SSH kex_exchange_identification: Connection reset by peer — Causes and Fixes

kex_exchange_identification: read: Connection reset by peer means the connection was reset during the SSH key-exchange phase. You may also see Connection closed by remote host. This string alone cannot confirm a Fail2Ban ban. Correlate the client's ssh -vvv output with server logs from the same timestamp to narrow the cause.

Distinguish SSH connection errors first

Error	Check first
`Connection refused`	Whether the SSH port is listening, address/port, connection-refusal rules
`Connection timed out`	Path, firewalls, security groups, unresponsive server
`kex_exchange_identification ... reset by peer`	Pre-auth connection limits, blocking devices, sshd logs
`Permission denied (publickey)`	User and key authentication after the server is reached

Key-authentication failures and connection-reset errors follow different diagnostic sequences. For a general classification of connection errors, continue with the SSH connection troubleshooting guide.

1. Record the hang point and timestamp with ssh -vvv

Bash

# 클라이언트에서 실행: 사용자·주소·포트 교체
ssh -vvv -o ConnectTimeout=10 -p 22 user@host

Record not only the last line but how far you get: Connecting to, Connection established, the remote version string, and authentication-method prompts. Verbose logs help narrow possible causes; they do not by themselves prove which component blocked the connection.

If you have a server console or an existing admin session, inspect logs from the same time.

Bash

# 배포판에 따라 서비스 이름은 ssh 또는 sshd
sudo journalctl -u ssh -u sshd --since '15 minutes ago' --no-pager
sudo ss -ltnp

If the server has no records at all, also check the destination, port, intermediate firewalls, and NAT path. A successful ping only confirms ICMP replies; it does not guarantee that the SSH port is working.

2. If it fails only from a specific source IP, check ban records

On a server that actually runs Fail2Ban, check the following.

Bash

sudo fail2ban-client status
sudo fail2ban-client status sshd

sshd is an example jail name. Match active jails against the source IP the server observed. In NAT or VPN environments, the client's private IP may differ from the IP the server sees.

Run the following only if a confirmed legitimate admin IP is banned in that jail and you have permission to unban it.

Bash

# 203.0.113.10은 예시 주소: 실제 차단 IP로 교체
sudo fail2ban-client set sshd unbanip 203.0.113.10

If you do not also fix the authentication-failure cause, it can get banned again. Fail2Ban client command documentation

3. If it happens only under concurrent connections, check MaxStartups

Bash

sudo sshd -T | grep -iE 'maxstartups|persourcemaxstartups|logingracetime'

MaxStartups limits concurrent connections that have not completed authentication. For example, if the effective setting is 10:30:100, new connections start being refused with 30% probability once there are 10 unauthenticated connections, and all are refused at 100. This is different from MaxSessions, which limits the number of completed login sessions. Check the actual effective setting for your version and distribution. OpenSSH sshd_config

First check whether automation jobs open many connections at once. After considering reducing deployment concurrency and reusing connections, adjust the limit to match server capacity and security policy. If the situation was caused by attack traffic, raising the limit alone can increase load.

4. Check per-account policies and sshd status

Bash

sudo sshd -T | grep -iE 'allowusers|denyusers|allowgroups|denygroups'
sudo sshd -t

In environments with Match conditions, do not infer a specific connection's settings from a plain sshd -T dump alone. An administrator can pass the actual user, remote address, and so on to sshd -T -C to inspect the effective configuration. Before running it, check supported options in the local man sshd.

Apply configuration changes only after a syntax check, while keeping an existing admin session open. Example for environments where the service name is ssh:

Bash

sudo sshd -t && sudo systemctl reload ssh

Then, from a separate terminal, confirm that a new connection succeeds before closing the existing session. If the listening process went down, first fix the startup-failure cause in the journal.

5. Check hosts.deny only on legacy environments

OpenSSH removed TCP Wrappers/libwrap support in 6.7. Therefore, telling people to edit /etc/hosts.deny as a default fix is not appropriate for modern OpenSSH servers. Investigate only when you have confirmed a legacy package or a custom patch that still uses libwrap. OpenSSH 6.7 release notes

Check the current server firewall according to the distro setup: nftables, iptables, UFW, cloud security groups, and so on. Rather than disabling the entire firewall for diagnosis, inspect the required source, destination, and port rules.

When every access path is blocked

Use a separate management path: the hosting admin console, a preconfigured serial console, a recovery environment, and so on. A cloud serial console has instance-, account-, and OS-specific prerequisites; it does not always connect just because you click a button.

After recovery, record cause logs → rules you changed → whether a new connection succeeded. Choose recurrence-prevention measures based on the confirmed cause: a specific IP ban, a concurrent-connection limit, or an sshd failure.

After you have identified the block cause, see SSH hardening and Fail2Ban configuration to tidy up defensive settings.

확인 정보

#SSH 접속 오류 #connection reset by peer #ssh_exchange_identification #fail2ban #서버보안

✦ ✦ ✦

편집 검토 · Editorial Review

Nodelog는 모든 콘텐츠의 내용과 출처를 공개 전에 검토합니다. 환경(OS·버전)에 따라 결과가 달라질 수 있는 기술 정보는 공식 문서와 함께 확인하며, 검토 기준과 정정 원칙은 편집 정책에서 안내합니다. 오류를 발견하시면 이메일로 제보해 주세요 — 확인 후 신속히 정정합니다.

편집 책임 · Nodelog 기술 편집팀·발행 · Sep 7, 2026·업데이트 · Sep 17, 2026

운영·검토 방식 자세히 보기 →편집 정책 →

이 글이 도움이 되었나요?

Comments

Be the first to comment.