13 ms·

I've been using SSH for ~15 years and never knew about these escape sequences. I'm eagerly awaiting my next hung session so that I can test `~.`. It's much nice

I've been using SSH for ~15 years and never knew about these escape sequences. I'm eagerly awaiting my next hung session so that I can test `~.`. It's much nicer than my current approach of having to close that terminal window.

shmerl 7mo ago
I've been using ~. on hung ssh connections for a while.
wolvoleo 7mo ago
I use that every day but it's the only one I know by heart lol
lathiat 7mo ago
Have been using that weekly since probably 20 years. Will change your life :) My other favourite is I very often SSH with -v to figure out why the connection is hanging, you rapidly figure out if DNS is failing, the TCP connection doesn't open, it does open but no traffic flows at all or it opens and SSH negotiation starts but never finishes. You can learn a lot just from this about what is wrong.
- Izkata 7mo ago
  Also helps with auth failures, I've used it several times with co-workers who can't figure out why their ssh key isn't working. It lists the keys out and some extra information.
- syncsynchalt 7mo ago
  And of course, you can use the ~v / ~V commands (as listed in the ~? menu) to increase/decrease verbosity after the connection is established. That lets you `ssh -vvvv` to a host then once you've figured out the issue use ~V to decrease verbosity so that debug messages don't clutter your shell.
sirfz 7mo ago
You can even chain them if you have deep ssh connections (i.e. ssh from one instance to another). I think it would be ~~. to terminate the 2nd hop. Edit: it's already explained in the OP
TacticalCoder 7mo ago
> It's much nicer than my current approach of having to close that terminal window. You can also just kill the ssh process (say from another terminal). That way you get to keep your terminal window. And this works with everything "blocking" your terminal, not just ssh.
tomxor 7mo ago
If hung SSH connections are common it's likely due to CGNAT which use aggressively low TCP timeouts. e.g. I've found all UK mobile carriers set their TCP timeout as low as 5 minutes. The "default" is supposed to be 2 hours, you could literally sleep your computer, zero packets, and an SSH connection would continue to work an hour later, and generally speaking this is still true unless CGNAT is in the way. If you are interested there are a few ways you can fix this: Easiest is to use a VPN, because the VPN's exit node becomes the effective NAT they usually have normal TCP timeouts due to being less resource constrained. Another nice benefit of this method is you can move between physical networks and your connection doesn't die... If you use Tailscale then you already have this in a more direct way. Another is to tune the tcp_keepalive kernel parameters. Lowering the keepalive timeout to be less than the CGNAT timeout will cause keepalive probes to prevent CGNAT from dropping the connection even while your SSH connection is technically idle. For Linux I pop these into /etc/sysctl.d/z.conf, I have no idea for Windows or Mac: # Keepalive frequently to survive CGNAT net.ipv4.tcp_keepalive_time = 240 net.ipv4.tcp_keepalive_intvl = 60 net.ipv4.tcp_keepalive_probes = 120 This is really a misuse of these settings, they are supposed to be for checking TCP connections are still alive and clearing them up from the local routing table. Instead the idea is to exploit the probes by sending them more frequently to force idle connections to stay alive in a CGNAT environment (dont worry the probes are tiny and still very infrequent). _time=240 will send a probe after 4 mins of idle connection instead of the default 2 hours, undercutting the CGNAT timeout. _intvl=60 and _probes=120 mean it will send 120 probes 60 seconds apart (2 hours worth) before considering the connection dead. This will keep it alive for at least 2 hours, but also allows us to have the best of both worlds so that under a nice NAT it keeps the old behaviour, e.g if I temporarily lose my network the SSH connection is still valid after 2 hours, but under CGNAT it will at least not drop the connection after 5 mins so long as I keep my computer on and don't lose the network. There are also some SSH client keepalive settings but I'm less familiar with them.
- anthk 7mo ago
  Check Mosh. It supports these kind of cuts and it will reconnect seamlessly. It will use far less bandwidth too. I successfully tried it with a 2.7 KBPS connection.
- 7mo ago
fragmede 7mo ago
Just ssh to funky.nondeterministic.computer to test it out!
tdeck 7mo ago
You don't need to actually open the menu either. Just hit enter, tilde, ., enter.
aa-jv 7mo ago
I last used this menu about 20 years ago when a dialup modem was the only way to roll, and have pretty much forgotten about it since the days of always-on direct to the desktop TCP/IP ..
bramgn 7mo ago
Be sure to hit enter before you start typing `~.`. It only works on a new line
ranger_danger 7mo ago
If you regularly have to deal with hung connections or slow/unreliable links, I suggest trying out mosh. https://mosh.org/ https://mosh.org/
a96 7mo ago
Probably getting closer to 30 than 25 for me. And I used rsh before that where guess what was used to escape the input. https://en.wikipedia.org/wiki/Berkeley_r-commands https://en.wikipedia.org/wiki/Berkeley_r-commands

