beautifulsoups.dev
Published on

리눅스 SSH 접속 끊김·Timeout 원인 10가지

Authors

서버에 SSH로 붙었다가 몇 분~몇 시간 뒤 세션이 끊기거나, 아예 Connection timed out/Connection reset by peer로 접속이 실패하는 이슈는 흔하지만 원인 범위가 넓습니다. 특히 클라우드 환경(AWS/Azure/GCP)과 사내망(VPN/방화벽/프록시)이 섞이면 “서버는 살아있는데 SSH만 죽는” 상황이 자주 나옵니다.

이 글은 재현 가능한 증상 분류 → 로그 확인 → 네트워크/서버/설정 원인 10가지를 순서대로 정리합니다. 각 항목마다 바로 실행 가능한 커맨드와 체크 포인트를 포함했습니다.

0) 먼저 증상부터 분류하기

SSH 문제는 메시지에 따라 접근법이 달라집니다.

  • Connection timed out: 라우팅/보안그룹/방화벽/포트 미개방/패킷 드롭 계열
  • Connection refused: 포트는 도달하지만 sshd가 리슨하지 않거나 로컬 방화벽이 거부
  • 접속은 되는데 몇 분 후 끊김: idle timeout, NAT/방화벽 세션 만료, keepalive 설정, 네트워크 불안정
  • kex_exchange_identification / banner exchange 오류: 과도한 연결/Fail2ban/sshd MaxStartups, L7 장비 간섭

클라이언트에서 우선 아래처럼 디버그 로그를 남겨 끊기는 지점을 파악하세요.

ssh -vvv user@server.example.com

서버에서는 동시에 다음을 켜두면 원인 추적이 빨라집니다.

# Debian/Ubuntu
sudo tail -f /var/log/auth.log

# RHEL/CentOS/Rocky
sudo tail -f /var/log/secure

# systemd journal
sudo journalctl -u ssh -f
# 또는 배포판에 따라 sshd
sudo journalctl -u sshd -f

1) 방화벽/NACL/보안그룹에서 22번 포트 드롭

가장 흔한 원인입니다. 클라이언트에서 timeout이라면 “서버까지 패킷이 도달하지 않는다” 쪽을 먼저 의심합니다.

체크

# 클라이언트에서 포트 도달성 확인
nc -vz server.example.com 22
# 또는
timeout 3 bash -c '</dev/tcp/server.example.com/22' && echo OK || echo FAIL

서버 측에서 22번 포트 리슨 여부:

sudo ss -lntp | grep ':22'

클라우드라면 Security Group / NACL / Firewall 정책에서 소스 IP가 바뀌었는지(재택/모바일/사내 NAT)부터 확인하세요.

2) 사내/클라우드 NAT의 Idle Timeout(유휴 세션 만료)

“접속은 되는데 가만히 두면 끊김”의 대표 원인입니다. 방화벽/NAT 장비는 일정 시간 트래픽이 없으면 TCP 세션을 정리합니다.

해결: SSH KeepAlive 설정

클라이언트(~/.ssh/config)에 권장 설정:

Host *
  ServerAliveInterval 30
  ServerAliveCountMax 3
  TCPKeepAlive yes
  • ServerAliveInterval: 클라이언트가 30초마다 keepalive 패킷 전송
  • ServerAliveCountMax: 3회 응답 없으면 종료(무한정 매달리지 않음)

서버(/etc/ssh/sshd_config)에서도 보완 가능:

ClientAliveInterval 60
ClientAliveCountMax 3

적용:

sudo systemctl reload sshd || sudo systemctl reload ssh

3) 서버 리소스 고갈(CPU/메모리/IO)로 sshd 응답 지연

서버가 과부하 상태면 TCP 연결은 되더라도 키 교환(KEX) 단계에서 지연/timeout이 발생할 수 있습니다. 특히 디스크 IO가 막히면 인증/로그 기록이 느려져 체감상 “SSH가 멈춘다”가 됩니다.

체크

uptime
vmstat 1 5
free -h

# IO 병목
iostat -xz 1 5
# 또는
sudo pidstat -d 1 5

메모리 압박으로 OOM이 발생하면 sshd나 관련 프로세스가 죽을 수도 있습니다. 컨테이너/노드 단위 메모리 진단이 필요하다면 K8s OOMKilled 반복? cgroup v2 메모리 진단도 같이 참고하면 좋습니다(원리 자체는 리눅스 메모리 압박 진단에 동일하게 적용됩니다).

4) 디스크 가득 참(특히 /var, /tmp)으로 로그인/세션 생성 실패

디스크가 100%면 auth.log 기록, pam 처리, sshd의 임시 파일 생성이 실패하면서 접속이 끊기거나 인증이 비정상 동작할 수 있습니다.

체크

df -h
sudo du -xh /var | sort -h | tail -n 20

로그 폭주/디스크 압박이 반복된다면 원인 서비스가 재시작 루프를 타는 경우도 많습니다. 이럴 땐 systemd 서비스 재시작 루프 10분 진단 가이드처럼 “무엇이 로그를 폭증시키는지” 먼저 잡는 게 빠릅니다.

5) sshd 설정: MaxStartups/MaxSessions/로그인 제한으로 연결이 끊김

동시에 많은 접속이 몰리거나(배치/자동화/모니터링), 브루트포스가 들어오면 sshd가 신규 연결을 드롭할 수 있습니다.

