Basically I want to be able to do something like teamviewer, where regardless of what the network configuration is, as long as both my ssh server (Machine A) and ssh client (Machine B) have internet access (and some 3rd server, Machine C), I can gain access - the reason for this is I want to be able to move machine A around, plug it in to power, have it auto-connect to one of several pre-configured wifi networks (each one unique/different), without having configured port-forwarding or similar on the networks, and be able to log into it via the internet from Machine B

How can I accomplish this? I don't mind setting something up on a server with a static IP address for helping out with the handshake, but I also don't mind a 3rd party server either if something already exists (like it does for say teamviewer)

edit for clarity: I have 3 machines, A B and C

A is a headless raspberry pi that will be powered on/off in random locations, connect to a pre-confiugred wifi network

B is the machine with a proper monitor, keyboard, etc. that I want to connect from

C is a rented AWS server that I have with a static IP address, can reliably SSH in from B, and can install whatever is necessary to help B connect to A

  • Can you ssh to the 3rd machine?
    – Anthon
    Sep 27, 2015 at 15:37
  • @Anthon I think so, I re-named them A B and C and added descriptions for them, hopefully that clears it up Sep 27, 2015 at 15:43
  • cough no-ip.com cough
    – Joshua
    Sep 27, 2015 at 21:42
  • 1
    no-ip.com won't help if the perimeter firewall at your location doesn't allow return traffic!
    – bobstro
    Sep 28, 2015 at 0:22
  • I used to use ssh tunnels, very briefly. I could never get them to stay up, though, even with autossh; if the uplink dropped for any reason, they'd always have to be restarted by hand. Eventually I set up a small VPN for myself with OpenVPN, and it's done the job nicely. Sep 29, 2015 at 2:00

5 Answers 5


As you have the machine C on the internet, make a special account there named sesame, and on A you make an account with a public/private key from which you have copied the public key to the sesame account on C.

You can now login from A to C, but instead of doing that you do:

ssh -N -R 19930:localhost:22 sesame@yourserverC

( you might want to combine this with a sleep statement or e.g. 10 seconds and wrap this in a endless loop so the connection is re-established if WiFi down caused it to break )

From machine B, normally login to whatever account you have on C (can be but doesn't have to be the sesame account, different accounts is what I use). And once you are on C, login to A using:

ssh localhost -p 19930

You can of course use a different number than 19930.

It is possible to run the ssh -N -R ... from /etc/rc.local if your private key on A is not password protected. In that case make sure to make sesame a separate account with limited functionality, so that when your machine A gets compromised/stolen, the risk for your server C is limited. That is also why I recommend use a separate account to get from B to C.

You can actually set the login shell for sesame in /etc/passwd to /bin/false, so you can no longer use the account for login.

  • This solution is different from using TeamViewer, there the server is used to open the ports which are then redirected to directly communicate. Just like programs like BitTorrent directly communicate after finding machines to download from (without having to open up ports in advance either).
    – Anthon
    Sep 27, 2015 at 15:56
  • So the main difference is that this way ALL the traffic goes through server C, vs C being used only to establish a link, and then not being used for the rest of the connection - I am OK with that. You do have a good point as far as security goes, is there anything I should do in particular to make sesame be unable to do anything on C besides the bare minimum of logging in? (RHEL system) Sep 27, 2015 at 16:14
  • 1
    @user2813274 Indeed al of the trafic goes through C in this scenario (which would take the usefulness out of BitTorrent). I am not sure how far you can limit the sesame account on C, it might be that you can make it run /bin/false as login shell (since ssh never really logs in), or otherwise limit it by adding a command= parameter in ~/.ssh/authorized_keys
    – Anthon
    Sep 27, 2015 at 16:56
  • @user2813274 In case you haven't tried yourself: if you have a special account for setting up the reverse proxy, you can disable logins to that account by changing the login shell to /bin/false.
    – Anthon
    Sep 29, 2015 at 6:03
  • 1
    @user2813274 Yes I tried that out and it would let me set up the reverse tunnel (you you need a different account to get to server C to do the ssh localhost -p portnum of course )
    – Anthon
    Sep 29, 2015 at 12:37

Install a IPv6 tunnel (such as Sixxs) on your Raspberry Pi. You'll now have a permanent static IPv6 address that will come online whenever your Pi is online. Make sure you secure your Pi as it's connected to the world now.

If your B is connected to an IPv6 network, then connect directly to the Pi. If B is not connected to an IPv6 network, use C as a jump server, where you connect over IPv4 to C and then ssh over IPv6 from C to your Pi.

  • I like this as it doesn't even require C if the networks support IPV6, I will have to try it out though - any issues as far as firewalls blocking this by default? Sep 27, 2015 at 16:11
  • 1
    Sixxs provide more than one protocol for tunneling IPv6. If you use Anything In Anything (AYIYA) you'll need TCP port 3874 and UDP port 5072 open from the Pi to the Internet. On home networks, this should be fine; corporate or campus networks might be different. Sep 27, 2015 at 16:28
  • Installing the tunnel sounded doable, but it seems I would have to sign up for the Sixxs service, wait for them to get back to me with an IP address, etc. - not quite so simple anymore - still potentially a good solution, but I don't think its the route I am going to go for now. Sep 28, 2015 at 15:23

Also have a look at this:

The technology used is the same as the one described in the accepted answer, but it uses some scripts to automate things and to make the solution more generic. It also makes the whole configurations inside a Docker container, so that the main system is safe in case that something is compromised.

However it does not provide automatic connection from A to C, it has to be initiated manually. Maybe you can customize the solution a bit so that it does exactly what you want.


Perhaps you need to use other than ssh or tunneling concept.. I suggest that you use messaging concept like whatsapp or telegram.. But i think, if you want to use something like vim, it's not as good as ssh..

Telegram have telegram-cli client that you can modify to accept and execute certain command and implement it in the raspi..

If you use Telegram you can simplify your network and at least reduce the C machine to do the Hub because the C server is subtituted with telegram messaging server.. telegram already come up with iphone and android client so i dont think that you need your B Machine too, you can install telegram client for specific OS if you want.. security? telegram message is encripted.. If someone want to ddos your raspi? they will ddos the telegram server first..

So as long as your raspi can connect to telegram server (simply your raspi connect to internet) even the raspi is behind firewall/proxy/private IP/dynamic IP, you can always do the remote..

With this concept, you can do the remote anywhere, anytime..

  • Wat. That's insecure, you're trusting some random messaging app, you're saying that OP should go modify said random messaging app to get it to work. This is not even realizing that the random messaging app would entirely break with something like vim and have horrible latency. Sep 28, 2015 at 13:32
  • Well, if you use it just to send command i think its ok.. if you use it to something like vim, i dont think it's good.. good advice.. i'll edit my answer Sep 28, 2015 at 14:48
  • I don't think this is what I want, I want full shell access, not really anything less than that - as far as ddosing the Pi.. I am not really concerned, first of all because I have to do a special setup to even connect to it myself, second because it's connections will be intermittent and randomly changing anyways Sep 28, 2015 at 15:19

I think you should take a look at reverse ssh port forwarding. In a nutshell, you first initiate an ssh from A to C using the syntax below and then use that port to tunnel back from C to A. You will not hit the home firewall of A when you do so because the R-Pi already has a tunnel.

ssh -R 2210:localhost:22 myCoolAwsSite.com

Please consider security ramifications when you do so. You can add some cron jujitsu so that the connection is re-established following a reboot.

  • Err... how is this any different than Anthon's answer? Sep 30, 2015 at 17:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.