Many Linux man pages have the thoroughness of a fortune cookie, so I can understand the skepticism.

Jackpot if they're just a pointer to an 'info' page.

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!”

I still struggle with the fact that I was (or delusional) an effective C programmer "back in the day" (before google etc) and all we had was "man" to look up std/x11 system calls.

Now I am dismayed with juniors who can't even be bothered to use google (or llms) to look up stuff on their first hiccup.

#include <old-man-shouting-at-clouds>

   #include <old-man-shouting-at-clouds.h>

  #define _POSIX_C_SOURCE 1
  #include <old-man-shouting-at-clouds.h>

Who doesn’t want you to know? Well, obviously, the man. That’s why you type man ssh, you’re forcing the man to tell you what he knows.

man ssh_config is even more interesting and hidden

ProxyCommand is fun

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

It’s been a while since I’ve heard RTFM

hahaha made me laugh, thanks :-D

How's that supposed to help? The ssh man page is about as close as you can get to a Platonic example of "uninformative pretend-documentation".

> typing on a line, backspacing all the way to the start and then typing ~ also sends a literal tilde

for the younger readers, yes, because in terminal echo mode, "backspacing" does not clear your terminal line buffer, those characters backspaced are already sent on the line. if you ever seen a misconfigured terminal, it hints what's going on, like:

user@host$ ls ~/^?^?^?^?^?~/a.out

^? is backspace's control char.

that is ssh watches what you type, not what is on the screen (terminal).

The drawback is that if you think your session is hanging and want to bail with ~., you have to press enter, which might actually make it to the server and execute something.

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 effective NAT they usually have normal TCP timeouts due to being less resource constrained. Another nice benefit of this method is you can move between physical networks and your connection doesn't die... If you use Tailscale then you already have this in a more direct way.

Another is to tune the tcp_keepalive kernel parameters. Lowering the keepalive timeout to be less than the CGNAT timeout will cause keepalive probes to 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:

  # Keepalive frequently to survive CGNAT
  net.ipv4.tcp_keepalive_time   = 240 
  net.ipv4.tcp_keepalive_intvl  = 60
  net.ipv4.tcp_keepalive_probes = 120

This is really a misuse of these settings, they are supposed to be for checking TCP connections are still alive and clearing them up from the local routing table. Instead the idea is to exploit the probes by sending them more frequently to force idle connections to stay alive in a CGNAT environment (dont worry the probes are tiny and still very infrequent).

_time=240 will send a probe after 4 mins of idle connection instead of the default 2 hours, 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 will keep it alive for at least 2 hours, but also allows us to have the best of both worlds so that under a nice NAT it keeps the old behaviour, e.g if I temporarily lose my network the SSH connection is still valid after 2 hours, but under CGNAT it will at least not drop the connection after 5 mins so long as I keep my computer on and don't lose the network.

There are also some SSH client keepalive settings but I'm less familiar with them.

    Host *
        ServerAliveInterval 25

    --- a/sshconnect.c
    +++ b/sshconnect.c
    @@ -26,6 +26,7 @@
     #include <net/if.h>
     #include <netinet/in.h>
     #include <arpa/inet.h>
    +#include <linux/ipv6.h>
     
     #include <ctype.h>
     #include <errno.h>
    @@ -370,6 +371,11 @@ ssh_create_socket(struct addrinfo *ai)
      if (options.ip_qos_interactive != INT_MAX)
        set_sock_tos(sock, options.ip_qos_interactive);
     
    + if (ai->ai_family == AF_INET6 && options.bind_address == NULL) {
    +  int val = IPV6_PREFER_SRC_PUBLIC;
    +  setsockopt(sock, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, &val, sizeof(val));
    + }
    +
      /* Bind the socket to an alternative local IP address */
      if (options.bind_address == NULL && options.bind_interface == NULL)
        return sock;

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.

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

You don't need to actually open the menu either. Just hit enter, tilde, ., enter.

I last used this menu about 20 years ago when a dialup modem was the only way to roll, and have pretty much forgotten about it since the days of always-on direct to the desktop TCP/IP ..

Just ssh to funky.nondeterministic.computer to test it out!

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

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

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

Same with me, I'll still instinctively go for ~. when a connection has hung / dropped (usually because of a NAT via a rebooted firewall), but never even considered how ~ doesn't normally cause an issue. Never knew it had to be immediately following a newline. Also never knew about the other options, ~^Z in particular looks useful.

I wonder if anyone still remembers the ctrl-[ sequence in telnet. I think I only ever used the quit command in that though.

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

    Host *
    EnableEscapeCommandline yes

    cat<Enter>~.

And these days you need to pass "-O" to scp to have it behave like rcp.

Laughs in uucp!bangpath.

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

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

Unlike CTRL ], at least ~. doesn't require that I press two modifiers at the same time ... CTRL ALTGR $. Because people who define those kinds of shortcuts never consider how they might work on non-QWERTY layouts.