Actually, joking aside, your advice doesn't seem to match the two-character string `~.` in the article. (Maybe your advice is meant to try first to see if the SSH session is really frozen, or if the remote shell is responding?) On the other hand, the article itself seems of two minds about what that two-character string does:
To view a list of available options with this escape trigger type `~.`.
To force terminate a frozen SSH session, press `~.`.
(As far as I can tell, in each case, one of those periods is the sentence ender and one is the command to terminate.) Unfortunately, I don't have anywhere to SSH to to check ….
Preceding with a single return is sometimes necessary because the escape sequence is only recognized at the beginning of a line. Not sure what the other incantations are for but may deal with situations where the ssh session is embedded in another terminal.
Correct. This is just my muscle memory, but I guess it's from checking if I can just terminate a program first, then clearing any input so the escape char can come at the beginning of the line. I probably learned this when using ssh sessions embedded in a GNUscreen session running on a jump host, where you had to specify a different character, or maybe send ~~. . I think I had fun standing up ad-hoc port-fowardings with ~C too.
I agree that it "should", but I've definitely had it not work. It may actually be a problem with the state of my local terminal under macOS. I've had to resort to "kill -9"ing my ssh from another window in some situations.
I can only imagine it appearing it not working by hitting Ctrl-s, which freezes terminal output. Killing ssh wouldn't solve that though. Besides unfreezing it with Ctrl-q, you'd have to kill the whole terminal.
Comments
It's ctrl+c ctrl+d ↵ ↵ ~.
↑↑↓↓←→←→BA?
Actually, joking aside, your advice doesn't seem to match the two-character string `~.` in the article. (Maybe your advice is meant to try first to see if the SSH session is really frozen, or if the remote shell is responding?) On the other hand, the article itself seems of two minds about what that two-character string does:
(As far as I can tell, in each case, one of those periods is the sentence ender and one is the command to terminate.) Unfortunately, I don't have anywhere to SSH to to check ….
Preceding with a single return is sometimes necessary because the escape sequence is only recognized at the beginning of a line. Not sure what the other incantations are for but may deal with situations where the ssh session is embedded in another terminal.
Correct. This is just my muscle memory, but I guess it's from checking if I can just terminate a program first, then clearing any input so the escape char can come at the beginning of the line. I probably learned this when using ssh sessions embedded in a GNUscreen session running on a jump host, where you had to specify a different character, or maybe send ~~. . I think I had fun standing up ad-hoc port-fowardings with ~C too.
~? gets you a list of options ~. terminates the connection
Sometimes plain ~. just doesn't work, depending on what state your connection is in.
~<Ctrl-Z> should suspend the ssh process and drop you back in the shell, where you can "kill %1".
I can't imagine what state that would be. It should work even if the remote machine is completely unresponsive.
I agree that it "should", but I've definitely had it not work. It may actually be a problem with the state of my local terminal under macOS. I've had to resort to "kill -9"ing my ssh from another window in some situations.
I can only imagine it appearing it not working by hitting Ctrl-s, which freezes terminal output. Killing ssh wouldn't solve that though. Besides unfreezing it with Ctrl-q, you'd have to kill the whole terminal.
https://www.sans.org/blog/using-the-ssh-konami-code-ssh-cont...
one <cr> does it for me and no ctrl+c/d needed