SSH Escape Sequences(lonesysadmin.net)
lonesysadmin.net
SSH Escape Sequences
https://lonesysadmin.net/2011/11/08/ssh-escape-sequences-aka-kill-dead-ssh-sessions/
86 comments
Basically, however deep you are you need to send that many ~s before the period.
Isn't it exponential? To escape ~, you need ~~. To escape ~~, you need ~~~~. To escape ~~~~, you need ~~~~~~~~. Etc.
Isn't it exponential? To escape ~, you need ~~. To escape ~~, you need ~~~~. To escape ~~~~, you need ~~~~~~~~. Etc.
The escape sequence for Telnet, however, was exponential. This lead to the Telnet Song, by Guy Steele, a link to which was once posted on HN.
https://news.ycombinator.com/item?id=2060597
Note that the "up arrow" referred to in the song is not the current up arrow on the cursor keypad. Some early versions of ASCII-ish had an up arrow where the caret is now. And telnet actually mostly used control-], not control-^ anyway. I seem to recall Steele saying that he used "up arrow" because it worked better in the lyrics. I heard Steele sing this once and I think I recorded it.
https://news.ycombinator.com/item?id=2060597
Note that the "up arrow" referred to in the song is not the current up arrow on the cursor keypad. Some early versions of ASCII-ish had an up arrow where the caret is now. And telnet actually mostly used control-], not control-^ anyway. I seem to recall Steele saying that he used "up arrow" because it worked better in the lyrics. I heard Steele sing this once and I think I recorded it.
No, not exponential. The escape sequence is: <newline> then '~'. Anything after the '~' is special. In other words, only the first '~' appearing directly after a new line is special.
For example, <newline>~~~~ will send <newline>~~~ to the remote side.
For example, <newline>~~~~ will send <newline>~~~ to the remote side.
You need to enter ~ after pressing return (or else you have a bad time editing command lines involving home directories), so in practice only the first ~ each SSH instance sees needs escaping.
It's convenient there (and probably not accidental!) that Unix usernames are usually lowercase, so if you want to run a command like
~otheruser/bin/cat
it won't conflict with an ssh escape sequence (although you won't see the ~ appear until you've typed ~o).
On the other hand,
~Randomuser/bin/cat
would be impossible to type immediately at a new command prompt over an ssh connection (though of course it's possible to run such a command by typing anything such as "x<Backspace>" first).
~otheruser/bin/cat
it won't conflict with an ssh escape sequence (although you won't see the ~ appear until you've typed ~o).
On the other hand,
~Randomuser/bin/cat
would be impossible to type immediately at a new command prompt over an ssh connection (though of course it's possible to run such a command by typing anything such as "x<Backspace>" first).
[deleted]
[deleted]
I often use ~C (to open the ssh command prompt) and type (e.g.) “-L 80:localhost:8000” to set up forwarding via the same ssh session.
I wrote a small utility that allows you to create these forwardings through multiple hosts.
https://github.com/mpfz0r/sshdrill
https://github.com/mpfz0r/sshdrill
This is useful to know, especially if it works with agent forwarding. I default to agent forwarding off, but invariably forget to enable it the few times I need it.
I really don't like that this requires the first key to be Enter.
In the edge-case scenario of a glitchy link that appears frozen, it's entirely possible that my Enter keypress might actually make it through and then do something I don't want.
I've had mouse and keyboard input get through to seemingly-frozen VNC sessions, so...
In the edge-case scenario of a glitchy link that appears frozen, it's entirely possible that my Enter keypress might actually make it through and then do something I don't want.
I've had mouse and keyboard input get through to seemingly-frozen VNC sessions, so...
Yep, as I wrote below another comment, I share the same sentiment. To mitigate the risk somewhat, I tend to press Ctrl-C a few times before hitting enter to initiate the escape sequence (there are some edge cases where you need more than one Ctrl-C to interrupt).
Still not satisfied about it, as there are plenty of situations where that doesn't help. Being in emacs, for example, it could make things worse...
Still not satisfied about it, as there are plenty of situations where that doesn't help. Being in emacs, for example, it could make things worse...
cough accidently sending half-pasted gibberish to IRC.
My most frequently posted line in IRC is
:wqMy solution is to use a stateless in-application (where I expect to be) command to switch to a different window (In this case, the server chatter window) where pasting the line is an error since there's no command.
It usually works...
I agree that it would be nice if /any/ terminal escape sequence followed by ~ would initiate the escape.
It usually works...
I agree that it would be nice if /any/ terminal escape sequence followed by ~ would initiate the escape.
Always use Ctrl+C Enter ~. Enter. Just think of it as an ssh Konami code.
If you've sshed into another box first, use ~~. to only reset the embedded session.
If you've sshed into another box first, use ~~. to only reset the embedded session.
^E^U<enter> standard practice.
It's TCP so the connection either breaks or arrives in order.
It's TCP so the connection either breaks or arrives in order.
How about typing "Ctrl+C Ctrl+C e x i t Enter", and then adding the "~ ." if that doesn't work?
I've posted random ~. in irc because I did it in the wrong order...
Note that these only work at the beginning of a "line", so you may have to hit enter before the tilde.
Yeah. I can understand where they are coming from, at least with tilde as the escape character it would be highly inconvenient if it happened all the time, but I still a bit unhappy about having to press enter before being able to terminate a stuck session. That's usually not something I want to actually send, should the session not be as dead as I thought it was.
And if your terminal state is hosed by a crashed cursor-addressing (curses) program, you may have to use ^J instead of Enter.
Are you sure? I never noticed that. As an experiment, I did this in an ssh session from macOS to OpenBSD:
stty raw; cat
Hmm, I just tried it with stty raw and you're right.
It has happened to me though. Maybe a curses crash can leave it a state other than raw? One of the other modes such as inlcr plus ..? Also I suspect smart terminals and shells prevent a interactive session from getting too crazy.
It has happened to me though. Maybe a curses crash can leave it a state other than raw? One of the other modes such as inlcr plus ..? Also I suspect smart terminals and shells prevent a interactive session from getting too crazy.
Yeah, come to think of it, it wouldn't really surprise me if some weird terminal state swaps ^J and ^M or something.
Edit: Oh, you mentioned that yourself already, inlcr.
Edit: Oh, you mentioned that yourself already, inlcr.
This is very important to know. It often doesn't work and then there's no feedback why.
Others have mentioned that this is of course in the manual for OpenSSH. I recommend the Escape sequences section of the HP/UX manual for rlogin as useful reading, not least because it explains things that the OpenSSH manual does not, and actually answers questions brought up in discussion on this very page.
* http://nixdoc.net/man-pages/HP-UX/man1/rlogin.1.html
* http://nixdoc.net/man-pages/HP-UX/man1/rlogin.1.html
I learned this unexpectedly: I run ipmitool on a bastion host, and it uses similar sequences, like ~., to terminate a Serial over LAN session. I've had to remember to key ~~. so that the first tilde is able to get through to ipmitool.
Omg thank you. Same exact use case and I can’t believe I didn’t realize this.
It's not as bad as it use to be. In the old days you might do many telnets to get where you want.
Sing the Telnet song!
http://www.poppyfields.net/filks/00222.html
Sing the Telnet song!
http://www.poppyfields.net/filks/00222.html
Speaking of telnet, that protocol was actually much richer and had many more features than it would seem at a casual look.
I learned that when implementing a tiny part of the telnet protocol in a retro computer emulator's serial port emulation routines, mostly just to enable character mode and proper (non-)echoing. (I also implemented the RS232 control lines, so that telnet'ing into the port actually behaved like a physical terminal would with respect to carrier detect and all that, but I think there wasn't any overlap with the telnet protocol itself. Maybe flow control.)
I learned that when implementing a tiny part of the telnet protocol in a retro computer emulator's serial port emulation routines, mostly just to enable character mode and proper (non-)echoing. (I also implemented the RS232 control lines, so that telnet'ing into the port actually behaved like a physical terminal would with respect to carrier detect and all that, but I think there wasn't any overlap with the telnet protocol itself. Maybe flow control.)
Telnet also uses TCP's out of band data mechanism to send "urgent data" and a DATA MARK to interrupt and synchronize with runaway processes, and send important commands around flow control and before buffered data.
https://en.wikipedia.org/wiki/Out-of-band_data
http://www.serverframework.com/asynchronousevents/2011/10/ou...
https://en.wikipedia.org/wiki/Out-of-band_data
http://www.serverframework.com/asynchronousevents/2011/10/ou...
(Oh, Don Hopkins answering. I read you so often on TUHS!)
Didn’t know that, seems useful. Especially because another comment in this thread since mentioned that they often kill their ssh sessions because of runaway processes.
Overall, it seems to me that a lot was lost when giving up telnet.
Didn’t know that, seems useful. Especially because another comment in this thread since mentioned that they often kill their ssh sessions because of runaway processes.
Overall, it seems to me that a lot was lost when giving up telnet.
See also the even older SUPDUP protocol (RFC 734¹), which I understand had even more features.
1. https://tools.ietf.org/html/rfc734
1. https://tools.ietf.org/html/rfc734
I wrote a terminal emulator for the Apple ][ + Videx 80 column card in FORTH and reverse polish notation 6502 code, that supported SUPDUP including the line saving protocol that RMS hacked into ITS and EMACS (%TDSAV %TDRES), so Emacs could stash lines on the screen in a memory buffer (on the Apple's bank switched RAM card) and restore them later to paint the screen quickly when scrolling back and forth. (That was great at 300 baud!)
This is just the part of it that interprets SUPDUP codes -- layered on top of the rest of the terminal emulator that emulated H19 (VT52 + character/line insert/delete):
http://www.donhopkins.com/home/archive/forth/supdup.f
This is just the part of it that interprets SUPDUP codes -- layered on top of the rest of the terminal emulator that emulated H19 (VT52 + character/line insert/delete):
http://www.donhopkins.com/home/archive/forth/supdup.f
Marc Crispin (the author of the SUPDUP RFC #734, who was famous for his catchphrase "MM is not at fault!") also wrote another RFC #748 documenting the Telnet Randomly-Lose Option, which was useful for fuzzball testing.
https://en.wikipedia.org/wiki/Mark_Crispin
https://tools.ietf.org/html/rfc748
https://en.wikipedia.org/wiki/Mark_Crispin
https://tools.ietf.org/html/rfc748
IAC WILL RANDOMLY-LOSE
The sender of this command REQUESTS permission to, or confirms
that it will, randomly lose.
IAC WON'T RANDOMLY-LOSE
The sender of this command REFUSES to randomly lose.
IAC DO RANDOMLY-LOSE
The sender of this command REQUESTS that the receiver, or grants
the receiver permission to, randomly lose.
IAC DON'T RANDOMLY-LOSE
The command sender DEMANDS that the receiver not randomly lose.On my keyboard layout tilde is a dead key that requires three keypresses, so the usual disconnection command with the appropriate precautions is usually something like this:
Esc Esc Esc Ctrl-U Ctrl-C Enter AltGr-] Space .
OpenSSH lets you map EscapeChar to something more convenient, but it doesn't allow multibyte characters.
Esc Esc Esc Ctrl-U Ctrl-C Enter AltGr-] Space .
OpenSSH lets you map EscapeChar to something more convenient, but it doesn't allow multibyte characters.
> it doesn't allow multibyte characters
Someone should make a patch. I want to use :hankey: as the EscapeChar.
EDIT: Apparently HN swallows emojis. I can see why.
Someone should make a patch. I want to use :hankey: as the EscapeChar.
EDIT: Apparently HN swallows emojis. I can see why.
If your keyboard layout had pile of poo where your tilde key currently is, you would not be joking. The problem is that even Latin-based international layouts have quite a few characters that don't fit in the ASCII range.
I come across these once a year or so on the net but when I need them I never can remember them because it's not so often that I need them
Fortunately you only need to remember ~? since it tells you the rest.
Unfortunately, ~? is two characters too many for me to remember a year later :|
Do you never have to terminate a stuck session? <enter>~. to do so is practically muscle memory. The other sequences I cannot remember either, since their frequency of use is several orders less for me, but ~? is pretty intuitive to find out.
Typically I just wait for timeout, or open a new session (remote tmux session makes this quite painless). Plenty of other things to do, usually, waiting a couple minutes every week or three doesn't bug me enough to google.
Since I didn't know about <Enter>~. until a few days ago, I usually `killall ssh` or the specific PID.
Not the OP but I generally don't need to use <enter>~. because I have my terminal multiplexed in tmux so will kill the tmux pane rather than OpenSSH session.
The main reason I prefer to kill via tmux rather than OpenSSH is because sometimes I'll be connected several sessions deep (eg via a Bastian / SSH jumpbox or tmux itself might be running remotely) so the tmux kill is easier than having to remember whether I need to ~. or ~~.
But ultimate there is no right nor wrong way to do things here, it's all just a question of preference and habit.
The main reason I prefer to kill via tmux rather than OpenSSH is because sometimes I'll be connected several sessions deep (eg via a Bastian / SSH jumpbox or tmux itself might be running remotely) so the tmux kill is easier than having to remember whether I need to ~. or ~~.
But ultimate there is no right nor wrong way to do things here, it's all just a question of preference and habit.
If you need them but don’t remember them just use man ssh in another terminal.
This is one of those things like discovering ^r that’s going to change my life.
This page takes ~5s to load if JS from cdn.ampproject.com is blocked...
So don't block it? You can expect a broken browsing experience if you purposely break your browser.
This page is more broken than usual, so it's still interesting. Regardless of you snide remark.
I always wanted a serial transfer available from this escape so I could drop into sftp mode or kermit/xmodem/zmodem files over inside of the same session.
There are actually more things supported by ssh than are exposed here (clone and stuff) but just not implemented in openssh's ssh client.
There are actually more things supported by ssh than are exposed here (clone and stuff) but just not implemented in openssh's ssh client.
I am sad to say how often I've used ~. to close an SSH session because I entered an `ls -latr` command on a really huge directory. Ctrl+Z, Ctrl+C, Ctrl+\ would not halt the output, and it was faster to just terminate the session and come back in than wait for the output to finish.
I spend quite some time in ssh sessions and have learned that "Enter~." terminates a connection when it gets unresponsive, but I never bothered to understand it. This actually explains it.
How is this SSH escape sequences when it's actually OpenSSH escape sequences?
They look neat though, better than having to restart the session to forward ports. Too bad it doesn't work in PuTTY.
They look neat though, better than having to restart the session to forward ports. Too bad it doesn't work in PuTTY.
I checked, and it is indeed an OpenSSH feature. According to the release notes, it was added in v2.2.0, but you can actually tell just by the perverse choice of ~ as an escape character!
In many European keyboard layouts, including the Finnish layout used by original SSH's author, tilde (~) is a compose key and a chore to type. It is usually expressed by typing AltGr+¨ followed by Spacebar: https://en.wikipedia.org/wiki/Tilde#Keyboards
English is one of the few keyboard layouts where a person can express ~ with one, rather than two, handstrokes. For others, terminating an SSH session with the escape character usually requires blindly typing this four-part sequence: Enter, AltGr+¨, Spacebar, Dot.
I know you can change the escape character with ssh_config(5), but no one who used a non-English layout would have ever chosen ~ as the default to start with. I've always felt like it had to be an OpenSSH-specific feature, because I knew the original author of SSH (before the open-source codebase became OpenSSH) used the same KB layout as myself. ;)
In many European keyboard layouts, including the Finnish layout used by original SSH's author, tilde (~) is a compose key and a chore to type. It is usually expressed by typing AltGr+¨ followed by Spacebar: https://en.wikipedia.org/wiki/Tilde#Keyboards
English is one of the few keyboard layouts where a person can express ~ with one, rather than two, handstrokes. For others, terminating an SSH session with the escape character usually requires blindly typing this four-part sequence: Enter, AltGr+¨, Spacebar, Dot.
I know you can change the escape character with ssh_config(5), but no one who used a non-English layout would have ever chosen ~ as the default to start with. I've always felt like it had to be an OpenSSH-specific feature, because I knew the original author of SSH (before the open-source codebase became OpenSSH) used the same KB layout as myself. ;)
Pretty sure you can edit a lot of these session settings in putty while it is running. It's in the menu, I think (been a while since I used putty).
because for just about everyone, ssh is openssh
for better or worse.
true though.
true though.
It's in the manpage.
To be fair, who of us reads every manpage for every command that they use? (And I mean reading, not just skimming.)
I mean, it's a good practice to read manpages every now and then, just to learn new stuff (in the same way that there are always new vim commands to learn). But we encounter so many comands with so many options that knowing all of the options is just implausible.
I mean, it's a good practice to read manpages every now and then, just to learn new stuff (in the same way that there are always new vim commands to learn). But we encounter so many comands with so many options that knowing all of the options is just implausible.
This topic has a whole section in the manpage, though.
It's not easy to miss even if just skimming, because of that.
Non-AMP version:
https://lonesysadmin.net/2011/11/08/ssh-escape-sequences-aka...
https://lonesysadmin.net/2011/11/08/ssh-escape-sequences-aka...
What's wrong with the AMP version?
Aside from the common dislike for AMP centralising everything on Google's servers, I also dislike AMP links for the same reason I dislike mobile links to sites when I'm using a desktop PC.
The AMP versions usually lose formatting and links, and are designed to be read on a small mobile screen. I'd rather have the full version when I have a big screen available.
The AMP versions usually lose formatting and links, and are designed to be read on a small mobile screen. I'd rather have the full version when I have a big screen available.
Did you even click the link? It's not hosted on Google's server and it looks great. Much less clutter than the non-AMP version, and loads faster as well of course.
Normal website works fine without cookies and javascript. AMP version does not. It gives you a blank page. Thus, AMP is bad, since a simple HTML page like this one should never require javascript to just display the contents.
In this case I like the yellow block for the quoted content.
Somewhat controversially, AMP is what’s wrong.
Wait I thought we were all annoyed that AMP was being served by Google (at google.com even). At least that was my beef, that and clicking the X took me back to Google instead of to the actual site.
Self hosted AMP is just a lightweight version of the site isn't it?
Self hosted AMP is just a lightweight version of the site isn't it?
The AMP version requires a script from cdn.ampproject.org to display any content. I'm extremely annoyed by this new craziness where a 3rd-party script/xhr is required to display the content/images. This is more than just sloppiness on the development side, this risks user privacy as well.
New craziness? People have been using third party hosts for bootstrap, jQuery, anything on cdnjs, fonts.com, etc forever
You yourself use recaptcha on the site in your profile and a gist script from GitHub on your blog
You yourself use recaptcha on the site in your profile and a gist script from GitHub on your blog
You are right, but to be fair, I did migrate that website from Github so there are artifacts from the giant pile of mess that was my Jekyll config and I even wrote my own static generator (like the next webdev) to get rid of all the dependencies but this side-project never finished (I was experimenting with formatting/highlighting to inline gists as you can see in the last post but then I got bored).
I can't fight the spam bots myself so I have to hide my email behind that captcha for practical reasons (which is not a part of my site, it is a popup).
Other than that, there are nothing 3rd-party there. And everything loads pretty fast without any alien scripts (or any scripts at all for that matter).
I can't fight the spam bots myself so I have to hide my email behind that captcha for practical reasons (which is not a part of my site, it is a popup).
Other than that, there are nothing 3rd-party there. And everything loads pretty fast without any alien scripts (or any scripts at all for that matter).
You missed the important part of that statement:
> a 3rd-party script/xhr is required to display the content
Way too many websites just stay blank when JS is disabled, even though HTML is very capable of displaying text.
> a 3rd-party script/xhr is required to display the content
Way too many websites just stay blank when JS is disabled, even though HTML is very capable of displaying text.
It's interesting that people go out of their way to complain about their privacy being invaded by cameras, drones, the NSA snooping backbones, google, etc but most of us are fine with out browsers connecting to 61 different domains (CNN.com) to render a 3 paragraph news story.
The craziness is that more and more sites won't even render anymore without third-party javascript. Without bootstrap, jquery, fonts, etc, at least the page will still work, and it will work better because there's no bootstrap, jquery, fonts, etc.
Mind you, these are sites that can be served perfectly with a 1Kb HTML page + a bit of CSS. Not web apps or anything, where I understand you'd want to load a bunch of XHR requests.
Mind you, these are sites that can be served perfectly with a 1Kb HTML page + a bit of CSS. Not web apps or anything, where I understand you'd want to load a bunch of XHR requests.
[deleted]
Basically, however deep you are you need to send that many ~s before the period.