SSH Connection closed by remote host 에러 원문별 트러블슈팅

SSH "Connection closed by remote host" 에러 원문별 트러블슈팅 런북

어제까지 잘 되던 SSH가 갑자기 거부당한다

키도 안 바꿨고, 비밀번호도 그대론데 갑자기 서버에 못 들어간다. 그런데 에러 메시지를 자세히 보면 Permission denied가 아니다. Connection closed by remote host 혹은 Connection reset by peer다.

이 둘의 차이는 결정적입니다. Permission denied (publickey)는 "너 누구인지 확인은 했는데 권한이 없다"는 인증 단계 실패이고, Connection closed / reset은 "인증 대화를 시작하기도 전에 연결 자체가 끊겼다"는 연결 계층 문제입니다. 즉 키·authorized_keys·권한(600)을 아무리 뒤져봐야 답이 안 나옵니다.

인증 단계까지 갔다면(Permission denied (publickey)) 이 글이 아니라 SSH 인증 트러블슈팅 글을 참고하세요. 이 글은 연결이 끊기거나 차단되는 문제만 다룹니다.

이 글에서 다루는 범위는 TCP/연결 계층과 접근 차단입니다: fail2ban 밴, hosts.deny, MaxStartups 초과, sshd 크래시, 방화벽·클라우드 보안그룹.

1. 에러 원문 감별표

검색창에 붙여넣은 그 한 줄만으로 원인의 8할이 갈립니다.

핵심 대비: closed는 서버가 "안녕히" 하고 얌전히 끊은 것(차단·데몬 정책), reset은 누군가 "탁!" 하고 회선을 끊은 것(방화벽·크래시·과부하) 입니다.

2. 먼저 나누는 흐름도: 나만 안 되나, 다 안 되나

명령을 치기 전에 30초만 판단하세요.

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

내 IP만 막혔다면 십중팔구 fail2ban self-ban입니다. 요즘 공격 트래픽이 늘면서 기본 프로파일이 정상 사용자까지 오탐·차단하는 사례가 부쩍 늘었습니다(재접속 반복, VPN IP 공유 등).

3. 복붙 진단 명령 모음

콘솔이나 다른 세션이 열려 있다면 위에서부터 순서대로 실행하세요.

# ① 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

출력 해석 팁:

• ① active (running)이 아니면 데몬 문제. Connection reset의 흔한 범인.
• ② Connection closed by <IP> [preauth]가 보이면 인증 전 드롭 → MaxStartups·차단 의심.
• ③ Banned IP list:에 내 IP가 있으면 확정. self-ban입니다.
• ④ hosts.deny에 sshd: 1.2.3.4 또는 ALL: ALL이 있으면 TCP wrappers 차단.
• ⑤ sshd -T는 실제 적용값, grep sshd_config는 파일에 적힌 값. 둘이 다르면 reload가 안 된 것.

4. 복붙 복구 명령

fail2ban 밴 해제

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

내 IP가 자주 밴된다면 /etc/fail2ban/jail.local의 ignoreip에 회사 고정망·VPN 대역을 추가하세요.

[DEFAULT]
ignoreip = 127.0.0.1/8 203.0.113.0/24

hosts.deny 정리

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

클라우드 보안그룹 / NACL

Connection reset인데 서버 안에는 아무 이상이 없다면 클라우드 콘솔을 보세요. AWS 보안그룹의 22번 인바운드 소스IP, NACL 규칙 변경이 종종 조용히 RST를 유발합니다. 콘솔에서 소스에 현재 공인 IP를 추가하면 끝납니다.

5. MaxStartups / MaxSessions 실전 설명

kex_exchange_identification: Connection closed가 산발적으로 뜨면 MaxStartups를 의심하세요.

기본값 10:30:100의 의미:

• 10: 미인증(pre-auth) 동시 연결이 10개까지는 무조건 허용
• 30: 10개를 넘으면 30% 확률로 드롭 시작
• 100: 100개에 도달하면 전부 드롭

CI 파이프라인, 다수의 rsync/git, 스캐너 트래픽이 몰리면 정상 접속까지 튕깁니다. 여유를 주려면:

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

변경 후 반드시 문법 검증부터:

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

⚠️ 안전 리로드 경고

• 설정을 바꾸기 전 반드시 별도 SSH 세션이나 콘솔/시리얼 접속을 하나 더 열어두세요. 오타 하나로 완전 락아웃될 수 있습니다.
• restart는 기존 세션을 끊습니다. 무중단으로 반영하려면 reload를 쓰세요.
• sshd -t로 문법 검증 없이 재기동하면 sshd가 아예 안 뜰 수 있습니다.

6. 다시는 락아웃되지 않기: out-of-band 접근

백도어를 뚫지 말고, 정식 out-of-band 경로를 항상 확보해 두세요.

• AWS: EC2 Instance Connect, SSM Session Manager(22번 포트 없이 접속) — 보안그룹을 잘못 건드려도 들어갈 수 있는 최후의 문
• GCP: 시리얼 콘솔, IAP TCP forwarding
• 온프렘/기타: IPMI·iDRAC 시리얼 콘솔

재발 방지 체크리스트:

1. ignoreip에 관리망·VPN 대역 등록
2. 설정 변경은 항상 sshd -t → reload
3. 별도 세션 확보 후 작업
4. SSM/시리얼 콘솔 등 백업 접근 경로 1개 상시 유지
5. fail2ban bantime·findtime을 환경에 맞게 튜닝(기본값 오탐 주의)

참고: 공식 문서

이 글에서 다루는 동작·설정·에러의 1차 출처는 다음 공식 문서입니다. 버전별 옵션과 정확한 동작은 여기서 확인하세요.

• OpenSSH sshd_config 매뉴얼(man7.org)

자주 묻는 질문 (FAQ)

Q. Connection closed와 Connection reset은 뭐가 다른가요? A. closed는 서버가 정책적으로 얌전히(FIN) 끊은 것으로 fail2ban·hosts.deny·MaxStartups 같은 차단/과부하가 원인입니다. reset은 TCP RST로 강제 종료된 것이라 방화벽·보안그룹·sshd 크래시를 먼저 보세요.

Q. fail2ban에 내 IP가 밴됐는지 어떻게 확인하고 푸나요? A. sudo fail2ban-client status sshd로 Banned IP list를 확인하고, sudo fail2ban-client set sshd unbanip <IP>로 해제합니다. 반복되면 ignoreip에 대역을 등록하세요.

Q. MaxStartups를 바꿨는데 적용이 안 돼요. A. sudo sshd -T | grep -i maxstartups로 실효값을 확인하세요. 파일값과 다르면 reload가 안 된 것입니다. sudo sshd -t로 문법 검증 후 sudo systemctl reload sshd를 실행하세요.