71–80 of 90 posts
Also, spiped is way simpler and more secure than SSH. (On my servers, I tunnel SSH over spiped, to protect the sshd from attacks.)
Earlier 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…
Curious what advantages this has over mosh? https://mosh.org/
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
Why SSH does not do this by default? Why the average Joe wants his SSH session to timeout?
In good conditions you can go months without sending a single byte of traffic between an SSH server and client and both will pick up the connection just fine when it's time to communicate again.
You could cut off traffic between them for any amount of time and they would be none the wiser as long as the network connection is back to normal when they finally try to send traffic again.
(I had SSH sessions in a QA lab persist as if nothing had happened after the connection between the endpoints was down for almost a week while we replaced the aggregation layer routers. They never saw a link state change since the access layer switches were up the whole time. They never attempted to communicate while the connections between those were down, so there was never any problem as far as they were concerned.)
The keepalives and connection checks and so forth are mostly to account for things like stateful network gear (firewalls, NAT routers, etc) between the endpoints that will cease relaying traffic between them if they are quiet for too long.
Earlier quoted context omitted.
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 t…
Isn't that exactly what ServerAliveInterval does? The man page says: "ssh(1) will send a message through the encrypted channel". A plain TCP keepalive wouldn't count as being "through the encrypted channel".
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
What is the reason to run 'sleep 20m'?
IIRC if there's an active connection on the forwarding thingy, that ssh command won't exit until the forwarded connection is closed, so this won't interrupt an active forwarded connection every 20min.
https://github.com/build-trust/ockam
One binary, easy to use, no ssh getting stuck! (yep, I work at Ockam :)