[HN Gopher] Closing a stale SSH connection
___________________________________________________________________
Closing a stale SSH connection
Author : granddave
Score : 117 points
Date : 2023-04-09 16:54 UTC (6 hours ago)
(HTM) web link (davidisaksson.dev)
(TXT) w3m dump (davidisaksson.dev)
| scsibug wrote:
| Another good tip; when randomly generating passwords (especially
| for other users), filter out anything starting with a tilde to
| prevent strange behavior.
| davesmylie wrote:
| Pretty sure the answer is no, cause I've been searching for a way
| to do this for a while, but is there any way to trigger these
| escapes from script?
|
| Use case is bouncing through to an RDS that only allows access
| from specific EC2 instances. The RDS endpoint in question is
| highly specific to the EC2 - not a big deal to hit ~L and create
| the forward manually, but doing this automatically would be
| great.
| hamandcheese wrote:
| Maybe take a look at expect:
|
| https://linux.die.net/man/1/expect
| blueflow wrote:
| Primary source is the SSH manpage, Section "ESCAPE CHARACTERS".
| Read it from your terminal with the `man ssh` command.
| riffic wrote:
| tilde dot is my jam.
| dingosity wrote:
| I feel old. I remember when we moved from telnet and rlogin to
| ssh and this was in the man page. I'm also happy to learn kids
| are still using terminals and ssh.
| blueflow wrote:
| I suspect many linux users nowadays don't even know that
| manpages exist or don't want to use them. Otherwise blogposts
| like this would not exist.
| dingosity wrote:
| Well... terminal emulators. Bonus points to everyone who has an
| actual VT240 on their physical desktop.
| hsjqllzlfkf wrote:
| Why is this better than CTRL-C?
| [deleted]
| lwf wrote:
| It's client-side, so works even if the remote system is totally
| hung and did not clearly disconnect.
|
| For example, running `systemctl suspend` will not terminate
| active SSH connections before putting the destination machine
| into a sleep state, and thus Ctrl+C (which isn't processed by
| SSH) will do nothing until the remote host is woken up by some
| mechanism.
| Deukhoofd wrote:
| Generally ssh will just forward signals (SIGINT, SIGQUIT) to
| the remote host. If that side is not responsive, you can hit
| Ctrl+C all you want, but it won't do anything.
| pstrateman wrote:
| Being able to change port forwarding without reconnecting is
| really useful too.
| hartator wrote:
| I wish there is an easy way to have the reverse: a "sticky" ssh
| session.
|
| It's so annoying that the connection is lost when going to sleep
| or network issues. And the solutions to fix this are not really
| worth the effort.
| donio wrote:
| I run ssh in a loop and auto-attach to a persistent tmux
| session on the other end. I also kill ssh processes as part of
| suspend so that the new one gets launched in the loop as soon
| as we wake up.
| granddave wrote:
| Check out autossh(1)!
| rmbyrro wrote:
| [1] https://github.com/Autossh/autossh
| summarity wrote:
| et survives reboots and IP roaming, pretty much anything:
| https://eternalterminal.dev/
| rsfern wrote:
| I'm not sure about resuming from sleep, but does mosh address
| your network stability issues?
|
| https://mosh.org/
| hartator wrote:
| The main thing about Mosh is you need both on the sever and
| the client. Installing on random servers you might be ssh -in
| only once feels gross.
| devman0 wrote:
| Has Mosh crypto been reviewed? Last I checked they were
| using some custom crypto on top of UDP instead of using
| something like DTLS or QUIC. Given SSH is one of the most
| battle tested protocols out there I am wary of replacing it
| with something else.
| lwf wrote:
| https://mosh.org/#faq:~:text=Q%3A%20What%20is%20Mosh%27s%
| 20s...
|
| The cryptography is standard AES-128 in OCB3 mode. It's
| been around long enough, and has had enough security
| scrutiny to at least discover a few minor DoS
| vulnerabilities, that it isn't entirely unreviewed.
|
| For the cipher itself, see
| https://en.wikipedia.org/wiki/OCB_mode#Attacks
| gsich wrote:
| It was AES-OCB last time I looked at it. Not sure if this
| is good/bad.
| LinuxBender wrote:
| Adding for completeness sake, if using Alpine Linux the ssh
| escape sequence menu and output will not display correctly if
| using /bin/ash _from BusyBox_ as your login shell. One work-
| around is to type 'cat [Return]' and then use the escape
| sequences, or to _carefully_ change your shell to /bin/bash
| CoolCold wrote:
| With all that glory of Alpine, my personal choice is to avoid
| having it on server side, it's too much "if" with it to keep in
| my memory.
| blueflow wrote:
| Alpine Linux user here, i could not reproduce that. How does
| the used shell even matter for that? The ssh client talks to
| the tty directly, not via shell.
| LinuxBender wrote:
| This thread [1] explains the issue people run into. I ran
| into it and thus found that explanation. Verified I can still
| reproduce it on Alpine 3.17.3 _up to date on patches_
|
| For clarification regarding what I mean with _menu and output
| will not display_ the disconnect command will still work but
| there will be no feedback. So disconnecting will work but one
| won 't get the menu or feedback on changing verbosity or
| dropping to a command line or displaying forwarded
| connections, etc... and a few of the sub-commands will not
| work.
|
| [1] - https://superuser.com/questions/985437/ssh-escape-key-
| only-w...
| capableweb wrote:
| Lots of words to just say "Enter then ~."
| abdusco wrote:
| One of the most useful SSH tricks I've ever learned. I wonder if
| there's a way to detect a stale session and force reconnect when
| I turn on the computer? Like mosh[0], but with SSH.
|
| [0]: https://mosh.org/
| LinuxBender wrote:
| _I wonder if there 's a way to detect a stale session and force
| reconnect_
|
| SSH uses TCP and if the session is _gone_ it will be an invalid
| session in iptables /nftables and likely have timed out on the
| remote end depending on state table timeouts and how long your
| laptop were offline. If there were no firewall in the path then
| one could play with long SO_KEEPALIVE sessions which I have
| done in the past when rebooting datacenter-wide _diskless_ NFS
| clients and NAS 's but I dont believe this will work with SSH
| due to session keys. As you alluded to, Mosh is the best
| current way to deal with broken or roaming sessions as Mosh
| uses a nonce and is designed to be stateless.
|
| If the sshd and ssh client timeouts are high enough, a UDP VPN
| can _at times_ work around intermittent timeouts.
| chrisweekly wrote:
| > "As you _eluded_ to"
|
| should be "alluded to"; eluded: evaded / dodged, vs alluded
| to: mentioned / referred to
|
| NOT being pedantic about spelling, just trying to be helpful
| (esp. for non-native English readers).
| LinuxBender wrote:
| Thanks. I'm sure I will get it wrong again but I try.
| Another one that my subconscious types out wrong is queue
| vs cue out of habit. _Fixed in above comment._
| saurik wrote:
| You can turn on TCP keeyalive on ssh using a handful of -o
| flags if that's the behavior you prefer.
|
| https://news.ycombinator.com/item?id=5017108
| c0l0 wrote:
| If you enjoyed this article, you may also find other useful tips
| in a piece I submitted to HN a while ago on "advanced SSH usage":
| https://johannes.truschnigg.info/writing/2022-07_advanced_ss...
| navaati wrote:
| Loved your article, thank you for writing it !
| jeffrallen wrote:
| If you enjoyed this article, you may like to learn about man
| pages... Try "man man".
| tjoff wrote:
| One caveat here is the note:
|
| > _(Note that escapes are only recognized immediately after
| newline.)_
|
| This means that it is easy to pick up a habit to smash the enter-
| button a few times before doing this dance, and as noted on a
| nordic layout it can be a bit tricky and since you might seldom
| do it you might do it a few times.
|
| Problem can be that sometimes the connection is only broken one
| way, what you are typing goes to the server but the responses
| don't. So you might end up wreaking some kind of havoc on the
| remote server when you just want to kill the session. Maybe you
| had a half-written command. Maybe you had just done an up-arrow
| to get to the previous command, maybe you redid that up-arrow one
| or more times before you realized that the connection was broken.
| If you press enter now you will re-run one of your previous
| commands. Could be quite scary.
|
| To save you from some of that, you could do a ctrl+c which will
| clear your current line, before pressing enter. But whether that
| is a good idea depends on the context...
|
| The most apparent issue this has been for me is if on the remote
| you have IRC or something and you type a bunch of garbage to
| whatever channel you are on. No biggie, but the old restart the
| terminal isn't too bad either.
| maratc wrote:
| Pro tip: if you used ssh to get into host A and then another ssh
| to get from host A into host B, to break the A-B connection you
| need to issue `~~.`
|
| ("control up-arrow Q" song playing in the background.)
| totetsu wrote:
| And if you use host A like that enough you can also change the
| ssh escape key in your config.
| yuvadam wrote:
| Alternatively just use jump hosts: $(ssh -J bastion target)
| imp0cat wrote:
| Thanks.
___________________________________________________________________
(page generated 2023-04-09 23:00 UTC)