How to Reset SSH Connection: 5-Minute Fixes

Your SSH session freezes mid-command, or you get kex_exchange_identification: read: Connection reset by peer or ssh_exchange_identification: Connection closed by remote host the moment you try to reconnect. Nine times out of ten this is a stale TCP session, a saturated connection limit on the daemon, or a stuck client-side socket — not a broken server. You don’t need to reboot anything to fix it. Most of these are copy-paste jobs that take under five minutes, and half of them don’t even require touching the remote box. The trick is knowing whether the reset is happening on your laptop, in the network path, or on the server’s sshd — and that’s diagnosable in about thirty seconds if you know which log to check first.

ssh -v user@host 2>&1 | head -20

When Your SSH Session Stops Responding: What’s Actually Happening

“SSH is frozen” actually means one of three distinct failure states, and they don’t get fixed the same way. Knowing which one you’re in saves you from restarting the wrong service.

• Hung session: your cursor blinks but nothing happens — no output, no error, no prompt back. The TCP connection is technically alive, but a network device between you and the server (usually a NAT gateway or corporate firewall) has silently dropped its state table entry for your socket.
• Timeout disconnect: you get an explicit message like Connection closed by remote host or client_loop: send disconnect: Broken pipe. The server or an intermediate device gave up waiting and killed the socket outright.
• Stale connection: commands appear to run — you press Enter, get a new blank line — but no actual output ever arrives. The shell on the remote end is alive, but the data channel between it and your terminal is broken.

“Resetting” SSH means different things depending on which failure you’re in: killing a zombie client process, forcing a fresh TCP handshake, or clearing out buffered keepalive data that never got flushed. All three fixes below work with OpenSSH 8.0 and later (the baseline since 2019, and still what ships on Ubuntu 22.04/24.04, Debian 12, and macOS’s built-in client), PuTTY 0.78+, and any standard terminal SSH client on Linux, macOS, or BSD.

Escape to the SSH Prompt Without Closing Your Session

Before you kill the terminal window or reach for kill -9, try the built-in OpenSSH escape sequence. It’s a client-side signal that doesn’t depend on the remote host responding at all, which is exactly why it works on a hung session when nothing else does. Give the connection 5-10 seconds of silence first — if it’s just slow, not dead, you’ll interrupt a command that was about to return.

Using the Tilde-Period Escape Sequence

Press Enter first to make sure you’re at the start of a fresh line — the escape sequence only gets recognized there, not mid-command.

[press Enter]
~.

Type a tilde, then immediately a period. No other keys in between.

You’ll see one of two outcomes, and both mean it worked:

Connection to hostname closed by remote host.

Or nothing at all — the terminal just returns you to your local shell prompt silently. Some terminal emulators (iTerm2, GNOME Terminal) print the message; others swallow it. Either way, your local SSH client process has terminated and you’re back on your own machine.

This works because ~. is interpreted by your local ssh client, not sent over the wire. Even if the remote server is completely unresponsive — kernel panic, network partition, whatever — your client still tears down the local side of the connection instantly. Applies to OpenSSH client on Linux, macOS, and BSD, plus any terminal wrapping it (Terminal.app, iTerm2, Alacritty, GNOME Terminal, Windows Terminal with WSL).

Kill a Frozen SSH Session from Another Terminal

Sometimes ~. doesn’t fire at all — the terminal emulator itself is locked up, not just the SSH session. If your window won’t accept any keystrokes, you need a second terminal (a new tab, a new SSH session to the same box, or a fresh terminal window) to go kill the stuck process directly.

Finding and Terminating the SSH Process

ps aux | grep ssh

Run this in the new terminal. You’ll get output like:

you   4821  0.0  0.1  408920  9216 pts/2  S+  14:02  0:00 ssh -i ~/.ssh/id_ed25519 user@10.0.1.15
you   4903  0.0  0.0   9032   656 pts/3  S+  14:12  0:00 grep --color=auto ssh

Ignore the grep line itself — that’s just your search command showing up in its own results. The line you want is the one starting the actual connection: ssh -i ~/.ssh/id_ed25519 user@10.0.1.15. The second column is the PID — 4821 in this example.

