SSH access to office host behind NAT router

35

31

I would like to access the ssh port of my office linux host from home. Unfortunately the host is located behind a NAT router. So, the IP address is not publicly available. There is however access to another internet host (Server) which is unfortunately only non-root access. After a while of searching I do not find a suitable solution.

Following setup:

  • Office PC (linux, root access) behind NAT (IP not public) but full Internet access.
  • Server PC (linux, no root access) static and public IP and full Internet access.
  • Home PC (linux, root access) behind NAT (IP not public) but full Internet access.

Possible connections: Office PC --> Server <-- Home PC

Not possible: Office PC <-X- Server -X-> Home PC

Neither the Home PC, nor the Server can initiate access to the Office PC. But both the Office PC and the Home PC can initiate connections to the Server.

Reverse SSH tunnel not possible: I tried a method called reverse ssh-tunnel. Unfortunately this requires GatewayPorts on Server set to "yes" in /etc/ssh/sshd_config, where I have no root access.

In principle it should be possible:

0) On the Server I start a userspace program which listens on 2 ports (1 incoming, 1 outgoing)

1) On my office PC I run a another program which keeps a TCP connection open to the outgoing port on the server.

2) From home I connect to Server's incoming port.

There should be a standard solution for this out there.

What is the quickest and cleanest solution to solve this?

Frank

ritter

Posted 2011-04-29T15:52:01.060

Reputation: 635

You can use FileZilla with sftp and port forwarding. Check out: https://superuser.com/a/1286681/141314

– Noam Manos – 2018-01-18T07:19:08.323

1

can the work PC connect to home setting up an ssh tunnel? http://en.gentoo-wiki.com/wiki/Autossh

– None – 2011-04-29T17:03:47.830

Answers

31

youatwork@officepc$ autossh -R 12345:localhost:22 notroot@serverpc

Later:

you@homepc$ autossh -L 23456:localhost:12345 notroot@serverpc

you@homepc$ ssh youatwork@localhost -p 23456

What you could do is this: in step 1 forward a remote port from the office PC to the server (12345 is used as an example, any port >1024 should do). Now connecting to 12345 on the server should connect you to port 22 on officepc.

In step 2, forward the port 23456 from your home machine to 12345 on the server (whence it gets forwarded to officepc:22, as set up in step 1)

In step 3, you connect to the local port 23456 with your office PC login. This is forwarded by step 2 to port 12345 on your server, and by step 1 to your office PC.

Note that I'm using autossh for the forwardings, as it's a ssh wrapper which automatically reconnects the tunnel should it be disconnected; however normal ssh would work as well, as long as the connection doesn't drop.

There is a possible vulnerability: anyone who can connect to localhost:12345 on serverpc can now connect to officepc:22, and try to hack into it. (Note that if you're running a SSH server, you should anyway secure it above the basic protections which are on by default; I recommend at least disabling root login and disabling password authentication - see e.g. this)

Edit: I have verified this with the same config, and it works. GatewayPorts no only affects the ports that are open to the world at large, not local tunnels. This is what the forwarded ports are:

homepc:
  outgoing ssh to serverpc:22
  listening localhost:23456 forwarded through ssh tunnel
serverpc:
  listening ssh at *:22
  incoming localhost ssh tunnel (from homepc) forwarded to localhost:12345
  listening localhost ssh tunnel (from officepc) forwarded from localhost:12345
officepc:
  outgoing ssh to serverpc:22
  incoming localhost through ssh tunnel (from serverpc) forwarded to localhost:22

So, as far as the network stack is concerned, it's all local traffic on the respective loopback interfaces (plus ssh connections to serverpc); therefore, GatewayPorts is not checked at all.

There is, however, the directive AllowTcpForwarding: if that is no, this setup will fail as no forwarding is allowed at all, not even across the loopback interface.

Caveats:

  • if using autossh and recent ssh, you may want to use ssh's ServerAliveInterval and ServerAliveCountMax for keeping the tunnel up. Autossh has a built-in check, but apparently it has some issues on Fedora. -M0 disables that, and -oServerAliveInterval=20 -oServerAliveCountMax=3 checks if the connection is up - tries each 20 sec, if it fails 3x in a row, stops ssh (and autossh makes a new one):

    autossh -M0 -R 12345:localhost:22 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
    
    autossh -M0 -L 23456:localhost:12345 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
    
  • it might be useful to restart ssh tunnel if the forward fails, using -oExitOnForwardFailure=yes - if the port is already bound, you might get a working SSH connection, but no forwarded tunnel.

  • using ~/.ssh/config for the options (and ports) is advisable, else the command lines get too verbose. For example:

    Host fwdserverpc
        Hostname serverpc
        User notroot
        ServerAliveInterval 20
        ServerAliveCountMax 3
        ExitOnForwardFailure yes
        LocalForward 23456 localhost:12345
    

Then you can use just the server alias:

    autossh -M0 fwdserverpc

Piskvor left the building

Posted 2011-04-29T15:52:01.060

Reputation: 2 277

Thanks, this is great! I wanted to add 1) you are not obliged to run autossh on local PC (if you remember to start ssh manually in a separate terminal). 2) your autossh command doesn't work, -M 0 is missing (https://serverfault.com/a/367749/251416).

