Curious what advantages this has over mosh? https://mosh.org/
AIK, for using mosh, you need to install mosh on target host as well. Seems like autossh doesn't need this step.
Autossh – automatically restart SSH sessions and tunnels
61–70 of 90 posts
Re: Autossh – automatically restart SSH sessions and tunnels
#62For web-servers on remote machines, I have found this useful:
socat TCP4-LISTEN:1234,fork,bind=127.0.0.1 EXEC:'ssh my.remote.server nc 127.0.0.1 1234'
This will set up a tunnel only when needed, and seems to play nicely with my browser.
Re: Autossh – automatically restart SSH sessions and tunnels
#63Earlier quoted context omitted.
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.
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 some…
Just to clarify that we're talking about the same thing in case I misunderstood something: autossh (style) scripts do these things:
1. fake data to keep a connection "fresh" for shitty middleware
2. detect connection which are stuck (state = open, but no data can actually round trip) and kill them
3. restart ssh when that happens
Is that what we're talking about here? I think people are saying that points 1 and 2, but not 3, are covered by SSH's ServerAlive* options. And that's also how OpenSSH advertises and documents those options, and apparently even how autossh talks about it in their own readme.
You're saying that those options don't actually solve points 1 and 2, while (your/their/etc) autossh does properly detect it.
Correct so far?
If so that seems like a bug in OpenSSH (or whatever implementation) which should get appropriate attention upstream. Has anyone reported this upstream? Is there a ticket to follow?
PS: I think we're all in agreement that option 3 is out of scope for stock OpenSSH (regardless of what other tools do)
Re: Autossh – automatically restart SSH sessions and tunnels
#64Wouldn’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…
SSH protocol does not protect against weak configuration, e.g. password authentication without brute force mitigation. Zero-trust can be misconfigured too, so it depends how well either of them is configured.
Re: Autossh – automatically restart SSH sessions and tunnels
#65Earlier quoted context omitted.
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 i…
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…
The default of ServerAliveCountMax is already 3
Re: Autossh – automatically restart SSH sessions and tunnels
#66Not 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.
How well is tailscale accepted in orthodox enterprise security circles? I like the idea of it but can't even imagine trying to get it past the cyber security folks.
If "orthodox" means "vpn traffic cannot be established through third-party cloud infrastructure", then tailscale and any other cloud-hosted ZTNA solutions wouldn't be accepted in that kind of enterprise.
Re: Autossh – automatically restart SSH sessions and tunnels
#67If 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
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 i…
> ssh process stuck
systemd's RuntimeMaxSec should help in this case but I've never had trouble with sshd personally
To add more context I use the above service to ssh from my phone to my laptop via my desktop PC. The service runs on my laptop and binds port 22 of my laptop to port 7070 of my PC but wiregaurd would probably work similarly
Re: Autossh – automatically restart SSH sessions and tunnels
#68Earlier quoted context omitted.
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 some…
Just to clarify that we're talking about the same thing in case I misunderstood something: autossh (style) scripts do these things: 1. fake data to keep a connection "fresh" for shitty middleware 2. detect connection which are stuck (state = open, but no data can actually round trip) and kill them 3. restart ssh when that happens Is that what we're talking about here? I think people are saying that points 1 and 2, bu…
I haven’t revisited this issue in years but on a project for thousands of similar devices we found autossh much more reliable.
I believe the issue is that the connections often fail or get wedged in other network layers; the only way to be sure that your ssh tunnel isn’t: a) lossy enough to “keep alive” but too lossy to send data, or b) isn’t just always waiting on TCP retry backoff, or c) etc, is to use the tunnel to transmit actual data at the application level.
Re: Autossh – automatically restart SSH sessions and tunnels
#69Earlier quoted context omitted.
I think this is actually superior to autossh. Doesn’t autossh not restart after crash/reboot?
You could run autossh as a systemd service that starts on boot. :-)
I think you meant this as a joke, but this is what we landed on about a decade ago and it was the most reliable setup we found.
Re: Autossh – automatically restart SSH sessions and tunnels
#70I’d recommend https://eternalterminal.dev/ , compared to mosh(poor colors support), this is the only thing that manages to consistently keep up my ssh sessions.
I love ET. Some discussion here of its advantages over mosh: https://news.ycombinator.com/item?id=21640200. Beware that ET does phone home: depending on how it's packaged for your system, telemetry is enabled by default in /etc/et.cfg.