kill -9 4821

This sends SIGKILL to the frozen client process. It’s safe to use -9 here — you’re not corrupting a database or killing a write in progress, you’re just terminating a network client on your own laptop. You’ll either see the shell print Killed or get no output at all, and your prompt in the frozen terminal (if it ever unfreezes) will show the connection dropped.

If you’ve got multiple SSH sessions open and don’t want to hunt PIDs, killall ssh works too — but it kills every SSH client process on the machine, including ones you didn’t mean to touch. Use pkill -f 'hostname' instead to match by pattern:

pkill -f 'user@10.0.1.15'

This only kills SSH processes matching that host string, leaving other sessions alone.

One thing this does not do: clean up anything on the remote server. Killing your local client just drops the TCP connection from your end — if you left a command running remotely (a tail -f, a stuck rsync, a runaway script), it may keep running under the orphaned shell on the server. Reconnect and check ps aux on the remote host if you need to kill that too.

Reset SSH Connection Timeout Settings If Sessions Keep Dropping

If your SSH sessions die every 5-15 minutes even while you’re actively working, the culprit is almost always an idle timeout — either your router’s NAT table dropping the connection because no packets crossed the wire, or a corporate firewall doing the same thing. The fix is keepalive packets, and you can set them on the client, the server, or both. This applies to OpenSSH 7.3 and later, which is the baseline on every current Ubuntu, Debian, RHEL, and macOS install in 2026.

Client-Side Keepalive: Prevent Timeout on Your End

Edit ~/.ssh/config on your local machine (create it if it doesn’t exist):

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

ServerAliveInterval 60 tells your SSH client to send a null packet to the server every 60 seconds of inactivity. ServerAliveCountMax 3 means it’ll tolerate 3 missed responses before giving up — so a dead connection gets detected within 3 minutes instead of hanging silently. There’s no visible output when this works; you just notice your session stays open through long idle stretches instead of dropping.

This takes effect on your very next connection — no reload needed. It’s entirely client-side and safe to apply with zero risk to anything. For a one-off test without editing the config file, run:

ssh -o ServerAliveInterval=60 user@10.0.1.15

Same effect, just scoped to that single connection.

Server-Side Keepalive: Prevent Idle Disconnects for All Users

If you manage the server and want this applied for every user connecting to it, edit /etc/ssh/sshd_config (requires sudo):

ClientAliveInterval 60
ClientAliveCountMax 3

This is the server-side mirror of the client setting — the daemon sends a keepalive to the client every 60 seconds and disconnects after 3 missed replies, giving you a 3-minute effective timeout. Reload the daemon to apply it:

sudo systemctl reload ssh

On older init systems, use sudo service sshd reload instead. Expect either silent success or a line like Reloaded ssh.service. If the reload fails, check /var/log/auth.log for Received signal 1 — that confirms the daemon actually re-read its config.

This change requires sudo and affects every SSH user on the box, so don’t set an aggressive value like ClientAliveCountMax 1 on a shared server without warning your team. It also only applies to new connections — anyone already logged in keeps their old timeout behavior until they reconnect.

Clear Stale SSH Keys or Cached Connections from Known_Hosts

If your terminal is throwing Host key verification failed or the much scarier WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!, this isn’t a network problem — it’s a mismatch. The key SSH has cached for that hostname in ~/.ssh/known_hosts no longer matches the key the server is presenting. That happens when a server gets rebuilt, its IP gets reassigned to a different box, or a cloud provider spins up a fresh VM on an address you used before.

Remove a Stale Host Key Entry

ssh-keygen -R hostname

Replace hostname with the actual IP or domain you’re connecting to. Expect output like:

# Host hostname found in /home/user/.ssh/known_hosts:1
Removed keys for hostname

If the entry wasn’t there, you’ll see Host not found instead — harmless, just means nothing was cached. Now reconnect:

ssh user@hostname

You’ll see a fresh prompt:

The authenticity of host 'hostname (10.0.1.15)' can't be established.
ECDSA key fingerprint is SHA256:abc123...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Type yes. This is normal and expected the first time you connect after removing a key — it’s not a security downgrade, it’s SSH asking you to re-establish trust. Confirm the new key got cached:

