Troubleshooting SSH "Connection closed by remote host" by Exact Error Message

SSH "Connection closed by remote host" Troubleshooting Runbook by Exact Error Message

SSH that worked yesterday is suddenly refused

You didn't change the key. The password is the same. Suddenly you can't get into the server. Look closely at the error, though—it is not Permission denied. It is Connection closed by remote host or Connection reset by peer.

The difference is decisive. Permission denied (publickey) means "I know who you are, but you don't have permission"—an authentication-stage failure. Connection closed / reset means "the connection itself was dropped before the auth conversation even started"—a connection-layer problem. Digging through keys, authorized_keys, and 600 permissions will not give you an answer.

If you reached the authentication stage (Permission denied (publickey)), this is not the article you want—see the SSH authentication troubleshooting post instead. This article covers only connection drops and blocking.

Scope of this article: the TCP/connection layer and access blocking—fail2ban bans, hosts.deny, MaxStartups exhaustion, sshd crashes, firewalls, and cloud security groups.

1. Error-message triage table

That one line you pasted into the search box already points to 80% of the cause.

Key contrast: closed is the server saying "goodbye" and hanging up politely (blocking / daemon policy). reset is someone slamming the line shut (firewall, crash, overload).

2. First split: is it just me, or everyone?

Spend 30 seconds deciding this before you run any commands.

SSH 접속 거부
   │
   ├─ 다른 IP/네트워크(폰 핫스팟 등)에서도 안 됨?
   │     → 전역 차단 · sshd 다운 · 방화벽 · MaxStartups
   │
   └─ 내 IP에서만 안 됨?
         → fail2ban 밴 · hosts.deny · 보안그룹 소스IP 제한

If only your IP is blocked, it is almost certainly a fail2ban self-ban. With attack traffic up, default profiles increasingly false-positive and lock out legitimate users (repeated reconnects, shared VPN IPs, etc.).

3. Copy-paste diagnostic commands

If you have a console or another session open, run these in order from the top.

# ① sshd가 살아있나
sudo systemctl status sshd

# ② 최근 sshd 로그 (거부 사유가 여기 다 찍힘)
sudo journalctl -u sshd -n 50 --no-pager

# ③ fail2ban이 내 IP를 밴했나
sudo fail2ban-client status sshd

# ④ TCP wrappers 차단 확인
sudo cat /etc/hosts.deny /etc/hosts.allow

# ⑤ MaxStartups 현재 실효값
sudo sshd -T | grep -i maxstartups
grep -i maxstartups /etc/ssh/sshd_config

How to read the output:

• ① If it is not active (running), it is a daemon problem—a common cause of Connection reset.
• ② If you see Connection closed by <IP> [preauth], that is a pre-auth drop → suspect MaxStartups or blocking.
• ③ If your IP is in Banned IP list:, that is confirmed. It is a self-ban.
• ④ If hosts.deny has sshd: 1.2.3.4 or ALL: ALL, that is TCP wrappers blocking.
• ⑤ sshd -T is the effective value; grep sshd_config is what is written in the file. If they differ, you never reloaded.

4. Copy-paste recovery commands

Unban fail2ban

# 밴된 IP 목록에 내 IP가 있으면
sudo fail2ban-client set sshd unbanip 203.0.113.45
# → 기대 출력: 1  (해제된 IP 수)

If your IP gets banned often, add your office static network and VPN ranges to ignoreip in /etc/fail2ban/jail.local.

[DEFAULT]
ignoreip = 127.0.0.1/8 203.0.113.0/24

Clean up hosts.deny

# 잘못 들어간 sshd 차단 라인 확인 후 제거
sudo sed -i '/sshd/d' /etc/hosts.deny

Cloud security groups / NACLs

If you get Connection reset but nothing is wrong on the server itself, check the cloud console. Changes to the AWS security group inbound source IP for port 22, or NACL rules, often cause silent RSTs. Add your current public IP to the source and you are done.

5. MaxStartups / MaxSessions in practice

If kex_exchange_identification: Connection closed appears sporadically, suspect MaxStartups.

What the default 10:30:100 means:

• 10: Unconditionally allow up to 10 concurrent unauthenticated (pre-auth) connections
• 30: Once you exceed 10, start dropping with 30% probability
• 100: At 100, drop everything

When CI pipelines, lots of rsync/git, or scanner traffic pile up, even legitimate connections get bounced. To give yourself headroom:

# /etc/ssh/sshd_config
MaxStartups 30:50:200
MaxSessions 20

After changing it, always validate syntax first:

sudo sshd -t            # 아무것도 출력 안 되면 정상
sudo systemctl reload sshd   # restart 아님!

⚠️ Safe-reload warning

• Always keep a second SSH session or console/serial connection open before changing config. One typo can lock you out completely.
• restart kills existing sessions. Use reload to apply without downtime.
• Restarting without an sshd -t syntax check can leave sshd unable to start at all.

6. Never get locked out again: out-of-band access

Don't punch a backdoor. Always keep a proper out-of-band path.

• AWS: EC2 Instance Connect, SSM Session Manager (connect without port 22) — the last door that still works even if you botch the security group
• GCP: serial console, IAP TCP forwarding
• On-prem / other: IPMI / iDRAC serial console

Lockout-prevention checklist:

1. Register management and VPN ranges in ignoreip
2. Always sshd -t → reload for config changes
3. Work only after you have a second session
4. Keep one backup access path at all times (SSM / serial console, etc.)
5. Tune fail2ban bantime and findtime for your environment (watch default false positives)

References: official docs

The primary source for the behavior, settings, and errors in this article is the official documentation below. Check it for version-specific options and exact behavior.

• OpenSSH sshd_config man page (man7.org)

FAQ

Q. What's the difference between Connection closed and Connection reset? A. closed is the server politely hanging up (FIN) as a matter of policy—fail2ban, hosts.deny, MaxStartups, and similar blocking/overload. reset is a forced TCP RST, so look at firewalls, security groups, and sshd crashes first.

Q. How do I check whether fail2ban banned my IP, and how do I unban it? A. Check the Banned IP list with sudo fail2ban-client status sshd, then unban with sudo fail2ban-client set sshd unbanip <IP>. If it keeps happening, add your range to ignoreip.

Q. I changed MaxStartups but it didn't take effect. A. Check the effective value with sudo sshd -T | grep -i maxstartups. If it differs from the file, you never reloaded. Run sudo sshd -t to validate syntax, then sudo systemctl reload sshd.