Hi, I have a fedora32 system behind a firewall without any access from the outside. I'd like to build a reverse ssh tunnel so I can get to it from my remote location while working remotely. I'm familiar with how remote ssh tunnels work, but can't quite get systemctl to create a proper service, presumably because ssh expects to be tied to a terminal.
I've built the following shell script. I believe "bash -s" can be used to spawn processes not connected to a terminal.
# cat /etc/init.d/ssh-tunnel.sh #!/bin/bash -s ssh -i /root/.ssh/orion-key -R 43022:localhost:22 root@orion.example.com I was using this script in a unit file, but got closer to what I want by placing the ssh command itself into the unit file as the ExecStart parameter.
# cat /etc/systemd/system/connection.service [Unit] Description=Reverse SSH to orion After=network.target
[Service] Type=forking #EnvironmentFile=-/etc/sysconfig/sshd-permitrootlogin #EnvironmentFile=-/etc/sysconfig/sshd #ExecStart=/etc/init.d/ssh-tunnel.sh ExecStart=ssh -tt -i /root/.ssh/orion-key -R 43022:localhost:22 root@orion.example.com #ExecReload=/bin/kill -HUP $MAINPID User=root KillMode=process Restart=on-failure #RestartSec=42s
[Install] WantedBy=multi-user.target I also read that -tt can be passed to ssh to start it on a pseudo-terminal.
I then added the unit file as a service using "systemctl enable connection.service"
Can someone guide me on the unit parameters I should be using for this? Should Type=forking?
Alex Regan writes:
I'm familiar with how remote ssh tunnels work, but can't quite get systemctl to create a proper service, presumably because ssh expects to be tied to a terminal.
I did this a looooong time ago, so visualize me waving my hands frantically. You presumably want the "-n" flag (detaches from stdin), or possibly the "-f" flag (implies "-n" but allows prompting for a passphrase, but that doesn't seem to be appropriate for a service).
The man page is pretty good, and has a discussion of using the tun(4) network pseudo-device.
Regards,
On Tue, 25 Aug 2020 21:22:43 -0400 Alex Regan wrote:
Hi, I have a fedora32 system behind a firewall without any access from the outside. I'd like to build a reverse ssh tunnel so I can get to it from my remote location while working remotely.
I do this, but I don't run it as a service, I just have a script that checks to see if it is already running, and if it isn't starts it in the background. This gives me a chance to type in the long passphrase for the agent keys before it is backgrounded. I run this script when I login.
The script also loops if the ssh process ever dies, waits 30 seconds, and starts it again. (That way I can do things like reboot my home system and still get reconnected automagically).
On Tuesday, August 25, 2020 9:22:43 PM EDT Alex Regan wrote:
Hi, I have a fedora32 system behind a firewall without any access from the outside. I'd like to build a reverse ssh tunnel so I can get to it from my remote location while working remotely. I'm familiar with how remote ssh tunnels work, but can't quite get systemctl to create a proper service, presumably because ssh expects to be tied to a terminal.
You probably want -t:
-t Force pseudo-terminal allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty.
On 8/26/20 8:07 AM, Garry T. Williams wrote:
On Tuesday, August 25, 2020 9:22:43 PM EDT Alex Regan wrote:
Hi, I have a fedora32 system behind a firewall without any access from the outside. I'd like to build a reverse ssh tunnel so I can get to it from my remote location while working remotely. I'm familiar with how remote ssh tunnels work, but can't quite get systemctl to create a proper service, presumably because ssh expects to be tied to a terminal.
You probably want -t:
He's running it as a service, so he doesn't want a terminal. That will cause problems. Someone already mentioned the "-n" option which backgrounds the ssh process, detaching it from any terminals, but still allows forwarding to work.
On Tue, Aug 25, 2020 at 9:23 PM Alex Regan mysqlstudent@gmail.com wrote:
Hi, I have a fedora32 system behind a firewall without any access from the outside. I'd like to build a reverse ssh tunnel so I can get to it from my remote location while working remotely. I'm familiar with how remote ssh tunnels work, but can't quite get systemctl to create a proper service, presumably because ssh expects to be tied to a terminal.
I've built the following shell script. I believe "bash -s" can be used to spawn processes not connected to a terminal.
# cat /etc/init.d/ssh-tunnel.sh #!/bin/bash -s ssh -i /root/.ssh/orion-key -R 43022:localhost:22 root@orion.example.com I was using this script in a unit file, but got closer to what I want by placing the ssh command itself into the unit file as the ExecStart parameter.
# cat /etc/systemd/system/connection.service [Unit] Description=Reverse SSH to orion After=network.target
[Service] Type=forking #EnvironmentFile=-/etc/sysconfig/sshd-permitrootlogin #EnvironmentFile=-/etc/sysconfig/sshd #ExecStart=/etc/init.d/ssh-tunnel.sh ExecStart=ssh -tt -i /root/.ssh/orion-key -R 43022:localhost:22 root@orion.example.com #ExecReload=/bin/kill -HUP $MAINPID User=root KillMode=process Restart=on-failure #RestartSec=42s
[Install] WantedBy=multi-user.target I also read that -tt can be passed to ssh to start it on a pseudo-terminal.
I then added the unit file as a service using "systemctl enable connection.service"
Can someone guide me on the unit parameters I should be using for this? Should Type=forking?
There is already a service which does what you are trying to accomplish called autossh.
Steps to work: $ sudo dnf install autossh
Place config file into /etc/autossh for example, for the config file name I use the ipaddress without spaces and the remote port (because sometimes I need more than one remote port).
/etc/autossh/ipaddress-port OPTIONS=-i /path/to/private/key -M 10985 -o "PubkeyAuthentication=yes" -o "PasswordAuthentication=no" -o "StrictHostKeyChecking=no" -tt -R 6667:localhost:22 root@ip.ad.dr.ess
$ sudo systemctl start autossh@ipaddress-port $ sudo systemctl enable autossh@ipaddress-port
Regards, -Jamie
On 26Aug2020 17:00, Jamie Fargen jamie@fargenable.com wrote:
/etc/autossh/ipaddress-port OPTIONS=-i /path/to/private/key -M 10985 -o "PubkeyAuthentication=yes" -o "PasswordAuthentication=no" -o "StrictHostKeyChecking=no" -tt -R 6667:localhost:22 root@ip.ad.dr.ess
Just a general remark about remote ssh forwards. Unless you _know_ that the machine you are exposing is itself very well secured, it is better to use this form of the -R option:
-R 127.0.0.1:6667:localhost:22
That exposes the internal-machine ssh service only to localhost on the target external-machine. Default, if sshd has GatewayPorts enabled, is to expose it on "*" - allowing access (and therefore _attack_) on the external interfaces of the external machine.
When I make this kind of arrangement I always tie the exposed service to only the local interface, and access it via an ssh jump, eg ssh clause:
Host internal-machine ProxyCommand ssh -W 127.0.0.1:6667 external-machine
That way the only people who can access the ssh service of internal-machine are those already allowed access to external-machine, rather than the entire internet.
Cheers, Cameron Simpson cs@cskk.id.au
-
Alex Regan -
Cameron Simpson -
Garry T. Williams -
Jamie Fargen -
Samuel Sieb -
Stephen J. Turnbull -
Tom Horsley