Short answer: Type exit
If that doesn't work, however...
SSH Escape Character and Disconnect Sequence
Most SSH implementations implement an escape character for interactive sessions, similar to telnet's Ctrl-]
combination. The default SSH escape character is ~
, entered at the beginning of a line.
If you want to terminate an interactive OpenSSH session which is stuck and cannot be exited by entering exit
or CtrlD into a shell on the remote side, you can enter ~
followed by a dot .
. To be sure to enter the escape character at the beginning of an input line, you should press Enter first.
So the following sequence will in most cases terminate an SSH session:
Enter~.
Other Escape Sequences
OpenSSH, for example, offers other escape sequences besides ~.
. Entering ~?
during a session should give you a list. Some examples:
~
followed Ctrl-Z
suspends the session,
~&
puts it directly into background,
~#
gives a list of forwarded connections in this session.
- If you want to simply enter a tilde at the beginning of a line, you have to double it:
~~
.
The escape character can be changed using the command line option -e
. If you set the special value -e none
, escaping is disabled and the session is fully transparent.
See also the OpenBSD man page on ssh (which is referenced from www.openssh.org) under the -e
command line option
I don't find the "how do we know this" section particularly helpful, because to me it implies that there is some sort of obvious-to-find solution, when I don't find it particularly intuitive that I would "man ssh" to find how to disconnect. How would I have found "exit", for example? I do agree it's good to reaffirm checking the man pages when you can. – Alexander Pritchard – 2017-10-11T15:49:40.333
@AlexanderPritchard I have updated my answer to more carefully explain what we're doing here. If you find the man page difficult to understand, file an issue with the maintainer, or even better, submit a pull request with an (unqualifyingly good) improvement. – Aaron Hall – 2017-10-11T17:01:07.240
1That sounds good in theory, but in practice, many people struggle to figure out how to navigate these commands because even knowing how to look for the information you want assumes context people do not have. Filing an issue with maintainers and submitting pull requests with improvements goes even further beyond this. I do not argue that man pages are useful, but if they were as definitively useful as some make them seem, I wouldn't be using Stack Exchange. I want to be clear I think your answer is fine, and that people should check the man pages, but they are not all-encompassingly useful. – Alexander Pritchard – 2017-10-12T17:54:40.373
8"if they were as definitively useful as some make them seem, I wouldn't be using Stack Exchange." I agree, and that's why I try to write good answers. Citing and quoting reference sources is not to make anyone feel dumb or bad for not having already read from that source, it is done to provide further evidence for what would otherwise be a perhaps demonstrable assertion of fact, as well as inform the user where more relevant information may be stored. You want to know that you're doing semantically the correct thing, as well as knowing that it works. – Aaron Hall – 2017-10-12T18:20:01.440