81–90 of 90 posts
Curious what advantages this has over mosh? https://mosh.org/
Biggest issue i have with mosh is that it you cant scroll up the history. It is kind of a deal breaker for me.
Earlier 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…
> 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
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
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…
You also need ClientAliveInterval on the server side (in addition to ServerAliveInterval on the client). In other words, both the client and the server need to be configured to monitor the connection. With this setup I had no issues with reconnections.
Earlier quoted context omitted.
> 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
RuntimeMaxSec would have systemd kill a live forwarded connection though?
ssh -O cancel -L 4102:localhost:4000 pc
Host *
ServerAliveInterval 11I’ve run autossh for quite some time but it was not reliable enough under my conditions
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.
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!
Anyway:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1688774 - [open] "Support HTTP over unix domain sockets" - 4 years old, last activity 7 months ago,
- https://issues.chromium.org/issues/40402523 - [closed; won't fix] "[ENH] Support HTTP over Unix Sockets via http://localhost:[/tmp/socket]/foo convention " - 9 years old, last activity 11 months ago.
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
Earlier quoted context omitted.
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…
> 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".
Earlier quoted context omitted.
> 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".
Honestly at this point Im out of date, but autossh also takes care of bugs or connection issues within the ssh link itself
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.
Earlier quoted context omitted.
Honestly at this point Im out of date, but autossh also takes care of bugs or connection issues within the ssh link itself
So 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.