– Yaroslav Nikitenko – 2019-05-24T16:29:54.857

@YaroslavNikitenko: [Piskvor checks various tunnels that have been created by this very command, and they're all up and passing data] Sure it does, -M is an optional argument. In a decade of using this, I have yet to see an install where disabling autossh's monitoring would be necessary - and I'm running this setup on a variety of UN*Xlikes, from BSDs through Macs to various Linuxes. If this works for many different scenarios, but breaks in some others, I suspect something else might be amiss in that linked question... (old autossh? firewall SPI issues?) https://linux.die.net/man/1/autossh

– Piskvor left the building – 2019-05-27T10:16:25.317

1my autossh version (Fedora Core) could not run from terminal without -M. I've also linked to another person who experienced that. You are right that in the manual it is marked as an optional argument. Good if it works for many people, pity that not for all. – Yaroslav Nikitenko – 2019-05-28T08:51:18.627

Hmh...apparently there's yet another variant in Debian, where the precedence of command-line switches and environment variables is different; that seems to be a different caveat, though. – Piskvor left the building – 2019-06-10T10:56:58.830

I belive this method you are supposing is called "reverse ssh-tunnel". Unfortunately this requires GatewayPorts on Server set to "yes" in /etc/ssh/sshd_config. This server has no gateway ports enables and I have no root access there. – None – 2011-04-29T16:07:51.283

3@Frank: Actually, I don't think so: GatewayPorts no restricts the opened ports to be only accessible on the loopback interface; note that in step 2 you're forwarding on the loopback interface (in fact, both the forwards are "localhost only"), so this might work (AllowTcpForwarding no in the sshd config would break this). – Piskvor left the building – 2011-04-29T16:22:42.420

3

@Frank: Yup, confirmed. This works even with GatewayPorts no; edited the answer. Note that there are other directives (such as PermitOpen and AllowTcpForwarding) that can break this setup: http://www.manpagez.com/man/5/sshd_config/

– Piskvor left the building – 2011-04-29T16:47:24.777

1Excellent answer! It works, you saved my weekend! Many thanks!! – None – 2011-04-29T18:49:03.593

4

If you can ssh to the internal server from home and from the internal server to your office Linux machine, then from home you can use the ssh ProxyCommand to bounce silently through the server to the internal machine via nc (netcat)

# ~/.ssh/config on your home machine:
Host internalpc 
   ForwardAgent yes 
   ProxyCommand ssh user@server.example.com exec nc internal.pc.example.com %p

Then you just ssh user@internalpc and you are silently forwarded through the server machine, no opening of ports or tunnels required on either end.

Michael

Posted 2011-04-29T15:52:01.060

Reputation: 441

1Thanks for your answer. Unfortunately, neither the Home PC, nor the Server can initiate access to the Office PC. But both the Office PC and the Home PC can initiate connections to the Server. – None – 2011-04-29T16:05:19.583

4

Install Robo-TiTO in the computer that you want to access SSH remotely.

  • This will allow you to access SSH using from Google Talk Client Apps anywhere.
  • There is no need for a public IP address or special setting.
  • It's Free and Open Source, Not Paying any application services anymore.
  • No need to open SSH port (keep your computer safe).
  • No need to open any tunneling (e.g., VPN or something like that)

The following installation instructions are obsolete, as the site has moved. The new URL is https://github.com/formigarafa/robotito

I made a script (tested on my Raspbian OS in Raspberry Pi) so you can easily install Robo-TiTO on Raspberry Pi, Debian or Ubuntu Box (Debian package distribution). this is the steps to get your Linux box remoteable:

  1. Open Shell Command or you can call it Terminal, go to your home folder, Download installer script by command:

    $ wget https://opengateway.googlecode.com/files/robotito
    
  2. after that run the script by entering command:

    $ sudo ./robotito
    
  3. and then you can edit file credentials.rb from the config folder of Robo-TiTO using your GTalk account and save it by pressing Ctrl+X and Y.  Default is using nano editor.

  4. running the Robo-TiTO from Robo-TiTO folder by command

    $ cd robotito
    $ ./jabbershd start
    
  5. Now that this is done you can use SSH from any Google talk client.  Don't forget to add the Robo-TiTO GTalk account to your Google talk account and test it with chatting each other before using the account.

Rolly Maulana Awangga

Posted 2011-04-29T15:52:01.060

Reputation: 121

@Piskvor, robotito will only run commands from whitelisted contacts. https://github.com/formigarafa/robotito/blob/master/config/credentials.rb.example#L8

– formigarafa – 2016-02-17T22:06:15.347

I never run into any trouble because of the whitelist based authentication. If I am not wrong, the message transfer is encrypted when using with GTalk. One way or another, I changed it recently and now it uses a One Time Password from a tool like Google Authenticator or similar to allow access. – formigarafa – 2017-07-02T01:59:23.280

1

@formigarafa: (1) If you are or have been involved in the development of this product, you must say so, explicitly.  Using the same name is not enough; most people won’t notice that.  (You may mention it in your profile.)  (2) When you edit a post, you should fix it as much as you can.  For example, try to catch typos like “I’ts”.  And, if a link has gone down, don’t just label it as a dead link; put the new URL *into the post*.  People shouldn’t have to dig through the comments to find the correct information.

– G-Man Says 'Reinstate Monica' – 2017-07-02T06:02:17.167

@G-Man, The original answer and edit were not mine. And I never had the intention to make it look as mine. I noticed a dead link on the answer, I did not create the link either. I was actually keen to see its content and tried to follow it. Unfortunately I couldn't find the resource. I marked as a dead link on the hope that whoever wrote the answer would be notified by the change and try to fix it. – formigarafa – 2017-07-09T02:19:03.717

@G-Man, BTW, I tried to improve my profiles many times here but every time I try I get so confused that I simply give up. FYI, this just happened again. I just cannot find anywhere in my profile where I would add projects I am involved to. – formigarafa – 2017-07-09T02:29:48.543

@formigarafa: I’m not sure what you think I’m accusing you of.  I don’t believe that you tried to make it look like the original answer and edit were yours.  On the contrary, I’m suggesting that you tried to slip your edit in without your affiliation being obvious.  But please stop ducking the implied question: are you or have you been involved in the development of Robo-TiTO? You edited (tried to edit) Rolly Maulana Awangga’s answer to say “Note: Robo-TiTO received some updates recently, now it works with Ruby 2.0.0 or later. It also features some security improvements, … (Cont’d) – G-Man Says 'Reinstate Monica' – 2017-07-09T03:33:34.900

(Cont’d) …  like One Time Passwords using Google Authenticator or similar option. No more need for whitelisting accounts.”  My point is that, if you’re going to talk about a product you’re affiliated with — especially if you say good things, like that it has been improved recently — you should disclose that you’re biased / involved. … … … … … … … … … As to your profile, it’s not highly structured. Click on “Edit Profile & Settings” and say whatever you want to say in the “About me” box. There are also boxes for a website link and a GitHub link below that.

– G-Man Says 'Reinstate Monica' – 2017-07-09T03:33:37.110

I was not thinking about any accusation. Sorry if I used the wrong tone. @G-Man, Yes, I am involved with the development of Robo-TiTO. And what I meant was that I was trying to be respectful with someone else's answer and do not make it look as mine. The same way as Robo-TiTO, it is open-sourced and based on someone else's work. – formigarafa – 2017-07-11T22:13:02.283

6I have a serious problem with "No need to open SSH port (keep your computer save)" - the shell-over-jabber bot which you propose is secured with, quote, CLIENT_PASSPHRASE = "logmein", in plaintext. That is literally zero security - you're making a truck-sized hole for anyone to enter. Contrast to SSH public key authentication: I'm authenticating over a secure channel, using credentials which never even cross the wire. Who's keeping their computer safe now? – Piskvor left the building – 2014-04-07T16:11:13.817

3

Piskvor's solution works and is nice. However, it keeps terminals dangling open with login shells hanging. Not very cool.

I've always used this little script I wrote to connect to a server and keep it connected by running it in cron:

#!/bin/bash
TARGET_HOST=${1:-myserver.example.com}
TARGET_PORT=${2:-7777}
TUNNEL_PORT=${3:-22}
T_USER="odin"

#Check that we have an active connection to the remote system
ACTIVE_PROCESS=`ps -ef | \
    grep "ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT" | \
    grep -v grep | \
    wc -l`
if [ $ACTIVE_PROCESS -lt 1 ]; then
    echo "`date` : establishing connection to $TARGET_HOST on port $TARGET_PORT"
    screen -m -d ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT > /dev/null
fi

I bet we could fix Piskvor's solution using the more elegant autossh alongside maybe a detached screen or use the -NT ssh arguments to just keep the connection up in the background.

odinho - Velmont

Posted 2011-04-29T15:52:01.060

Reputation: 141

Thank you for the compliments :) For my use cases, I regularly need the shell access, as well as the forwardings; plus, I have tried to show the minimal case here (it is possible to simplify the above into two commands with transparent SSH host hopping, but that would require additional configuration on the homepc computer). – Piskvor left the building – 2014-04-07T16:02:19.100

2

To me , it sounds like, instead of a SSH tunnel, you should try a VPN: the kind that works by using a server on the outside to proxy through, such as Hamachi . There are other free softwares like this one, but Hamachi is my fav.

djangofan

Posted 2011-04-29T15:52:01.060

Reputation: 2 459

1Now that the 5.0.0.0/8 network actually has public IPv4 addresses assigned, Hamachi is in trouble (if Hamachi is running, you can not access a somewhat-random part of the internet). Also, Hamachi is no longer free-to-use. – Piskvor left the building – 2014-08-14T12:26:39.997