6 ms·
How to kill an unresponsive ssh session
- oakenshield 16y agoIt'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.
- timmorgan 16y agoOn rare occasion, Google does give me a man page, but more often than not, someone has answered my bone-head question in simple terms in a forum somewhere.
- oakenshield 16y agoOh, I wasn't dissing the Google method. I'm just saying that if people bothered to read the whole manpage for some application just once, they'd know of the "cool" features they might need, instead of waiting until someone posts it on HN or reddit.
- pyre 16y agoThe issue being that not all manpages are created equal. Some only document 2% of the program's functionality, others drone on and on about insignificant features, others are just unclear in their wording. It makes it so that people only consult the manpages when they need to. That said, reading the manpages for something that you use all the time like ssh is a good idea. (Though if you use zsh, I'll take a bit to go through all of the documentation)
- wtn 16y agoThat's one reason to favor BSD over the ill-advised GNU/Linux info page movement. The BSDs take man pages quite seriously.
- ajross 16y agoPeople don't read documentation. I clicked on this thing thinking "No, it's can't just be about the ~ escape, right? There's some content here.... Right?" I lost. It's a blog post about a documented feature. Tune in next week for the "-j" option to tar!
- onedognight 16y agoSeems you haven't read your man pages recently. -j is deprecated. Yes, tar has implemented auto-detection after all these years! tar xf linux.tar.bz2 Brought to you by "A note from a random man page".
- ajross 16y agoUh... my man page says nothing about deprecation, it just documents its behavior. And I certainly still find it useful, in any case, for situations where autodetection won't work -- for example when you are creating an archive. Y'know, with the "-c" flag that apparently you haven't read about yet. Bazinga! (edit: What I find most interesting isn't so much that you goofed your snipe, which happens all the time. It's that someone upvoted it.)
- X-Istence 16y agoTry doing that on older Solaris's or AIX machines.
- barrkel 16y agoThat can often only help if you read the documentation before you want to anything with the program in question. For problems for which you (a) already have a solution and (b) do not know that the program has a better solution for, why would you read the man page?
- yason 16y agoThey do but nobody wants to memorize everything off some man page. There are thousands and generally, man pages are considered references where you dig up one thing at a time. Then there are man pages that are actually being studied with great care, such as bash. And even bash man page is notorious for containing an endless amount of information. You can read it several times and still you will bump into a blog post or HN comment that reveals some previously missed (but documented) bash feature. Telnet conveniently prints "Escape character is ^]" and that's why everybody knows it. I must admit it probably never occurred to me that ssh must have some sort of escaping method as well. Well, thanks to HN for that link anyway :)
- slmbrhrt 16y agoYou can add Unix Manpages to your "Subscribed Links" in your Google preferences, and then you will get your answer on the first try.
- milkshakes 16y agoThanks!
- dmm 16y agoI think people have learned not to use man pages because the man pages in GNU land almost universally suck. Check out OpenBSD's for some examples of really good documentaion
- benmathes 16y agoMy take on man pages is "If you want people to RTFM, make a better FM". (not mine originally)
- timmorgan 16y agoI learn something wonderful almost every day on HN. I just tried this, and it seems just ~. works fine (no newline needed).
- shabble 16y agoquoting 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.
- mml 16y agoderp.
- hackermom 16y agoThe SSHD - at least OpenSSH's - also kills mute sessions when it notices they have been completely silent for a while.
- djcapelis 16y agoI 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 16y agoIn 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.
- illumin8 16y agoBe 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.
- rit 16y agoThere'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.
- th0ma5 16y agofor 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 &
- pavel_lishin 16y agoWhy is a Scandinavian asshole blocking the article? http://grab.by/42AG http://grab.by/42AG
- gorm 16y agoIt's a collaboration between Norway and Sweden. Håkon Wium Lie from Norway did the CSS and Andre Laszlos did the coding part. Great article btw.
- andrelaszlo 16y agoHahaha. 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 16y agoI'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 16y agoYou just need to escape the tilde, try ~~.
- yesimahuman 16y agoAny chance these sessions are just on flow control and are actually not unresponsive (Ctrl-s/Ctrl-q)?
- jrockway 16y agoThis 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.
- jayliew 16y agoOn 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 http://raamdev.com/recovering-from-ctrls-in-putty