체크 포인트

  • /etc/ssh/sshd_config:
    • MaxStartups (인증 전 연결 제한)
    • MaxSessions (하나의 TCP 연결에서 세션 수 제한)

예시(상황에 맞게 조정):

MaxStartups 30:50:100
MaxSessions 50

현재 접속/세션 상태:

who
w
ss -tn state established '( sport = :22 )'

주의: 값만 올리면 공격 트래픽에 더 취약해질 수 있으니, 7)~8) 항목(차단 정책/레이트 리밋)과 같이 조합하세요.

6) DNS/역방향 DNS(rDNS) 지연으로 접속이 느리거나 timeout

sshd는 접속 IP에 대해 역방향 DNS를 확인하는 경우가 있습니다. DNS가 느리거나 잘못 구성되면 인증 전 단계가 지연되어 timeout처럼 보일 수 있습니다.

체크

서버에서 클라이언트 IP에 대해:

# 클라이언트 IP를 1.2.3.4로 가정
getent hosts 1.2.3.4

# 역방향 조회
dig -x 1.2.3.4 +short

완화(필요 시):

# /etc/ssh/sshd_config
UseDNS no

보안/감사 요구가 있는 환경에선 UseDNS를 끄기 전에 정책 확인이 필요합니다.

7) Fail2ban/IDS/방화벽 자동 차단으로 “갑자기” 접속 불가

비밀번호 로그인 시도 실패가 누적되거나, 특정 패턴이 탐지되면 IP가 차단됩니다. 이 경우는 Connection timed out 또는 No route to host처럼 보일 수도 있고, 장비에 따라 Connection reset이 날 수도 있습니다.

체크

sudo iptables -S | head
sudo nft list ruleset | head -n 50

# fail2ban 사용 시
sudo fail2ban-client status
sudo fail2ban-client status sshd

차단 해제/화이트리스트는 운영 정책에 맞춰 진행하세요.

8) 클라이언트 측 네트워크 변경(Wi‑Fi↔LTE, VPN 재연결)로 TCP 세션 단절

노트북이 슬립/절전, 네트워크가 바뀌는 순간 기존 TCP 세션은 유지되지 않습니다. 사용자는 “SSH가 끊겼다”고 느끼지만 사실 클라이언트 환경 변화입니다.

대응

  • 장시간 작업은 tmux/screen으로 서버에서 세션을 유지
  • 자동 재연결이 필요하면 autossh 고려
# 서버에서
tmux new -s work
# 끊겼다가 재접속 후
tmux attach -t work

9) MTU/MSS 문제(특히 VPN/터널)로 특정 구간에서만 멈춤

VPN, GRE, IPsec, WireGuard, 클라우드 VPC 피어링 등에서 MTU가 맞지 않으면 초기 연결은 되는데 대용량 패킷 구간에서 멈추거나 재전송이 반복되어 timeout이 발생합니다.

체크

경로 MTU 추정(DF 비트, ping 크기 조절):

# Linux
ping -M do -s 1472 server.example.com
# 실패하면 크기를 줄여가며 성공하는 최대값을 찾습니다.

증상이 애매하면 패킷 캡처가 결정적입니다.

sudo tcpdump -i any port 22 -nn -vv

10) sshd/암호화 알고리즘 협상 문제(구형 장비/레거시 설정)

구형 OS/네트워크 장비/보안 정책 때문에 특정 KEX/HostKey/암호 스위트가 막혀 협상이 실패할 수 있습니다. 이때 클라이언트 -vvv 로그에 “no matching … found” 류가 뜹니다.

체크 및 임시 우회

클라이언트에서 지원 알고리즘 확인:

ssh -Q kex
ssh -Q cipher
ssh -Q key

임시로 알고리즘을 지정(보안 정책 검토 후 최소 범위로):

ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 \
    -oHostKeyAlgorithms=+ssh-rsa \
    user@server.example.com

가능하면 서버/클라이언트 OpenSSH를 업데이트하고, 레거시 알고리즘 활성화는 “최후의 수단”으로만 사용하세요.

빠른 체크리스트(현장용)

아래 순서로 보면 대부분 빠르게 결론이 납니다.

  1. 클라이언트: ssh -vvv, nc -vz host 22
  2. 서버: ss -lntp | grep :22, journalctl -u sshd -f
  3. 네트워크: 보안그룹/방화벽/NAT idle timeout 여부
  4. 리소스: uptime, vmstat, iostat, df -h
  5. 정책/차단: fail2ban, iptables/nft
  6. 환경: VPN/MTU, Wi‑Fi↔LTE 전환, 슬립

마무리

SSH 끊김/Timeout은 단일 원인보다 **네트워크(드롭/세션만료/MTU) + 서버 상태(리소스/디스크) + sshd 정책(제한/알고리즘)**이 겹쳐 발생하는 경우가 많습니다. 위 10가지를 순서대로 체크하면 “감으로 설정을 바꾸는” 시행착오를 줄이고, 로그와 지표로 원인을 좁힐 수 있습니다.

추가로 서버가 불안정해 재부팅/복구가 필요한 상황이라면(특히 클라우드 VM) 부팅 로그 기반 복구 흐름을 정리한 Azure VM 부팅 불가? Boot Diagnostics로 복구도 함께 참고하면 장애 대응에 도움이 됩니다.

Discuss on Twitter • View on GitHub