- Published on
리눅스 SSH 접속 지연·끊김, auth.log로 추적하기
- Authors
- Name
- 스타차일드
- https://x.com/ETFBITX
서버에서 ssh 접속이 유독 느리거나(비밀번호 입력 전 수 초~수십 초 멈춤), 로그인 직후 끊기거나, 간헐적으로 Connection reset 류 오류가 발생하면 보통 네트워크만 의심하기 쉽습니다. 하지만 실제 현장에서는 sshd 인증 경로(키 교환, 계정 조회, PAM, DNS 역조회, GSSAPI, Fail2ban 등) 중 어디에서 시간이 소비되는지부터 확인해야 빠르게 좁힐 수 있습니다.
이 글은 auth.log(Debian/Ubuntu 계열) 또는 secure(RHEL/CentOS 계열)를 기준으로, SSH 지연·끊김을 “로그로 증명”하면서 원인을 확정하는 흐름을 다룹니다.
1) 먼저 확인: 로그 파일 위치와 로그 레벨
배포판별 파일
- Ubuntu/Debian:
/var/log/auth.log - RHEL/CentOS/Rocky/Alma:
/var/log/secure - systemd 환경:
journalctl -u ssh또는journalctl -u sshd
auth.log가 비어 있거나 정보가 부족하면 sshd 로그 레벨을 잠깐 올려 재현하는 것이 가장 빠릅니다.
/etc/ssh/sshd_config 예시:
LogLevel VERBOSE
# 더 자세히가 필요하면 DEBUG, DEBUG2, DEBUG3도 가능(운영에서는 단기간만)
설정 반영:
sudo systemctl reload sshd # 또는 ssh
운영 팁: DEBUG3는 로그가 폭발적으로 늘 수 있으니, 재현이 끝나면 LogLevel을 원복하세요.
2) 증상 분류: “어느 구간”에서 느린가
SSH 접속은 대략 다음 단계로 지나갑니다.
- TCP 연결
- 키 교환 및 알고리즘 협상
- 사용자 인증(공개키, 패스워드, 키보드-인터랙티브)
- PAM 세션 오픈(환경 구성, 홈 디렉터리, 모듈 실행)
- 셸 실행 및 세션 유지
auth.log는 특히 34 구간의 단서를 잘 줍니다. 반대로 12 구간은 auth.log만으로 부족할 수 있어 sshd의 디버그 로그나 tcpdump가 필요합니다.
3) auth.log를 “시간축”으로 읽는 방법
실전: 특정 IP만 필터링
grep -E "sshd\[|ssh" /var/log/auth.log | grep "203.0.113.10"
실전: 접속 시각 주변만 보기
# 예: 02:10~02:12 사이
sed -n 's/^/ /p' /var/log/auth.log | grep "Feb 24 02:1[0-2]" | grep sshd
핵심 포인트
- 한 번의 접속 시도는 보통 같은
sshd[PID]로 묶입니다. - 지연이 있다면, 같은
PID로그 사이의 “시간 간격”이 비정상적으로 벌어집니다.
예시(시간이 벌어지는 지점이 병목 후보):
Feb 24 02:10:01 host sshd[12345]: Connection from 203.0.113.10 port 51234 on 10.0.0.10 port 22
Feb 24 02:10:01 host sshd[12345]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=203.0.113.10
Feb 24 02:10:25 host sshd[12345]: Accepted password for ubuntu from 203.0.113.10 port 51234 ssh2
위 로그는 pam_unix 실패 이후 Accepted까지 24초가 비어 있습니다. 이 경우 “패스워드 입력 지연”이 아니라, 인증 경로 어딘가가 24초 동안 막혔다는 뜻입니다(PAM 모듈, 계정 조회, DNS 역조회 등).
4) 가장 흔한 원인 1: DNS 역조회 지연(UseDNS)
SSH가 클라이언트 IP를 역조회(PTR)하거나 정방향 확인을 하며 멈추는 케이스가 매우 흔합니다. 특히 사설망에서 DNS가 불안정하거나, 역조회가 타임아웃까지 끌리는 환경에서 “비밀번호 입력 전 멈춤”으로 나타납니다.
auth.log 단서
auth.log에는 DNS 역조회 자체가 명시적으로 안 찍힐 수 있습니다. 대신 다음과 같은 패턴이 보입니다.
Connection from ...이후 다음 로그까지 시간이 길게 비어 있음Invalid user또는Accepted로그가 늦게 등장
해결: UseDNS no
/etc/ssh/sshd_config:
UseDNS no
반영:
sudo systemctl reload sshd
추가로, sshd_config에 GSSAPIAuthentication이 켜져 있으면(특히 Kerberos 미사용 환경) 지연이 생길 수 있어 함께 확인합니다.
GSSAPIAuthentication no
5) 가장 흔한 원인 2: PAM/계정 조회(SSSD, LDAP, AD) 지연
도메인 계정(AD/LDAP) 또는 sssd를 사용하는 서버에서, 디렉터리 서버 응답이 느리거나 간헐적으로 실패하면 SSH가 “로그인 직전” 또는 “로그인 직후”에 끊기거나 멈춥니다.
auth.log에서 보이는 형태
pam_sss(sshd:auth)또는pam_ldap관련 메시지Authentication failure가 반복되거나,Accepted가 늦게 찍힘- 세션 단계에서
pam_unix(sshd:session)이후 끊김
예시:
Feb 24 02:11:03 host sshd[13001]: pam_sss(sshd:auth): received for user dev: 7 (Authentication failure)
Feb 24 02:11:33 host sshd[13001]: Accepted password for dev from 203.0.113.10 port 53321 ssh2
30초 간격은 네트워크 타임아웃/재시도일 가능성이 큽니다.
함께 보면 좋은 로그
journalctl -u sssd -S "-10 min"/var/log/sssd/하위 로그
대응 방향
- 디렉터리 서버 상태/네트워크 확인
sssd캐시 및 타임아웃 튜닝- 장애 시 로컬 계정으로 우회 가능한지(운영 정책) 검토
서비스가 재시작을 반복하거나 타임아웃으로 죽었다 살아나는 경우가 있다면, 원인 추적 관점에서 아래 글의 접근이 그대로 적용됩니다.
6) 가장 흔한 원인 3: Fail2ban/방화벽/Rate limit로 인한 끊김
SSH 브루트포스가 많거나, fail2ban/방화벽이 공격으로 오탐하여 차단하면 “비밀번호 입력 후 바로 끊김” 또는 “특정 네트워크만 간헐적 실패”가 발생합니다.
auth.log 단서
Failed password가 매우 많이 찍힘- 동일 IP에 대해
Disconnecting: Too many authentication failures같은 메시지
예시:
Feb 24 02:12:10 host sshd[14002]: Failed password for invalid user admin from 198.51.100.20 port 60001 ssh2
Feb 24 02:12:12 host sshd[14002]: error: maximum authentication attempts exceeded for invalid user admin from 198.51.100.20 port 60001 ssh2 [preauth]
Feb 24 02:12:12 host sshd[14002]: Disconnecting: Too many authentication failures [preauth]
점검
sudo fail2ban-client status
sudo fail2ban-client status sshd
sudo iptables -S | grep -i 22
sudo nft list ruleset | grep -i 22
원인 자체가 SSH가 아니라 “서버가 공격 트래픽으로 과부하”인 경우도 많습니다. CI 러너나 자동화 에이전트가 멈추는 현상과 결이 비슷하게 나타나기도 합니다.
7) 로그인 직후 끊김: 셸/프로파일/리소스 제한을 의심
인증은 성공했는데 바로 끊기는 경우, auth.log에는 보통 Accepted까지만 깔끔하게 찍히고 이후가 빈약할 수 있습니다. 이때는 다음을 추가로 봐야 합니다.
journalctl -u sshd에서 세션 종료 사유- 사용자 셸 초기화 파일(
.bashrc,.profile)에서 블로킹 명령(예: 네트워크 호출) ForceCommand또는Match User설정ulimit/pam_limits로 인해 프로세스 생성 실패
auth.log에서 세션 단계 단서
예시:
Feb 24 02:13:01 host sshd[15001]: Accepted publickey for ops from 203.0.113.10 port 51111 ssh2: RSA SHA256:...
Feb 24 02:13:01 host sshd[15001]: pam_unix(sshd:session): session opened for user ops(uid=1001) by (uid=0)
Feb 24 02:13:02 host sshd[15001]: pam_unix(sshd:session): session closed for user ops
session opened 직후 session closed가 바로 붙으면, 셸 실행 실패/즉시 종료/강제 종료 신호 등을 의심합니다.
8) 재현을 빠르게 만드는 클라이언트 측 옵션
서버 로그만 보며 추측하지 말고, 클라이언트에서 디버그 출력을 함께 확보하면 원인 구간이 확 줄어듭니다.
ssh -vvv user@server.example.com
여기서 debug1: Authenticating to ... 이후 멈추는지, debug1: Entering interactive session 이후 끊기는지로 1차 분류가 됩니다.
또한 keepalive 관련 끊김(특히 NAT, L4 idle timeout) 의심 시에는 아래도 확인합니다.
서버 /etc/ssh/sshd_config:
ClientAliveInterval 30
ClientAliveCountMax 3
클라이언트 ~/.ssh/config:
Host myserver
HostName server.example.com
ServerAliveInterval 30
ServerAliveCountMax 3
주의: keepalive는 “원인 제거”가 아니라 “중간 장비의 idle timeout 회피” 성격입니다. 근본 원인은 L4/방화벽/프록시의 세션 만료 정책일 수 있습니다.
9) 한 번에 정리: auth.log 기반 체크리스트
아래 순서대로 보면 대부분의 SSH 지연·끊김 이슈는 30분 내에 방향이 잡힙니다.
auth.log에서 문제 시각의sshd[PID]묶음을 찾고, 로그 사이 시간 간격이 벌어지는 지점을 표시Connection from ...다음이 느리면UseDNS,GSSAPIAuthentication우선 의심pam_sss/pam_ldap가 보이면 디렉터리 의존성(SSSD/LDAP/AD) 상태 확인Too many authentication failures,Failed password폭증이면 공격/차단/레이트리밋 확인session opened직후session closed면 셸/프로파일/ForceCommand/리소스 제한 확인- 클라이언트
ssh -vvv출력과 서버auth.log타임라인을 맞춰 “어느 단계가 느린지” 확정
10) 빠른 트러블슈팅 예시(명령 모음)
아래는 운영에서 자주 쓰는 “한 세트”입니다.
# 1) 실시간으로 sshd 관련 auth.log 보기
sudo tail -f /var/log/auth.log | grep sshd
# 2) 특정 사용자/아이피만 보기
sudo grep "sshd" /var/log/auth.log | grep "Accepted" | tail -n 50
sudo grep "sshd" /var/log/auth.log | grep "203.0.113.10" | tail -n 200
# 3) systemd 저널에서 sshd만 보기(배포판에 따라 ssh 또는 sshd)
sudo journalctl -u sshd -S "-30 min"
# 4) 현재 sshd 설정 중 의심 옵션 확인
sudo sshd -T | egrep "usedns|gssapiauthentication|clientalive|maxauthtries|loglevel"
sshd -T는 실제 적용되는 최종 설정을 출력하므로, Match 블록이 섞여 있을 때 특히 유용합니다.
SSH 지연·끊김은 원인이 여러 갈래로 퍼져 있어 “설정 몇 개 바꿔보자”로 접근하면 시간만 낭비하기 쉽습니다. auth.log를 중심으로 PID 단위 타임라인을 만들고, 지연이 발생하는 정확한 단계(역조회, PAM, 디렉터리 조회, 세션 오픈)를 확정한 뒤 조치하면 재발률도 크게 줄일 수 있습니다.