
SSH tunnelling for fun and profit: AutoSSH - everythingcli
http://www.everythingcli.org/ssh-tunnelling-for-fun-and-profit-autossh/
======
wscott
I use sshuttle
([https://github.com/apenwarr/sshuttle](https://github.com/apenwarr/sshuttle)).
It is super flexible and works as a poor man's VPN.

It also has much better performance when used over a flaky connection because
it doesn't do TCP-over-TCP.

It doesn't really create a persistent tunnel like this thingy, but it seems
worth mentioning to people who might find autossh interesting.

~~~
sneak
Alternately, "ssh -D 1080 user@host" will give you a SOCKS proxy on
127.0.0.1:1080 that forwards all connections out of the remote host. No
download required.

~~~
tobiaswk
Yes this works fine for most cases. Although I've had DNS-related problems
I've never been able to resolve properly.

~~~
Diederich
Can you expand on that? I've never seen any problems with -D

~~~
therein
Well the DNS queries aren't routed through the proxy.

------
yanokwa
For a persistent connection to a server, I like mosh
([https://mosh.mit.edu](https://mosh.mit.edu)). It works really well for
roaming across networks and for intermittent or laggy connectivity.

~~~
Carrok
Yea this looks like a terribly convoluted solution for something mosh has
solved quite elegantly.

~~~
Piskvorrr
1\. Mosh is about a decade younger than this ("why would anyone write this,
when there would be a better solution in ten years?!" \- Mosh was a _response_
to the shortcomings of available programs, namely the combination of
autossh+screen), 2. Mosh solves a slightly different problem (persistent
terminal emulation across variable and unstable connection X persistent SSH
connection - one has intelligent local echo, the other has tunnels)

------
wiz21c
I used autossh for 2 years, several times a week, and it is absolutely robust
(like never failed, ever) when it comes to restarting a broken ssh connection

------
NelsonMinar
One thing the article glossed over is the SSH key. I set this up for remote
access to a computer behind a NAT router that does not allow any incoming
connections at all. For that to work robustly in case of a reboot, the private
ssh key used by that computer must have no passphrase. That always makes me
nervous, I ended up setting up the public computer side of this with a special
user account that was as locked down as I could make it. All the ssh tunnel
will do is forward port 2200 on the public machine to my computer's ssh port.
Works great!

~~~
Piskvorrr
Or you could use a SSH agent (Pageant, ssh-agent): you enter your key
passphrase _once_ when starting the agent, and it handles the key auth on your
behalf.

~~~
NelsonMinar
How do I enter the passphrase when the computer behind the firewall reboots?

~~~
Piskvorrr
Ah. Now that's a problem I have no _solution_ for - only the same workaround
as you describe (you have taken one more step than I did by having a dedicated
_host_ for the SSH connection, instead of just an account - with today's
virtualization, this is easier than ever :)).

------
tomkinstinch
A challenge I've had with Autossh (and OpenSSH for that matter) is in getting
the listen port during remote (reverse) tunnels when it is dynamically
assigned via '-R 0:localhost:$SOMEPORT' where $SOMEPORT is on the machine
originating the reverse tunnel, and 0 is a dynamically assigned open port on
the relay/remote machine. It doesn't look like there is a good way[1] to get
the listen port from the originating side (remotehost:$DYNPORT) without
inspecting ssh stdout (complicated when using Autossh via systemd). Any ideas?
On the remote side it is easy to find the listen port provided you have sudo
access, but seemingly impossible without [2]. On the local side I probably
just need to pipe stdout to a regex to find the right string and then redirect
the captured port number to a file or named pipe, but it seems like it ought
to be easier to get dynamic port assigned on the remote side from the local
end of the tunnel.

1\. [http://www.nico.schottelius.org/blog/openssh-6.2-add-
callbac...](http://www.nico.schottelius.org/blog/openssh-6.2-add-callback-
functionality-using-dynamic-remote-port-forwarding/)

2\.
[https://gist.github.com/tomkinsc/c2932097796155f4fd94](https://gist.github.com/tomkinsc/c2932097796155f4fd94)

------
anfogoat
Assuming autossh is going just rerun whatever binary ssh points to, then you
likely wont need a separate binary for this. Just run

    
    
      while true; do ...; done
    

and be done with it. The author does say that

 _... Some scripts use a while loop, others encourage you to run a remote
command (such as tail) to make sure you don’t run into timeout and various
others. But actually, you don’t want to re-invent the wheel and stick to
bullet-proof already existing solutions._

but the only case where that makes sense, and where a simple while loop will
fail you, is if the ssh command hangs. Only then will this start making sense.

~~~
x0
I'd put a `sleep 5s` or so in there as well, in case your wifi is off or
something, and it's looping "no route to host" over and over.

~~~
Piskvorrr
...and a condition for this, and a bit of checking for that, and a SSH option,
and a signal handler - and all of a sudden, you have replicated autossh 0.7,
except buggier and in bash.

~~~
x0
Replace bash with zsh and you have my life story.

------
matt_wulfeck
In the example of the author creating a reverse tunnel for mysql, I can't
decide if I love or hate these types of tunnels. On the one hand it's nice to
allow SSH to do all of the encryption heavy lifting, and to punch a single
hole through the firewall. It's also nice that somebody sniffing around from
the outside doesn't really have any idea what services are running on the box.

On the other handle it comes off as much too hacky for something I'd trust my
production services with. It also involves two levels of authentication (PKI +
whatever is built-in to the system).

------
jacquesm
Nice tool but not quite as reliable as I'd like it to be, especially on the
reconnection-in-the-face-of-unreliable-transport front. I tried using it for
my mailtunnel but eventually switched to a VPN over UDP.

~~~
vidoc
you might take a look at zerotier.com. They provide tools/services to ease
tun/tap much like docker eases lxc/containers.

~~~
jacquesm
For now openvpn seems to fill my needs but thank you for the reference, if I
can't get this to work reliably over the longer term I will look at zerotier.

------
peterwwillis
This seems like pretty simple code. Could we not roll this into the official
ssh client as a patch, but instead of port forwarding, use the existing keep-
alive code and ssh signaling channel to check the connection and restart the
session? Not only would this be cleaner (no need for wrappers), but we could
use it on servers where port forwarding is disabled.

------
kardos
I understand the fun part but somehow missed the profit aspect

~~~
Piskvorrr
Can't remember how many times a persistent autossh reverse tunnel to a jump
host has saved me from several hours of a field trip. A few man-months, I'd
guess - that's quite enough profit for me ;)

------
Aissen
Nice tool, but doesn't play well with ssh_config ControlPersist, which is
essential to my use cases :-(

~~~
everythingcli
you could still append this option: `autossh -oControlPersist=yes|no"`

~~~
Aissen
And then losing the advantage of ControlPersist; the ideal would be to have an
always-on ControlMaster, but that would also be restarted once
ServerAliveInterval*ServerAliveCountMax expires.

------
brightball
This is pretty slick.

------
daurnimator
This tool makes me afraid.

Anyone that can successfully use AutoSSH is not monitoring their private key
usage. You should always need to approve each time your SSH key is used;
whether via typing in your password, swiping your smartcard, or pressing the
button on your yubikey.

~~~
everythingcli
This is not how it is meant. When you use AutoSSH/SSH and need to enter a
password for your key anytime you do a connection (which probably happens
every 10min as a system engineer/admin/etc) it is probably useless.

I have many different SSH keys, each with different long passwords.

What u are looking for is `ssh-agent` which can take care of all the password
handling.

Also unattended rsync (over ssh) backups rely on no user interaction at all.

~~~
Tiksi
On top of that, you can always use a separate user for the tunnel that doesn't
have a login shell. Obviously still a problem if someone gets the private keys
but not nearly as much so, as they'll basically be limited to
tunneling/forwarding.

