I remember my first days with Linux/Unix and being taught about man and apropos and info. But somehow I could never find anything useful via apropos!
With many years of insight, I think I probably never updated the database.
bombcar 5 hours ago [-]
Reminds me of the old canard of 'man woman'
6 hours ago [-]
saguntum 5 hours ago [-]
man ssh_config is even more interesting and hidden
ProxyCommand is fun
smoyer 7 hours ago [-]
HN as a tabloid ... After all enquiring minds want to know!
paulddraper 2 hours ago [-]
It’s been a while since I’ve heard RTFM
senectus1 7 hours ago [-]
hahaha made me laugh, thanks :-D
7 hours ago [-]
andrewflnr 2 hours ago [-]
I've been using the ~. shortcut for a while, but somehow escaped learning about the help menu.
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.
piccirello 7 hours ago [-]
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.
tomxor 6 hours ago [-]
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:
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.
anthk 19 minutes ago [-]
Check Mosh. It supports these kind of cuts and it will reconnect seamlessly. It will use far less bandwidth too.
I successfully tried it with a 2.7 KBPS connection.
iberator 20 minutes ago [-]
putty is sending packets for network up since like forever
snvzz 3 hours ago [-]
Note this is only an issue if not using IPv6.
CGNAT is for access to legacy IPv4 only.
rnhmjoj 1 hours ago [-]
Well, for different reasons, but you have similar issues with IPv6 as well. If your client uses temporary addresses (most likely since they're enabled by default on most OS), OpenSSH will pick one of them over the stable address and when they're rotated the connection breaks.
For some reason, OpenSSH devs refuse to fix this issue, so I have to patch it myself:
--- 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;
dsl 1 hours ago [-]
This is a very common misconception. The issue is not IPv4 or CGNAT, it's stateful middleboxes... of which IPv6 has plenty.
The largest IPv6 deployments in the world are mobile carriers, which are full of stateful firewalls, DPI, and mid-path translation. The difference is that when connections drop it gets blamed on the wireless rather than the network infrastructure.
Also, fun fact: net.ipv4.tcp_keepalive_* applies to IPv6 too. The "ipv4" is just a naming artifact.
lathiat 7 hours ago [-]
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.
Izkata 4 hours ago [-]
Also helps with auth failures, I've used it several times with co-workers who can't figure out why their ssh key isn't working. It lists the keys out and some extra information.
sirfz 7 hours ago [-]
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
tdeck 1 hours ago [-]
You don't need to actually open the menu either. Just hit enter, tilde, ., enter.
fragmede 4 hours ago [-]
Just ssh to funky.nondeterministic.computer to test it out!
TacticalCoder 6 hours ago [-]
> 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.
wolvoleo 7 hours ago [-]
I use that every day but it's the only one I know by heart lol
shmerl 7 hours ago [-]
I've been using ~. on hung ssh connections for a while.
vzaliva 6 hours ago [-]
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 ~?
BenjiWiebe 5 hours ago [-]
It'll still work. OpenSSH doesn't care about output (for ~ stuff), only input, so if you type <enter>~. it will close the connection.
krautsauer 3 hours ago [-]
Does not for me, not even with busybox sh and no funky escape codes in PS1 at all. It does with cat or yes running, so just something being output is not the problem… Hm.
vzaliva 4 hours ago [-]
It does not. open ssh linux to mac, typing ~ just types it on fish shell prompt. It works after`cat` followed by ENTER
ploxiln 1 hours ago [-]
Just type <enter> without cat, your shell will show you another prompt, and the ssh escape command will also work.
wrs 4 hours ago [-]
Those aren’t “secret”, they’re obviously borrowed from rsh — oh that’s right, I’m old.
aidenn0 4 hours ago [-]
And these days you need to pass "-O" to scp to have it behave like rcp.
pram 8 hours ago [-]
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.
MayeulC 7 hours ago [-]
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).
NitpickLawyer 2 hours ago [-]
> I use another little-known feature, "ControlMaster". Multiplexes multiple connections into one, it makes making " new" sessions instant
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.
ghrl 2 hours ago [-]
I'm using that as well but had issues with tunneling where it creates the tunnel in the background and terminates and so you might not know the random port it assigned or I couldn't figure out how to un-tunnel it and tunnel again to the same port. Just bypassed the control master then.
nyanchovy 6 hours ago [-]
TIL; thanks, that's interesting (and somehow escaped my 20+ years of using ssh)! As usual the gold is in the comments :-)
blueflow 8 hours ago [-]
As secret as the ssh manual.
bigstrat2003 6 hours ago [-]
"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.
olalonde 3 hours ago [-]
Wow, never knew this... That said I'm not sure if I'll remember using it as my muscle memory is already trained to kill hung processes via ctrl-b s, ctrl-k, ctrl-b x (in tmux).
juancn 6 hours ago [-]
It's like Ctrl + ] on telnet.
The good old times!
Lasang 6 hours ago [-]
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.
alwillis 4 hours ago [-]
It's not hidden or undocumented; it's in the man page.
FYI, you can kill forwarding tunnels with -KD portnum in that commandline too.
nirui 5 hours ago [-]
Secret Menu -> Escape Characters
I really hate it when people just rename terms. It made it harder to search properly for better answers.
_kst_ 8 hours ago [-]
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.
MayeulC 7 hours ago [-]
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.
greyface- 7 hours ago [-]
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.
singlow 5 hours ago [-]
I find it odd that you would have commands in ~/bin but not have it be the highest priority in your PATH. I use ~/.local/bin, but would never type it because i wouldn't have bins that overlap shell commands and no other path would have priority.
greyface- 4 hours ago [-]
Usually, it is. IIRC, this was when I was just setting up my environment on a new host, after I had populated ~/bin but before I restarted my shell to pick up PATH modifications.
wolvoleo 7 hours ago [-]
SSH does it pretty well though. Never once have I done it by mistake.
jasomill 5 hours ago [-]
I'd guess this is because it only works in ssh PTY sessions. So it would have no effect on tunneling or when piping arbitrary data through ssh to a non-interactive remote command (unless you use the -t switch to force PTY allocation even when stdin is not a TTY).
wolvoleo 5 hours ago [-]
No I don't think so. I mainly and pretty much constantly use SSH for logging in. I'm not one of those 'cattle not pets' guys lol.
And when I port forward I usually don't even tunnel it over SSH because all my stuff is on tailscale so it's also encrypted.
Jackpot if they're just a pointer to an 'info' page.
With many years of insight, I think I probably never updated the database.
ProxyCommand is fun
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.
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:
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.
CGNAT is for access to legacy IPv4 only.
For some reason, OpenSSH devs refuse to fix this issue, so I have to patch it myself:
The largest IPv6 deployments in the world are mobile carriers, which are full of stateful firewalls, DPI, and mid-path translation. The difference is that when connections drop it gets blamed on the wireless rather than the network infrastructure.
Also, fun fact: net.ipv4.tcp_keepalive_* applies to IPv6 too. The "ipv4" is just a naming artifact.
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.
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 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.
The good old times!
Here's 15-year old HN link about it: http://grack.com/blog/2011/02/23/ssh-escape-sequences-or-don...
I really hate it when people just rename terms. It made it harder to search properly for better answers.
I find it convenient not to have to worry about accidentally entering escape characters. YMMV.
And when I port forward I usually don't even tunnel it over SSH because all my stuff is on tailscale so it's also encrypted.