Discussion

JavaScript is not available.

0xbadcafebee: [delayed]

pram: Yep the menu is handy for ssh tunneling. Maybe not a lot of people doing that these days though with stuff like dev tunnels and Tailscale.

_kst_: That doesn't do much good if you set `EscapeChar` to `none` in `.ssh/config`.I find it convenient not to have to worry about accidentally entering escape characters. YMMV.

piccirello: I've been using SSH for ~15 years and never knew about these escape sequences. I'm eagerly awaiting my next hung session so that I can test `~.`. It's much nicer than my current approach of having to close that terminal window.

shmerl: I've been using ~. on hung ssh connections for a while.

lathiat: Have been using that weekly since probably 20 years. Will change your life :)My other favourite is I very often SSH with -v to figure out why the connection is hanging, you rapidly figure out if DNS is failing, the TCP connection doesn't open, it does open but no traffic flows at all or it opens and SSH negotiation starts but never finishes. You can learn a lot just from this about what is wrong.

wolvoleo: SSH does it pretty well though. Never once have I done it by mistake.

MayeulC: Note that it only works after pressing enter, so the odds are slim. In practice, I don't think I ever hit it by accident.

wolvoleo: I use that every day but it's the only one I know by heart lol

smoyer: HN as a tabloid ... After all enquiring minds want to know!

sirfz: You can even chain them if you have deep ssh connections (i.e. ssh from one instance to another). I think it would be ~~. to terminate the 2nd hop.Edit: it's already explained in the OP

senectus1: hahaha made me laugh, thanks :-D

greyface-: I have noticed it while running ~/bin/some_command. The ~ doesn't echo until I also type the /. It doesn't cause any misbehavior because there is no binding for ~/ but can be slightly surprising.

juancn: It's like Ctrl + ] on telnet.The good old times!

TacticalCoder: > It's much nicer than my current approach of having to close that terminal window.You can also just kill the ssh process (say from another terminal). That way you get to keep your terminal window. And this works with everything "blocking" your terminal, not just ssh.

Lasang: Hidden or undocumented features like this always have a strange appeal. Part of it is nostalgia for older software where small Easter eggs or experimental features would sometimes ship in production builds.

MayeulC: I typically just create a "new" connection in a separate tab when I want to add tunneling.I put new in quotes because I use another little-known feature, "ControlMaster". Multiplexes multiple connections into one, it makes making " new" sessions instant (can also be configured to persist a bit after disconnecting). Also useful for tab-completing remote paths. It does not prompt for authentication again, though. And it's a bit annoying when the connection hands (can be solved with ssh -o close, IIRC).

nyanchovy: TIL; thanks, that's interesting (and somehow escaped my 20+ years of using ssh)! As usual the gold is in the comments :-)

joecool1029: FYI, you can kill forwarding tunnels with -KD portnum in that commandline too.

imwally: I blew a few minds a week ago when I told my younger coworkers about man pages. I hit ‘em with the `man man` and one dude was like “whoa!”

tomxor: If hung SSH connections are common it's likely due to CGNAT which use aggressively low TCP timeouts. e.g. I've found all UK mobile carriers set their TCP timeout as low as 5 minutes. The "default" is supposed to be 2 hours, you could literally sleep your computer, zero packets, and an SSH connection would continue to work an hour later, and generally speaking this is still true unless CGNAT is in the way.If you are interested there are a few ways you can fix this:Easiest is to use a VPN, because the VPN's exit node becomes the NAT they usually have normal TCP timeouts due to being less resource constrained.Another is to tune the tcp_keepalive kernel parameters. By default these are set up to send probes after 2 hours to see if the other side is still there. If you lower this to be less than the CGNAT timeout then the TCP probes will help prevent CGNAT from dropping the connection even while your SSH connection is technically idle. For Linux I pop these into /etc/sysctl.d/z.conf, I have no idea for Windows or Mac: net.ipv4.tcp_keepalive_time = 240 net.ipv4.tcp_keepalive_intvl = 60 net.ipv4.tcp_keepalive_probes = 120 time=240 will send a probe after 4 mins of idle connection undercutting the CGNAT timeout. intvl=60 and probes=120 mean it will send 120 probes 60 seconds apart (2 hours worth) before considering the connection dead - this is really a misuse of these settings, the idea is that I don't want it to drop the connection in the case that I am actually not behind CGNAT but have temporarily lost my network connection. i.e. under a nice NAT it keeps the old behaviour and I can still cleep my computer for 2 hours, but under CGNAT it will at least not drop the connection after 5 mins so long as I keep my computer on (best of both).There are also some SSH client keepalive settings but I'm less familiar with them.

vzaliva: I've used ~. for a long time but did not know about others. I know, should have read man page.Anyway, if you try it from shell prompt it is likely will not work as pressing ENTER shows the next prompt. Try `cat` followed by ENTER and then ~?

blueflow: As secret as the ssh manual.

bigstrat2003: "secret" not in the sense that it's hidden, but that most people won't know about it. Because approximately nobody actually reads man pages in their entirety, they just get in to find out how a specific flag works and then get out.

saguntum: man ssh_config is even more interesting and hiddenProxyCommand is fun

BenjiWiebe: It'll still work. OpenSSH doesn't care about output (for ~ stuff), only input, so if you type <enter>~. it will close the connection.

bombcar: Reminds me of the old canard of 'man woman'