[HN Gopher] Autossh - automatically restart SSH sessions and tun...
___________________________________________________________________
Autossh - automatically restart SSH sessions and tunnels
Author : denysonique
Score : 91 points
Date : 2024-09-28 16:09 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| vincentpants wrote:
| Curious what advantages this has over mosh?
|
| https://mosh.org/
| mjw1007 wrote:
| mosh is for interactive sessions, to keep them working when the
| connection is flaky.
|
| autossh is for keeping unattended ssh tunnels alive, if the
| connection is flaky or one end is only intermittently
| available. So for using tunnels for the sort of thing you might
| otherwise use a VPN for.
| leni536 wrote:
| I have used autossh + tmux before to enable X forwarding (just
| for clipboard sharing). Couldn't do that in mosh.
| sgt wrote:
| Rather than using AutoSSH for port forwarding and such, I just
| create a systemd unit with a restart policy. Then you don't need
| autossh at all, just use ssh.
| xk3 wrote:
| If you have systemd, you could do this: [Unit]
| Description=look ma, no autossh After=network.target
| [Service] Type=exec ExecStart=/usr/bin/ssh -o
| ServerAliveInterval=60 -o ExitOnForwardFailure=yes -Nn -R
| 7070:localhost:22 pc 'sleep 20m' Restart=always
| RestartSec=20 RuntimeMaxSec=30m
| [Install] WantedBy=default.target
| ChoHag wrote:
| That's so much better than bourne/bash, which requires this
| monstrous wart of a code blob:
|
| autossh() { # Tiny delay after failure in
| case of connection errors while ! ssh "$@"; do
| echo Restarting ssh "$@"...; sleep 1; done }
| botto wrote:
| This is quite clean and tidy
| 8xeh wrote:
| This approach works very well. I've had dozens of extremely
| remote systems hooked up this way for about 8 years. The only
| problem I've seen is that occasionally the server ssh process
| will get stuck, so you have to log in to the server and kill
| it. It seems to happen when a remote goes offline and
| reconnects without closing the old connection first.
|
| If I were doing it now, I'd probably use wireguard, probably.
| This is simpler to set up and works great.
| elashri wrote:
| Can't you just add something like ServerAliveCountMaxto help
| with solving stale connections?
|
| So something like that would solve that
|
| [Unit] Description=look ma, no autossh After=network.target
|
| [Service] Type=exec ExecStart=/usr/bin/ssh -o
| ServerAliveInterval=60 -o ServerAliveCountMax=3 -o
| ExitOnForwardFailure=yes -Nn -R 7070:localhost:22 pc 'sleep
| 20m' Restart=always RestartSec=20 RuntimeMaxSec=30m
|
| [Install] WantedBy=default.target
| dietr1ch wrote:
| No passphrase for the key? What about spotty connection?
| Doesn't WantedBy block startup on this starting properly? (I'm
| pretty sure I've been soft locked out of my computer when
| Comcast decides to do Comcast things.
| j33zusjuice wrote:
| No. WantedBy will have no impact on startup. Before or after
| would, but not Wantedby.
| polalavik wrote:
| I think this is actually superior to autossh. Doesn't autossh
| not restart after crash/reboot?
| LaputanMachine wrote:
| It doesn't by default, but you can set the AUTOSSH_GATETIME
| environment variable to 0 so that autossh retries even if the
| first connection attempt fails.
| pferde wrote:
| You could run autossh as a systemd service that starts on
| boot. :-)
| denimnerd42 wrote:
| been doing this since 2012... autossh wasn't the solution back
| then even.
|
| you want ServerAliveCountMax too but default is 3.
| johnklos wrote:
| This is no better than ssh in a loop, which is trivially done
| by a shell script - no systemd needed.
|
| However, when you have shitty NAT routers (SonicWall, any AT&T
| fiber device, for instance), the connections will be timed out
| or will die and there'll be long periods where you're waiting
| for the next iteration of the loop, and/or sometimes it'll get
| stuck and never try again.
|
| autossh deals with this by actually passing traffic and taking
| action if traffic doesn't move.
| jauntywundrkind wrote:
| If you read what the person wrote, you'll see a
| ServerAliveInterval.
|
| If there are ServerAliveIntevalMaxCount (defaults to 3)
| attempts that fail, the ssh connection will drop. And systemd
| will restart it.
|
| Today you learned. Nice. I've dropped autossh for years and
| you can too, even on flaky connections.
| johnklos wrote:
| Today I learned that some people make mistakes, but I
| already knew that ;) ServerAliveInterval doesn't do this
| properly and consistently.
|
| I've used my own autossh type script for two decades now.
| It's mostly used to give access to machines behind shitty
| NAT, and/or that have addresses that constantly change,
| and/or for systems on CGNAT, like Starlink.
|
| If ServerAliveInterval works so well and negates the need
| for something like autossh to exist, then why have sessions
| created by my script, which has ServerAliveInterval (and
| ServerAliveIntevalMaxCount) gotten hung up where the script
| needs to kill the old and create a new ssh connection now
| and then? My script logs each timeout, each session hang,
| and each new connection, and depending on the network, it
| can happen often.
|
| Please read the bit where it's explained how autossh sends
| test data back and forth. Do you think you just magically
| and cleverly discovered ServerAliveIntevalMaxCount and that
| the autossh people have no idea that it exists?
|
| Or perhaps they know it exists, they know it's not perfect,
| and they used another mechanism to make up for the
| shortcomings of what ssh offers out of the box?
| oasisaimlessly wrote:
| > autossh deals with this by actually passing traffic and
| taking action if traffic doesn't move.
|
| The `ServerAliveInterval` option above achieves this.
| johnklos wrote:
| No, it actually doesn't, or at least not properly. It's not
| hard to get ssh sessions that are wedged.
| walrus01 wrote:
| This is not very dissimilar from how the RIPE Atlas software
| probe (debian package) maintains a persistent SSH
| command/control session to the anchors and RIPE infrastructure.
| As I recall it installs itself as a systemd service.
|
| https://atlas.ripe.net/docs/howtos/software-probes.html
| ndreas wrote:
| I used to use autossh to set up a SOCKS proxy to tunnel my web
| browser traffic via my home network and it worked really well.
| Also had a ControlMaster on the tunnel which made SSH connections
| to my server instantaneous.
|
| Nowadays I use wireguard an a dedicated SOCKS proxy. The upside
| is that I can access everything on my home network directly
| without having to tunnel.
| isoprophlex wrote:
| Not 100% the same use case as autossh was built for maybe, but
| I'm now simply throwing tailscale on every box i need to interact
| with. Does away with all the port forwarding stuff, it's
| absolutely delightful.
| amlib wrote:
| How much reliance on third party am I subjecting myself by
| using Tailscale? What happens if I make a local connection to a
| machine/service running on Tailscale, does it still go out of
| the local network? If so, is the bulk of the payload
| transferred locally? Is there any advantage on using it if the
| machine/service is easily accessible over ipv6?
| botto wrote:
| That's what Tailscale is built for, when it can it sets up a
| P2P connection, it only ever sends data through Tailscales
| servers if you are in a restrictive network environment (i.e.
| corp network that controls all inbound and outbound traffic)
| snailmailman wrote:
| It will route directly over the local network when possible.
|
| It will be encrypted through the VPN, so there will be some
| overhead. But will be as direct as it can be. It only routes
| through tailscales servers as a last resort, when it can't
| find a direct route at all (usually because NAT holepunching
| fails somehow). Their "DERP" relay servers just relay the
| encrypted connection. I think you can use your own relay
| servers, but I don't know if that feature can be disabled
| entirely.
|
| Headscale can be entirely self-hosted. It still uses the
| tailscale client applications- but is compatible.
| isoprophlex wrote:
| good questions, pretty well answered by other commenters. if
| you are happy with the level of encryption you have on your
| 'plain' ipv6 connection, sure, use that.
|
| additionally the acl/auth system, their dns and service
| discovery thing is nice, though not essential.
| leetrout wrote:
| I used autossh to do terrible things securing redis back in 2013.
| Fantastic tool.
| r0n22 wrote:
| Ohh tell me more?
| leetrout wrote:
| Way back redis didnt have passwords at all. That got added
| but there was no secure transport support.
|
| So I ran redis in a higher memory box at rackspace separate
| from my db and my app server. I used autossh to forward 6379
| from localhost on the app server(s) to the redis server.
| Worked like a charm and never caused any issues.
|
| Other commenters are right in that wireguard is a great
| modern solution to this!
| frizlab wrote:
| How is this different from this ssha () {
| while true do ssh "$@" sleep 1
| done true }
|
| EDIT: Oh I think I know, autossh must be detecting when the
| connexion is closed but ssh does not automatically...
| beagle3 wrote:
| Ssh does with the right settings and has for about a decade -
| see the systemd example someone posted above.
| botto wrote:
| I've used autossh to have a reverse tunnel open connection back
| to my work desktop, IT never found it and I had that in place for
| year
| hi-v-rocknroll wrote:
| The last time I used autossh it was on a client site to keep 2
| layers of ssh tunnels open to jump through their network
| isolation hoops.
|
| In general, when flexibility is possible, such a use-case
| nowadays would often be better served by deploying WireGuard.
| Grouchy, out-of-touch corporate net admins probably don't even
| know what it is and insist on their antiquated Cisco VPNs.
| beagle3 wrote:
| 14 years ago, i was using auto ash to keep SSH tunnels up; but at
| some point (quite far back - perhaps 2016?) ssh gained everything
| needed to do this internally _except_ the restart.
|
| At this point I configure all of the keep alive and retry options
| in ssh_config and sshd_config, and use While
| true; do ssh user@host ; sleep 10; done
|
| To get the same effect, but with much more flexibility - e.g.
| alternating connection addresses on a multihomed host, add
| logging, run from daemontools or systemd unit instead of a loop
| and let them track the process and restart, etc.
| amelius wrote:
| Nice tool, but I'm getting tired of using port numbers for
| everything instead of more descriptive strings. My system has
| more than 10 tunnels and servers running, and since I only do
| sysadmin work once every half year or so, the port numbers are
| very cumbersome to deal with.
| jclulow wrote:
| I believe these days SSH is willing to forward a UNIX domain
| socket to a remote TCP port, or a local TCP port to a remote
| UNIX domain socket, or any combination of the two families
| really. You could use names locally, if your client tools are
| willing to do AF_UNIX!
| mjw1007 wrote:
| The nice thing about this is that, with filesystem
| permissions on one end and a check for SCM_CREDENTIALS or
| SO_PEERCRED on the other, you can effectively get user-based
| access control working between two machines.
|
| I think this is the one remaining advantage of ssh tunnels
| over using a VPN.
|
| NB if you're doing this sort of thing, you probably want to
| add `StreamLocalBindUnlink yes` to the ssh options.
| sjf wrote:
| Agreed, I have so many services that all want to run their own
| webserver, db, elasticsearch, etc. I have to start using non-
| standard port numbers and it's a burden to have to keep track
| of them.
| dheera wrote:
| autossh is nice but the default options suck. I have to do
| something like this for it to work well autossh
| -f -N -o ServerAliveCountMax=2 -o ServerAliveInterval=5 -o
| ConnectTimeout=5 -o BatchMode=yes [...]
| chasil wrote:
| Use stunnel for non-interactive tunneling over TLS.
|
| It is much more straightforward than ssh for this purpose, and
| works well with socket activation under systemd.
|
| I use it with the systemd automounter to encrypt NFSv4, and I
| have found it to be quite reliable.
| dingi wrote:
| Sometime back, I had a rapsberry pi connected to wired network of
| a coworking space. I remember using autossh to keep a tunnel open
| with one of my VPS. Mainly used it as a torrent box. I added
| magnet links through qbittorrent webui installed on raspberry pi.
| Qbittorrent was configured to only run at night time to not cause
| issues for business work. Downloaded all sort of things easily
| reaching thousands of GBs throughout my time there. They never
| found out. Or they didn't care to look. Good times.
| qwertox wrote:
| I use this to set up reverse tunnels, for example to set up
| MongoDB replica sets which sync through SSH. It kind of
| simplifies the security aspect of replica sets a bit, since then
| MongoDB does not need to be exposed to the internet and no VPN
| setup is needed.
| aborsy wrote:
| Wouldn't ssh with systemd or auto ssh be a more secure means of
| remote access to apps (like http/https apps) than the zero trust
| network access solutions (like Cloudflare Tunnels which
| terminates the TLS) or even Tailscale (which should be a trusted
| third party)?
|
| You set up public key authentication with SSH to a reverse proxy,
| a persistent tunnel, and a socks proxy. In a Firefox profile, you
| set localhost:port. Done! All your services are available in that
| browser all the time.
|
| Autossh with a reverse ssh tunnel can also be used to expose an
| internal service to the Internet through a VPS.
|
| SSH has been very secure over the decades. A good feature of SSH
| is that it can jump from host to host, unlike VPN.
| whalesalad wrote:
| mosh
| bashkiddie wrote:
| I used to be a happy user of `autossh` until 2023. I used it on
| Cygwin on Windows and was quite happy how reliably it set up my
| tunnels (upon tunnels) in a flaky corporate network. `autossh`
| worked reliable compared to `ssh`s many timeout options.
|
| I would still recommend it.
___________________________________________________________________
(page generated 2024-09-28 23:00 UTC)