

How to kill an unresponsive ssh session - ique
http://www.laszlo.nu/post/553591402/how-to-kill-an-unresponsive-ssh-session

======
rit
There's a whole bunch of other characters you can call prefixed with the Tilde
(~) as well. My favorite is often ~^Z (That's tilde+Control-Z), which puts the
SSH session in the background and drops you back to the host machine. You can
hit ~? for a list. One other very, very useful one is ~#, which lists all
forwarded connections - if you've setup X11 Forwarding or any port forwarding
it lists the details for you.

Of course - if you're multihopping this all works as well. You'll need to add
a ~ for each machine in the loop though.

E.g. if I hop from workstation -> server1 -> server 2... ~^Z drops me to
workstation shell. ~~^Z drops me to server 1 shell.

------
oakenshield
It's like people don't know about man pages anymore. Google is the man page...
only you may not get your answer on the first try.

~~~
slmbrhrt
You can add Unix Manpages to your "Subscribed Links" in your Google
preferences, and then you _will_ get your answer on the first try.

~~~
milkshakes
Thanks!

------
illumin8
Be careful if you're a couple sessions deep.

The proper way to kill a session if you're connecting from one server to
another is ~~. (two tildes). Otherwise you'll kill your first session and lose
access to the other session you connected to from it.

Also, as others have mentioned, <ENTER> first just to make sure you're on a
new line.

------
timmorgan
I learn something wonderful almost every day on HN.

I just tried this, and it seems just ~. works fine (no newline needed).

~~~
shabble
quoting from the manpage:

"The escape character is only recognized at the beginning of a line."

so you'll generally need that newline to allow the escape to be detected, even
though it's not technically part of the sequence.

------
jayliew
On a related note, for folks using PuTTY.exe on Windoze to SSH, if you
sometimes accidentally hit CTRL-S and "lock up" the session, hit CTRL-Q to
recover.

 _Apparently CTRL+S actually does XOFF, which means the terminal will accept
key strokes but won’t show the output of anything. It will appear as if your
terminal is dead when it’s really just waiting to be turned back on. The fix?
Simply press CTRL+Q to turn flow-control on (XON). If you pressed a whole
bunch of keys before pressing CTRL+Q, you’ll see the output from those
keystrokes._

credit: <http://raamdev.com/recovering-from-ctrls-in-putty>

------
jrockway
This is why people on IRC always say things like:

    
    
      <jrockway> My net connectio*#$&*#^B^B^H~.~.~.
      <jrockway> .~.
      <jrockway> MY NET CONNECTION SUCKS
    

Gotta have a newline before entering the escape sequence. Annoying when your
session is not as dead as you think it is.

------
pavel_lishin
Why is a Scandinavian asshole blocking the article?

<http://grab.by/42AG>

~~~
andrelaszlo
Hahaha. Sorry about that. He's gone now.

I have no idea about who Håkon Wium Lie is though. That must be some kind of
misunderstanding.

Thanks for all the comments.

------
Estragon
I've known about ~. as a way to end an ssh session for years. Unfortunately,
it only works about 50% of the time. (It fails when the current session is
piggy-backing on another session to the same host.)

~~~
spudlyo
You just need to escape the tilde, try ~~.

------
yesimahuman
Any chance these sessions are just on flow control and are actually not
unresponsive (Ctrl-s/Ctrl-q)?

------
th0ma5
for me this is a side effect often of starting something that hangs on to a
standard in, out, or error. when starting server processes, it can be nice to
do the full thing: nohup CMD > stdout.log 2> stderr.log < /dev/null &

------
hackermom
The SSHD - at least OpenSSH's - also kills mute sessions when it notices they
have been completely silent for a while.

~~~
djcapelis
I believe this is both configurable and not the OpenSSH default.

Your distro likely enabled this, some enjoy messing with the sshd_config. (I
believe Redhat and Redhat derived distros tend to enable this setting, but it
is _not_ the openssh default behavior.)

~~~
dfox
In most cases when I have seen this behavior it was not caused by sshd, but by
some overly intelligent device (eg. Alcatel's ADSL modems do this) along the
way.

------
mml
derp.

