
Terminating a Frozen SSH Session - erredois
https://www.remembertheusers.com/2020/07/0668-terminating-a-frozen-ssh-session.html
======
js2
So much to learn, if only people would read man pages.

[https://linux.die.net/man/1/ssh](https://linux.die.net/man/1/ssh)

See the "Escape Characters" section.

(Linux historically has terrible man pages compared to say the old SunOS man
pages of yore, but the ssh man page is complete.)

(When I was first introduced to Unix, it was on SunOS. One day, I typed "man
intro" [1]and about 8 hours of man page reading later, decided to call it a
day.)

1\.
[https://docs.oracle.com/cd/E19683-01/816-0210/6m6nb7m45/inde...](https://docs.oracle.com/cd/E19683-01/816-0210/6m6nb7m45/index.html)

(Here's another thing you can do. Look at the list of commands in your PATH.
I'll bet you're not familiar with all of them. Some will have curious names.
Why not see what they do?)

~~~
thephyber
> if only people would read man pages

Sounds suspiciously like "if only people would read Terms of Service". A
single document, given lots of leisure time, is fine. The aggregate of all man
pages (or in my example ToS docs) is ridiculous.

I would argue that man pages are good if you know what you're looking for. The
hardest part about modern tech stacks is knowing which layer (therefore which
M) to RTFM.

~~~
bonestormii_
I mean, man pages are searchable, immediately accessible, usually callable by
the same name as the binary, somewhat standard in their formatting, and
frequently exhaustive in at least the interface of the program. It's about 10x
easier to `man someprogram` than it is to open a browser and google for some
random answer in a lot of cases. What flag is it again? How do I format that
string again?

Man pages are part of what I love about the unixy CLI experience. That is, in
my opinion, a far cry from a hostile document like a ToS that is asking you to
consent to things after going out of their way to be impenetrable and opaque.

The man pages are just trying to help you! Love them.

~~~
doliveira
What about googling "man somecommand" in the browser?

~~~
nix23
No (direct) google needed:

[https://linux.die.net/man/](https://linux.die.net/man/)

------
deeblering4
Also, the ~ needs to be the first on the line, so the key sequence is often
<return>~. to kill a hung session.

And good idea to ctrl-c ctrl-U before hitting return, just in case there was a
command in the buffer and the session wasn’t actually hung up.

------
neilv
The most comfortably I ever saw a person wield the telnet/rsh/ssh escape
sequences was when I was an intern, visiting a Cray division, to port some
software. He was juggling multiple hops, to get to a machine across the room,
with the panels off.

I'm guessing that juggling multiple hops might've been ordinary in Internet-
based supercomputing center practice at the time. Including through terminal
servers?

Though it would've been aesthetically cooler to sit at the console of a front-
end processor of a Cray or Connection Machine.
[https://en.wikipedia.org/wiki/Maxell#/media/File:Blown_Away_...](https://en.wikipedia.org/wiki/Maxell#/media/File:Blown_Away_Guy_-
_Maxell_ad.jpg)

(I ended up creating some multi-hop-to-go-10-feet situations myself at that
company, such as for crudely gatewaying from our main Sun-dominated
engineering LAN, to some porting systems, such as VAXstations that were only
on DECnet. Half of the engineers had been developing things like LAN-accessed
in-circuit emulators, borrowing other workstations' tape drives through rsh as
part of a local Unix command pipeline, etc., so they were also unusually
comfortable with the hops.)

~~~
mikehotel
If you are doing multiple hops, it’s good to know you can stack tildes to
target a specific link in the chain. So if the second ssh connection is hung,
you can press ~ ~ . to terminate that ssh connection, and not the first one.

~~~
flingo
See also: detaching from, or quitting a tmux/screen session.

------
farnsworth
> To view a list of available options with this escape trigger type `~.`

That should be `~?`

~~~
pronoiac
Agreed, in markdown:

`~`.

I might follow it with a comma and more of a sentence, for clarity or safety.

~~~
farnsworth
I mean the command to show the "help message" is actually be tilde then
question mark.

------
totetsu
It's ctrl+c ctrl+d ↵ ↵ ~.

~~~
JadeNB
↑↑↓↓←→←→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:

> 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 ….

~~~
icedchai
~? gets you a list of options ~. terminates the connection

Sometimes plain ~. just doesn't work, depending on what state your connection
is in.

~~~
jolmg
> Sometimes plain ~. just doesn't work, depending on what state your
> connection is in.

I can't imagine what state that would be. It should work even if the remote
machine is completely unresponsive.

~~~
icedchai
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.

~~~
jolmg
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.

------
0xdeadb00f
Is this an openSSH thing and therefore an OpenBSD "thing"? I only ask because
openBSD's `cu` uses the same ~. escape to exit out of a serial/tty connection.

I honestly had no idea ssh implemented the same escape until I read this.

------
WatchDog
Annoyingly the (not-ssh) AWS session manager cli doesn't seem to implement
this.

~~~
acdha
I use the optional approach for using it as a SSH ProxyCommand because it’s
nice not to have the fidelity gaps like this.

------
godelski
Btw, this doesn't work in zsh. It does work in bash. But I just lost my
session from typing `~.` Don't even have to press enter!

~~~
yjftsjthsd-h
Weird - it works for me, and it should be totally in the ssh client; I can't
even see where the shell is involved. Are you doing something weird with key
bindings? Does it work if you temporarily run without your zsh config?

------
sam_lowry_
Use mosh and never terminate a ssh session again.

------
riffic
tilde dot is life.

------
traceroute66
Am I missing something here ? Surely all the author of the blog post needs to
do is put : ServerAliveInterval X ServerAliveCountMax Y In their client ssh
config file ? (Where X & Y are values that meet their needs)

~~~
jolmg
The issue is that by the time you learn you need that or that your X and Y
didn't suffice, you've already got a hung connection. So, now you want to
restart the connection, maybe adding those options, but Ctrl+C is not killing
ssh because it's trying to pass that to the server, too. So what do you do?
Terminate with `~.`, then you can add `-o ServerAliveInter=X`, etc.

Without the escape sequences, your options are to use another terminal to
`kill` the ssh client, or kill the whole terminal and start ssh in another.
The problem with the former is that it might imply having to login again into
the machine that has the ssh client. The problem with the latter is that you
might be in multiple nested ssh sessions after having jumped through various
servers, and closing the terminal kills everything instead of just the one
that got hung.

