Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH Secret Menu

twitter.com

Post reply on HN
Print view View original

111–120 of 184 posts

Re: SSH Secret Menu

#111

Post by lxgr »

tomxor wrote: post #22
piccirello wrote: post #6

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.

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…

> you could literally sleep your computer,

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.

Re: SSH Secret Menu

#112

Post by lxgr »

snvzz wrote: post #44
tomxor wrote: post #22

Earlier quoted context omitted.

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…

Note this is only an issue if not using IPv6. CGNAT is for access to legacy IPv4 only.

Mobile carriers usually have stateful firewalls for IPv6 as well (otherwise you can get a lot of random noise on the air interface, draining both your battery and data plan), so it's an issue just the same.

The constrained resource there is only firewall-side memory, though, as opposed to that plus (IP, port) tuples for CG-NAT.

Re: SSH Secret Menu

#113

Post by lxgr »

rnhmjoj wrote: post #88
gspr wrote: post #62

Earlier quoted context omitted.

Interesting! Is there anywhere a discussion around their refusal to include your fix?

See this, for example: https://groups.google.com/g/opensshunixdev/c/FVv_bK16ADM/m/R... It boilds down to using a Linux-specific API, though it's really BSD that is lacking support for a standard (RFC 5014).

It would also seem to break address privacy (usually not much of a concern if you authenticate yourself via SSH anyway, but still, it leaks your Ethernet or Wi-Fi interface's MAC address in many older setups).

Re: SSH Secret Menu

#114

Post by nticompass »

I've had to use [Enter] ~. in SSH sessions before. I've had SSH/network get stuck and using that was the only way to kill the session (and recover).

I guess you could call it a "secret" or at least "not super-well known (to people who aren't Linux 'experts')."

Re: SSH Secret Menu

#115

Post by nticompass »

jbaber wrote: post #103
Almondsetat wrote: post #90

Earlier quoted context omitted.

The real jackpot is if they're the same as the --help command

I used to think this and used things like `help2man`. I now disagree, but throwing it out there.

I could use some "help2man." I don't know how to "man" /s

Re: SSH Secret Menu

#116

Post by withinboredom »

saguntum wrote: post #30
0xbadcafebee wrote: post #3

Find the HIDDEN SECRETS that THEY DON'T WANT YOU TO KNOW! $ man ssh

man ssh_config is even more interesting and hidden ProxyCommand is fun

You can also run commands when a user authenticates, grab their keys from github.com/username.keys, validate they're a user in a specific github group, then let them connect by outputing the keys, otherwise nothing to deny them access.

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.

Re: SSH Secret Menu

#117

Post by withinboredom »

lxgr wrote: post #112
snvzz wrote: post #44

Earlier quoted context omitted.

Note this is only an issue if not using IPv6. CGNAT is for access to legacy IPv4 only.

Mobile carriers usually have stateful firewalls for IPv6 as well (otherwise you can get a lot of random noise on the air interface, draining both your battery and data plan), so it's an issue just the same. The constrained resource there is only firewall-side memory, though, as opposed to that plus (IP, port) tuples for CG-NAT.

> otherwise you can get a lot of random noise on the air interface, draining both your battery and data plan

I highly doubt you get "random" data over ipv6. There are more ipv6 addresses than there are atoms on the planet.

Re: SSH Secret Menu

#118

Post by ranger_danger »

piccirello wrote: post #6

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.

If you regularly have to deal with hung connections or slow/unreliable links, I suggest trying out mosh.

https://mosh.org/

Re: SSH Secret Menu

#120

Post by lxgr »

withinboredom wrote: post #117
lxgr wrote: post #112

Earlier quoted context omitted.

Mobile carriers usually have stateful firewalls for IPv6 as well (otherwise you can get a lot of random noise on the air interface, draining both your battery and data plan), so it's an issue just the same. The constrained resource there is only firewall-side memory, though, as opposed to that plus (IP, port) tuples for CG-NAT.

> otherwise you can get a lot of random noise on the air interface, draining both your battery and data plan I highly doubt you get "random" data over ipv6. There are more ipv6 addresses than there are atoms on the planet.

Yes, but they're not randomly distributed across the entire number space.

For example, receiving traffic from a given address is a pretty good indicator that there's somebody there possibly worth port scanning.

And where there has once been somebody, there or in the same neighborhood (subnet) might be somebody else, now or in the future.

Post reply on HN