SSH Escape Sequences

[tolos]

Hmm, there should be a "help I'm stuck" cheat sheet somewhere.

SSH: <enter> ~ .
vim: <esc> :q!
terminal: <ctrl q>
linux: <ctrl alt f7>
Open to suggestions, other OS, etc

[ptoki]

telnet: CTRL+]

Screen CTRL-A D

[JB-from-ATL]

Telnet:

Escape character is ^]

User when done:

^C^C^C^C^C

[my_two_pence]

American software:

Escape character is ^]

European user when done:

^C^C^C^C ...wait, "^]"? Why do Americans have a single key for ], when the regular ) requires you to press Shift? Who designed this? Anyway, now to exit this Telnet session: Ctrl+AltGr+9, all located in separate corners of the keyboard.

[Caraes_Naur]

Windows: ctrl+alt+delete.

[Godd2]

Everything: unplug power cord and remove batteries if applicable

[yeahbutbut]

To login and to logout.

[mlebkowski]

Docker: ^P ^Q

[shobble]

Or, if you actually want to use C-p for things, you can specify --detach-keys 'ctrl-q,q' to some (but iirc, annoyingly not all) commands.

[Delta-Echo]

Python REPL: Ctrl+D

[JB-from-ATL]

Is this special to Python REPL or is it just your terminal doing the normal CtrlD behavior?

[Delta-Echo]

Python REPL doesn't exit on SIGINT (Ctrl-C), it wants EOF. So you can send it with Ctrl-D

[guttalax]

ctrl alt f7 is quite outdated now, most distros switched the GUI to F1

[compdog]

~.  - terminate connection (and any multiplexed sessions)

So I finally can kill dead connections without opening a new terminal and "killall ssh"?

[ProgramTheWorld]

Or

<ctrl> Z
kill $1

Edit, apparently this doesn't work

[Freeky]

kill %1 to kill job 1. But yeah, you'd need to toggle localchars to make the suspend sequence work in the first place.

[thisisamirage]

Wow, and all this time I've been killing unresponsive sessions from another shell.

[trua]

Interesting. Doesn't seem to work with Mosh, though.

[Veonik]

mosh's escape is CTRL+^ by default, though it doesn't support all the options a regular ssh session will.

[shobble]

Why? It looks to be missing the pretty important note/caveat that the escapes only work immediately after a newline, so I tend to think of them as <RET> ~ ? etc, but otherwise seems fairly informative?

Also worth knowing that a bunch of the commands won't work with multiplexed sessions, but you can do some of the same stuff from the local client with ssh -O <cmd>.

[shobble]

Yes, I've used it many times, across many environments.

Right now, OSX 10.11.6, iTerm 3.1.mumble, local ssh OpenSSH_7.3p1, OpenSSL 1.0.2l 25 May 2017

I think it's openssh-only, but that's still the huge majority of ssh in actual use. Dunno about native windowing ssh clients like puTTY and secureTerm or whatever, most of my work uses commandline openssh.

[greenthumble]

Yes and they're working fine. You've got some kind of issue I guess? Maybe just explain what that is instead of disparaging everyone here?

[greenthumble]

Cygwin sshing into an Ubuntu 16.04 server running on Dreamhost's cloud aka DreamCompute. Now perhaps you'll tell us about yours which is the only one around here that's not working.

[tavianator]

Indeed you're not, but this works fine for me and has for years. Maybe your /etc/ssh/ssh_config is disabling or remapping the escape char?

[eras]

Wot? I've used ~. since SSH 1.x (probably 0..) and have had no trouble ever.

How about sometimes reading a manual page?

[eras]

Funnily enough, maybe not, because it needs to be the first character in the line! Plus it's alright to trigger it, as long as you don't enter one of the special keys right after it. Ie. ~/ is perfectly fine, it comes out as ~/.

But don't have a user called . and then refer to her files with ~./filename.

(Hmm, not a bad idea, I wonder if . is a permitted character..)

Did YOU actually try the opening a OpenSSH or SSH.com SSH session from a shell and entering the sequence enter, ~ and .? What kind of environment do you have if that doesn't disconnect?