3 ms·
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
by svnt 2y ago
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.
- pritambaral 2y ago> is to use the tunnel to transmit actual data at the application level. 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".
- svnt 2y agoHonestly at this point Im out of date, but autossh also takes care of bugs or connection issues within the ssh link itself
- jauntywundrkind 2y agoSo does ssh now. So much smoke & obfuscation. Autossh itself mentions ServerAliveInterval. It's worked flawlessly on all kinds of dodgy connections for me. If anyone has any damned bug reports, link them.
- svnt 2y agoI don't know if I would call it smoke and obfuscation, at the time systemd was not widely deployed and the ssh functionality was not as developed, so it made sense to use autossh. Now it sounds like it doesn't make sense anymore. It happens.