Terminating a Frozen SSH Session | Hacker News Reader

Terminating a Frozen SSH Session

remembertheusers.com

55 pointserredois37 comments

So much to learn, if only people would read man pages.

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

(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?)

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

In the creators' defense, man has several methods to figure out what you're looking for. And this isn't modern, it came out around 1971 :)

The first is "apropos" or "man -k". You ask for a keyword and maybe a section and it lists relevant pages.

The second is intro pages. "man 1 intro" tells you about user commands. "man 2 intro" about system calls, and so on.

Third is the "SEE ALSO" lists. Once you find something relevant you start chasing rabbit holes.

And finally "man man" of course.

When I was at UCB in the 80's I regularly read the man pages. Learned so much. So, I would definitely disagree. I think it's an excellent way to learn about *nix and what it offers.

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.

What about googling "man somecommand" in the browser?

No (direct) google needed:

https://linux.die.net/man/

Section 7 of the manual pages contains some gems indeed. I was unaware of intro(7)!

In addition to exploring your PATH, here is a nice proxy for a list of useful concepts:

    man -s 7 -k ''

> if only people would read man pages.

I don't like this line of reasoning, because people did read the manual. These escape characters are on the 7th page (on my terminal) and are not a feature needed to used to get the service. Most people just need to connect, maybe get an X server. That's it.

The reason I don't like the line of reasoning is because it is similar to "You should read and memorize the entirety of Python documentation before you begin programming." This is both absurd and elitist. The reason posts like this are helpful is because human memory and attention don't work like that. It is more natural to learn things as they are required (man pages are not ordered in terms of most commonly used commands, nor should it be. Man pages are a reference page designed for a time before stackexchange existed, and they are great) because you shouldn't just memorize things you aren't going to use, and if you don't use them you will forget.

TLDR: No one likes the wizard that scoffs "RTFM," it isn't helpful.

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.

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

(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.)

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.

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

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

That should be `~?`

Agreed, in markdown:

`~`.

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

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

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:

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

~? 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".

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

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.

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.

https://www.sans.org/blog/using-the-ssh-konami-code-ssh-cont...

one <cr> does it for me and no ctrl+c/d needed

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.

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

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

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!

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?

It works in ZSH; press Enter first. (Enter, ~, .)

Use mosh and never terminate a ssh session again.

tilde dot is life.

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)

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.

Reply on news.ycombinator.com