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?)
In addition to exploring your PATH, here is a nice proxy for a list of useful concepts:
man -s 7 -k ''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.
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.
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.
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.
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 ….
Sometimes plain ~. just doesn't work, depending on what state your connection is in.
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.)
That should be `~?`
`~`.
I might follow it with a comma and more of a sentence, for clarity or safety.
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.
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.
I honestly had no idea ssh implemented the same escape until I read this.
