What's Actually Happening

You're trying to use SSH escape sequences like ~. to close a stuck connection or ~C to open the command line, but nothing happens. You type the tilde and the character, but SSH ignores it. This is frustrating when you have a hung session and the escape sequences are your only option.

The Error You'll See

You type the escape sequence:

bash
~.

But nothing happens. The session continues as if you typed nothing, or the characters appear literally on screen:

bash
user@remote:~$ ~.
bash: /home/user: Is a directory

The shell interpreted ~ as your home directory instead of recognizing it as an SSH escape character.

Why This Happens

SSH escape sequences have strict requirements:

  1. 1.The tilde (~) must be the first character on a new line
  2. 2.The character following ~ must be typed quickly
  3. 3.Your terminal must not be in raw mode or have special character handling
  4. 4.The session must be an interactive SSH session, not a direct command

The most common reason is typing ~ when it's not at the start of a line. If you've typed anything else, or if the previous command output didn't end with a newline, the ~ is treated as a regular character.

Step 1: Ensure Proper Positioning

The escape character ~ must immediately follow a newline. Press Enter first:

bash
[Press Enter]
~.

Not:

bash
some text~.

The sequence must appear exactly at the beginning of a line.

Step 2: Check for Shell Interference

Your shell might be interpreting ~ as home directory expansion. Test by checking what happens when you type ~ alone:

bash
echo ~

If this prints your home directory, the shell is processing the tilde. For escape sequences, SSH intercepts the tilde before the shell sees it—but only if it's first on a line.

Step 3: Verify SSH Session Type

Escape sequences only work in interactive sessions. Check your connection:

bash
echo $SSH_TTY

If empty, you might be in a non-interactive session or using a tool that wraps SSH.

Step 4: Check for Custom Escape Character

SSH allows changing the escape character. Check your config:

bash
grep -i escape ~/.ssh/config

If you see EscapeChar set to something other than ~, use that character instead.

Step 5: Test Basic Escape Sequences

Try the help sequence to see all available commands:

bash
[Press Enter]
~?

You should see:

bash
Supported escape sequences:
  ~.   - terminate connection (and any multiplexed sessions)
  ~B   - send a BREAK to the remote system
  ~C   - open a command line
  ~R   - request rekey
  ~V/v - decrease/increase verbosity (LogLevel)
  ~^Z  - suspend ssh
  ~#   - list forwarded connections
  ~&   - background ssh (when waiting for connections to terminate)
  ~?   - this message
  ~~   - send the escape character by typing it twice

If this works, your escape sequences are functional.

Step 6: Alternative Disconnect Methods

If escape sequences truly aren't working, use alternatives:

From another terminal: ``bash pkill -f "ssh.*hostname"

Force kill all SSH connections: ``bash pkill ssh

Using SSH ControlMaster: If you're using connection multiplexing, connect to the control socket:

bash
ssh -O exit hostname

Verify the Fix

Escape sequences work correctly when:

  1. 1.Pressing Enter, then ~? shows the help menu
  2. 2.~. immediately closes the connection
  3. 3.~C opens the SSH command line prompt ssh>
  4. 4.~# lists forwarded connections

To practice, start an SSH session and immediately try ~? after pressing Enter once. This confirms the sequences are working before you need them in an emergency.