"It's easier to ask an AI" can be true without implying that manpages are bad.
However, "man" the tool does have issues, and one of them bit me just now.
So, I didn't know about openssh client escapes like ~?. I thought, "surely that's in the manpage?" I opened the manpage (in less) and searched for "\~\?". No hits.
Of course, escape characters are documented in the manpage, and the string "~?" does appear. Why didn't search find it? Because man, in its infinite wisdom, decided to render every instance of "~" as some bizarre unicode not-tilde, which is visually similar but totally impossible to grep for.
This has also bitten me in the past with dash. DASH. A character that is critically important when documenting invocation options. man loves to convert it into something that looks like dash, prints like dash, but doesn't come up in search.
I'm sure there is a way to turn this "feature" off, and I'm about to spend a bunch of time figuring out what it is. But this is documentation for command-line tools. Silently destroying our ability to grep it should NOT be the default.
/<ctrl-r>~?I miss most.
It sounds like some distributions do have this fixed in their default settings. I'm on Cygwin 3.6.6; maybe it's mostly a Cygwin thing.
You'll be happiest.
You might also consider seeing if it's any different in WSL. Or you could, you know, just use Linux ;P
though you have to be aware of the escapes for regex, so \~?
Another neat thing I noticed while playing with it just now: there's an option to enter ~ twice to send a literal ~, but usually you don't have to do this when typing something like 'ls ~' in a regular session. Not only does the ~ have to be the first character on a line to start an escape sequence, but typing on a line, backspacing all the way to the start and then typing ~ also sends a literal tilde. It only triggers the escape sequence if the ~ is the chronologically first character after a newline (or first in the session), which is an unlikely thing to type into a shell in a normal session. Good choice of UI, both the character and the state machine.
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).
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
_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.
Depends on whether your sockets survive that, though. Especially on Wi-Fi, many implementations will reset your interface when sleeping, and sockets usually don't survive that.
Even if they do, if the remote side has heartbeats/keepalive enabled (at the TCP or SSH level), your connection might be torn down from the server side.
CGNAT is for access to legacy IPv4 only.
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.
That lets you `ssh -vvvv` to a host then once you've figured out the issue use ~V to decrease verbosity so that debug messages don't clutter your shell.
Edit: it's already explained in the OP
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.
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 ~?
I wonder if anyone still remembers the ctrl-[ sequence in telnet. I think I only ever used the quit command in that though.
The point of the return is to prime it to accept the start of a new escape sequence. Presumably the idea is that `~.` is not completely unlikely to occur as part of text entered remotely, but less so at the beginning of a new line.
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).
Is this what secureCRT used as well? I remember this being all the rage back when I used windows, and it allowed this spawn new session by reusing the main one.
I use it when I need to crash a kernel on purpose to test kdump over the network.
You can also send commands to the simulated console of a VM under libvirt with "virsh connect". But I don't think you can send a break to the kernel with that.
~.
I guess you could call it a "secret" or at least "not super-well known (to people who aren't Linux 'experts')."
alias ssh="echo 'dont forget: ~? for SSH escapes!'; /usr/bin/ssh "
The good old times!
Running on 443 means it will blend in with https traffic, making it much more difficult for them to detect and block (I've never actually seen anywhere that can detect/block it - you'd need to be doing deep packet inspection on encrypted traffic) :)
I really hate it when people just rename terms. It made it harder to search properly for better answers.
What I now have: ~B
What I really need: a way to stop long-running SSH connections from freezing
I find it convenient not to have to worry about accidentally entering escape characters. YMMV.
$ man sshJackpot if they're just a pointer to an 'info' page.
Case in point: the jq man page is incredible and everyone I know instead runs off to google or stackoverflow or Claude to answer simple questions
ProxyCommand is fun
It's really great for ops teams where you want to give ssh access and manage it from github teams without needing a complex system.
See "escape characters" under man ssh.
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>Here's 15-year old HN link about it: http://grack.com/blog/2011/02/23/ssh-escape-sequences-or-don...
https://die.net and https://ss64.com are sites I’ve been recommending for years.