shmerl 7mo ago

I've been using ~. on hung ssh connections for a while.

wolvoleo 7mo ago

I use that every day but it's the only one I know by heart lol

lathiat 7mo ago

Have been using that weekly since probably 20 years. Will change your life :) My other favourite is I very often SSH with -v to figure out why the connection is hanging, you rapidly figure out if DNS is failing, the TCP connection doesn't open, it does open but no traffic flows at all or it opens and SSH negotiation starts but never finishes. You can learn a lot just from this about what is wrong.

Izkata 7mo ago
Also helps with auth failures, I've used it several times with co-workers who can't figure out why their ssh key isn't working. It lists the keys out and some extra information.
syncsynchalt 7mo ago
And of course, you can use the ~v / ~V commands (as listed in the ~? menu) to increase/decrease verbosity after the connection is established. That lets you `ssh -vvvv` to a host then once you've figured out the issue use ~V to decrease verbosity so that debug messages don't clutter your shell.

sirfz 7mo ago

You can even chain them if you have deep ssh connections (i.e. ssh from one instance to another). I think it would be ~~. to terminate the 2nd hop. Edit: it's already explained in the OP

TacticalCoder 7mo ago

> It's much nicer than my current approach of having to close that terminal window. You can also just kill the ssh process (say from another terminal). That way you get to keep your terminal window. And this works with everything "blocking" your terminal, not just ssh.

tomxor 7mo ago

If hung SSH connections are common it's likely due to CGNAT which use aggressively low TCP timeouts. e.g. I've found all UK mobile carriers set their TCP timeout as low as 5 minutes. The "default" is supposed to be 2 hours, you could literally sleep your computer, zero packets, and an SSH connection would continue to work an hour later, and generally speaking this is still true unless CGNAT is in the way. If you are interested there are a few ways you can fix this: Easiest is to use a VPN, because the VPN's exit node becomes the effective NAT they usually have normal TCP timeouts due to being less resource constrained. Another nice benefit of this method is you can move between physical networks and your connection doesn't die... If you use Tailscale then you already have this in a more direct way. Another is to tune the tcp_keepalive kernel parameters. Lowering the keepalive timeout to be less than the CGNAT timeout will cause keepalive probes to prevent CGNAT from dropping the connection even while your SSH connection is technically idle. For Linux I pop these into /etc/sysctl.d/z.conf, I have no idea for Windows or Mac: # Keepalive frequently to survive CGNAT net.ipv4.tcp_keepalive_time = 240 net.ipv4.tcp_keepalive_intvl = 60 net.ipv4.tcp_keepalive_probes = 120 This is really a misuse of these settings, they are supposed to be for checking TCP connections are still alive and clearing them up from the local routing table. Instead the idea is to exploit the probes by sending them more frequently to force idle connections to stay alive in a CGNAT environment (dont worry the probes are tiny and still very infrequent). _time=240 will send a probe after 4 mins of idle connection instead of the default 2 hours, undercutting the CGNAT timeout. _intvl=60 and _probes=120 mean it will send 120 probes 60 seconds apart (2 hours worth) before considering the connection dead. This will keep it alive for at least 2 hours, but also allows us to have the best of both worlds so that under a nice NAT it keeps the old behaviour, e.g if I temporarily lose my network the SSH connection is still valid after 2 hours, but under CGNAT it will at least not drop the connection after 5 mins so long as I keep my computer on and don't lose the network. There are also some SSH client keepalive settings but I'm less familiar with them.

anthk 7mo ago
Check Mosh. It supports these kind of cuts and it will reconnect seamlessly. It will use far less bandwidth too. I successfully tried it with a 2.7 KBPS connection.
7mo ago

fragmede 7mo ago

Just ssh to funky.nondeterministic.computer to test it out!

tdeck 7mo ago

You don't need to actually open the menu either. Just hit enter, tilde, ., enter.

aa-jv 7mo ago

I last used this menu about 20 years ago when a dialup modem was the only way to roll, and have pretty much forgotten about it since the days of always-on direct to the desktop TCP/IP ..

bramgn 7mo ago

Be sure to hit enter before you start typing `~.`. It only works on a new line

ranger_danger 7mo ago

If you regularly have to deal with hung connections or slow/unreliable links, I suggest trying out mosh. https://mosh.org/ https://mosh.org/

a96 7mo ago

Probably getting closer to 30 than 25 for me. And I used rsh before that where guess what was used to escape the input. https://en.wikipedia.org/wiki/Berkeley_r-commands https://en.wikipedia.org/wiki/Berkeley_r-commands