grep hostname ~/.ssh/known_hosts

You should see one new line with a fresh key fingerprint. If the same warning fires again immediately on the next connection attempt, stop — don’t just keep typing yes. That pattern means the server’s actual key changed, possibly from a man-in-the-middle attack or a hijacked IP. Verify the fingerprint out-of-band with whoever manages that box before proceeding.

Prefer editing by hand instead of the keygen tool? Find the offending line first:

grep hostname ~/.ssh/known_hosts

Then open the file in any editor and delete that line. Same result, just manual. Works identically on Linux, macOS, and BSD — the file format hasn’t changed in over a decade. Note this fix doesn’t reset an active connection; it only clears the block stopping you from starting a new one.

Verify Your SSH Connection Is Actually Reset and Stable

Don’t declare victory just because the prompt came back. Run something trivial first:

echo 'Connection OK'

Or:

uptime

Expect output back in under a second. If uptime takes 3-4 seconds to print, that’s a latency or DNS problem worth chasing separately — not a broken connection, but not “fixed” either.

The real test is stability, not the initial handshake. Start a long-running command and walk away for five minutes:

tail -f /var/log/syslog

On a self-hosted Postgres box under moderate load, this is exactly what you’d leave running while watching for connection drops during a migration. If new log lines keep streaming and the terminal stays responsive, the reset held. If the session hangs — no output, no cursor movement, nothing for 30+ seconds — or you get kicked with Connection closed by remote host, the fix didn’t stick. Note which fix you just tried and move to the next one in this article; don’t repeat the same step twice expecting a different result.

When it’s still failing, check the server side instead of guessing client-side:

sudo tail -f /var/log/auth.log

Ubuntu/Debian use /var/log/auth.log. RHEL/CentOS/Fedora use /var/log/secure. BSD variants log to /var/log/messages. Look for Connection closed by authenticating user or any line mentioning timeout.

If you see sshd: fatal: Timeout before authentication, the server is killing the session before login finishes — this is not a client-side reset issue at all. Check ServerAliveInterval on the client and ClientAliveInterval in sshd_config, or investigate raw network latency between the two hosts.

Prevent SSH Connection Resets: Long-Term Stability Checklist

Once a session is stable, lock it in so you’re not back here next week. All of the following are client-side, additive changes — no sshd restart, no server downtime.

• Keepalives. Add to ~/.ssh/config: ServerAliveInterval 60 and ServerAliveCountMax 3. This pings the server every 60 seconds so idle connections don’t get killed by NAT devices or firewalls silently dropping the socket.
• Rule out packet loss. Run ping -c 10 hostname — any loss above 0% on a LAN, or above 2-3% over the internet, points to a network problem, not SSH itself.
• Check server load. Run ssh user@hostname 'uptime'. A load average above your core count means the server is too busy to answer keepalives in time — that’s your reset, not your config.
• Update your client. Run ssh -V and update via apt, yum, or brew if you’re behind OpenSSH 9.x — older clients have known rekeying bugs that trigger resets on long sessions.

For connection reuse, add multiplexing:

Host *
  ControlMaster auto
  ControlPath ~/.ssh/control-%h-%p-%r
  ControlPersist 10m

New sessions to the same host reuse the existing TCP connection instead of renegotiating, cutting reconnect time to near-zero.

Last, run tmux or screen on the remote box for anything long-running. A dropped SSH session no longer kills your process — you just reattach with tmux attach.

Frequently Asked Questions

Related Reads

• Fix “fatal: not a git repository” Error in VS Code

  Resolve “fatal: not a git repository” in VS Code. Copy-paste fixes ordered by likelihood. Works on Windows, macOS, Linux…

• REST vs GraphQL API Comparison: Which Fits Your Stack in 2026

  REST vs GraphQL API: Compare query efficiency, caching, real-time capabilities, and implementation complexity. Choose th…

• Best Terminal Emulator for Windows in 2026: Developer Comparison

  Compare top Windows terminal emulators for developers & sysadmins in 2026. Windows Terminal, ConEmu, Cmder reviewed with…