- Published on
리눅스 SSH 로그인 지연·멈춤 해결(SSSD·DNS)
- Authors
- Name
- 스타차일드
- https://x.com/ETFBITX
서버에 ssh user@host로 접속하면 비밀번호(또는 키 인증) 이후에 멈춘 듯 멈추거나, 로그인 프롬프트가 뜨기까지 수십 초 지연되는 경우가 있습니다. 네트워크 자체는 살아있고 TCP 22 포트도 열려 있는데, 인증 이후 단계에서 멈추는 것이 특징입니다.
이 문제는 대부분 다음 두 축에서 발생합니다.
- SSSD(또는 LDAP/AD 연동) 조회 지연:
id,getent passwd, 그룹 조회가 느려 PAM/NSS 단계에서 SSH가 대기 - DNS/역방향(PTR) 조회 지연:
UseDNS/GSSAPI/호스트네임 확인 과정에서 resolver가 타임아웃
이 글은 “지연을 재현/측정 → 병목 구간을 분리 → SSSD/DNS를 각각 최적화” 순으로 정리합니다.
> 네트워크/DNS 이슈는 쿠버네티스에서도 자주 증폭됩니다. IPv6/DNS 점검 관점은 EKS에서 IPv6만 통신 실패 - CNI·SG·DNS 점검도 함께 참고하면 원인 분리가 빨라집니다.
증상 패턴과 “어디서 멈추는지” 빠르게 구분하기
1) SSH 디버그 로그로 단계 확인
클라이언트에서 가장 먼저 할 일은 -vvv로 멈추는 지점을 보는 것입니다.
ssh -vvv user@server
Authenticated to ...이후 멈춤: 서버 측 PAM/NSS/SSSD/DNS 역조회 가능성이 큼Connecting to .../kex_exchange_identification단계에서 지연: 방화벽/네트워크/IDS/MTU 등 다른 이슈
2) 서버에서 “로그인 시각”과 “세션 시작 시각” 비교
서버에 콘솔/세컨드 채널로 들어갈 수 있다면(예: 클라우드 콘솔, SSM, iDRAC) 아래를 봅니다.
sudo journalctl -u sshd --since "10 min ago" -o short-iso
sudo tail -n 200 /var/log/secure 2>/dev/null || true
sudo tail -n 200 /var/log/auth.log 2>/dev/null || true
- 인증은 성공했는데
session opened까지 시간이 길면 PAM/NSS 쪽 reverse mapping checking getaddrinfo같은 로그가 보이면 DNS 역조회 쪽
DNS(역방향 조회) 때문에 SSH가 느려지는 경우
SSH는 접속한 클라이언트 IP에 대해 역방향(PTR) 조회를 하거나, GSSAPI(Kerberos)에서 DNS를 사용하며, 일부 환경에서는 호스트 기반 접근 제어에 DNS가 개입합니다. DNS가 타임아웃 나면 그만큼 SSH가 기다립니다.
1) sshd 설정에서 DNS 조회 비활성화(가장 흔한 즉시 처방)
서버에서 /etc/ssh/sshd_config를 확인합니다.
sudo sshd -T | egrep -i 'usedns|gssapi'
권장 조합(AD/Kerberos를 쓰지 않는 일반 서버 기준):
# /etc/ssh/sshd_config
UseDNS no
GSSAPIAuthentication no
적용:
sudo systemctl restart sshd
UseDNS no: 접속 클라이언트에 대한 역방향 조회를 하지 않음GSSAPIAuthentication no: Kerberos/GSSAPI 시도 자체를 끔(필요한 환경이라면 끄면 안 됨)
2) resolver 타임아웃/서치 도메인으로 인한 지연 점검
DNS 서버가 죽어있거나, 잘못된 search domain 때문에 여러 번 재시도하면 로그인 시간이 길어질 수 있습니다.
cat /etc/resolv.conf
resolvectl status 2>/dev/null || true
특히 아래가 문제를 키웁니다.
- 사내 DNS로 향하는데 외부망/격리망에서 접근 불가
search corp.local corp처럼 탐색 도메인이 많고, 짧은 호스트네임을 자주 조회options timeout:2 attempts:5처럼 재시도가 길게 잡힘
테스트는 dig로 PTR 조회를 직접 해보면 됩니다.
# 접속 클라이언트 IP가 203.0.113.10 이었다고 가정
DIG="dig +time=1 +tries=1"
$DIG -x 203.0.113.10
# 정방향도 같이
$DIG server.example.com A
- 여기서 1초 내 응답이 안 오면 SSH 지연의 강력한 후보입니다.
3) systemd-resolved/NetworkManager 환경에서 캐시/업스트림 점검
Ubuntu/Debian 계열에서 systemd-resolved가 중간 캐시/포워더 역할을 하며 업스트림이 느리면 그대로 영향을 받습니다.
sudo journalctl -u systemd-resolved --since "10 min ago"
resolvectl query example.com
업스트림 DNS를 바꾸거나(예: VPC DNS), 로컬 캐시를 재시작해 증상을 즉시 완화할 수 있습니다.
sudo systemctl restart systemd-resolved
SSSD 때문에 SSH가 느려지는 경우(AD/LDAP/NSS/PAM 병목)
SSSD는 NSS(Name Service Switch)와 PAM(Pluggable Authentication Modules)에 붙어 사용자/그룹 조회, 인증, 권한 결정에 관여합니다. SSSD가 느려지면 SSH는 로그인 과정에서 id user, 그룹 매핑, sudo 규칙 등을 조회하다가 대기합니다.
1) 가장 빠른 확인: id/getent가 느린지 측정
SSH가 느린 서버에서 아래가 느리면 거의 확정입니다.
time id someuser
time getent passwd someuser
time getent group somegroup
- 수 초~수십 초 걸리면 SSSD/LDAP/AD/DNS 중 하나가 병목
2) SSSD 상태/로그 확인
sudo systemctl status sssd --no-pager
sudo journalctl -u sssd --since "30 min ago" | tail -n 200
# SSSD 자체 로그(배포판/설정에 따라 경로 다름)
sudo ls -al /var/log/sssd/ 2>/dev/null || true
자주 보이는 원인:
- AD/LDAP 서버로의 네트워크 지연/방화벽
- DNS SRV 조회 실패(AD 도메인 컨트롤러 탐색)
- 시간이 틀어져 Kerberos/LDAP TLS 인증이 지연/실패
- 캐시 DB 손상 또는 과도한 캐시 미스
> 시간 드리프트는 인증 계열 장애를 비정상적으로 느리게 만들기도 합니다. 컨테이너/노드 시간 문제를 다룬 EKS Pod 시간 드리프트로 STS·TLS 실패 해결하기처럼, NTP/chrony 상태도 함께 확인하는 습관이 좋습니다.
3) SSSD 설정에서 “오프라인/캐시” 전략 점검
/etc/sssd/sssd.conf는 성능과 장애 내성을 크게 좌우합니다. (권한 600 필수)
sudo stat -c '%a %n' /etc/sssd/sssd.conf
sudo cat /etc/sssd/sssd.conf
아래는 로그인 지연 완화에 자주 쓰는 옵션 예시입니다(환경에 맞게 조정 필요).
# /etc/sssd/sssd.conf (예시)
[sssd]
services = nss, pam
config_file_version = 2
domains = example.com
[nss]
# 그룹 조회 폭발을 줄이는 데 도움이 될 수 있음
ignore_group_members = True
[pam]
# 네트워크가 불안정할 때 오프라인 캐시로 로그인 허용
offline_credentials_expiration = 7
[domain/example.com]
id_provider = ad
access_provider = ad
cache_credentials = True
# DNS/네트워크 이슈로 AD 탐색이 느릴 때, DC를 고정하면 개선되는 경우가 많음
#ad_server = dc1.example.com, dc2.example.com
# 너무 잦은 갱신/조회로 지연이 생기면 튜닝 포인트
entry_cache_timeout = 600
entry_cache_user_timeout = 600
entry_cache_group_timeout = 600
# LDAP/AD 응답이 느릴 때 타임아웃을 명시적으로 줄여 "빨리 실패"하게 만들 수도 있음
#ldap_network_timeout = 3
변경 후:
sudo chmod 600 /etc/sssd/sssd.conf
sudo systemctl restart sssd
ignore_group_members = True가 효과적인 케이스
대규모 AD에서 한 사용자가 수백/수천 그룹에 속하면, 로그인 시 그룹 멤버십 확장 조회가 폭발하며 지연이 커질 수 있습니다. 이 옵션은 그룹 멤버 목록을 NSS에 넘기는 방식을 단순화해 조회량을 줄여주는 데 도움이 됩니다(대신 일부 그룹 멤버 목록 조회 동작이 달라질 수 있어 검증 필요).
4) 캐시 정리로 “갑자기 느려짐” 복구
SSSD 캐시가 꼬이거나 오래된 레코드로 반복 실패하면 지연이 심해질 수 있습니다.
# 캐시/DB 정리(운영 영향 고려)
sudo sss_cache -E
sudo systemctl restart sssd
더 강하게 초기화해야 한다면(권장 전: 백업/점검):
sudo systemctl stop sssd
sudo rm -f /var/lib/sss/db/*
sudo systemctl start sssd
5) PAM에서 불필요한 모듈/조회가 로그인 시간을 늘리는지 확인
pam_sss.so 외에도 pam_mkhomedir, pam_mount, pam_access, pam_ldap 등이 체인에 있으면, 하나만 느려도 전체가 느려집니다.
배포판별로 경로가 다르지만 보통 아래를 확인합니다.
# RHEL/CentOS/Rocky
sudo cat /etc/pam.d/sshd
# Ubuntu/Debian
sudo cat /etc/pam.d/sshd
sudo cat /etc/pam.d/common-auth
sudo cat /etc/pam.d/common-account
특히 네트워크 파일시스템 마운트나 홈디렉터리 생성이 느리면 SSH가 멈춘 것처럼 보입니다.
“DNS vs SSSD” 5분 컷 진단 체크리스트
1) 서버에서 즉시 실행
# 1) sshd가 DNS 조회하는지
sudo sshd -T | grep -i usedns
# 2) 접속자 IP 역조회가 느린지(예: CLIENT_IP)
dig +time=1 +tries=1 -x CLIENT_IP
# 3) 사용자/그룹 조회가 느린지
time getent passwd $USER
time id $USER
판정 가이드:
dig -x가 느리다 → UseDNS/GSSAPI/resolv.conf부터getent/id가 느리다 → SSSD/AD/LDAP/DNS SRV/시간 동기화부터- 둘 다 느리다 → DNS가 SSSD에도 영향을 주는 구조일 수 있음(AD SRV 조회 등). DNS를 먼저 안정화하는 편이 보통 효율적
운영 환경에서의 안전한 개선 순서(권장)
- 증상 재현 + 시간 측정:
ssh -vvv,time getent,dig +time=1 - sshd에서 불필요한 DNS/GSSAPI 끄기:
UseDNS no, (필요 없으면)GSSAPIAuthentication no - resolver 안정화:
/etc/resolv.conf의 nameserver/search/options 정리, 죽은 DNS 제거 - SSSD 튜닝/고정: DC 고정(
ad_server), 캐시(cache_credentials), 그룹 조회 폭발 완화 - 로그인 체인(PAM) 슬림화: 느린 모듈 제거/순서 조정
> 장애 원인 분리/로그 기반 디버깅은 인프라 전반에서 공통입니다. 애플리케이션 레벨에서 타임아웃을 추적하는 흐름은 gRPC 마이크로서비스 503·데드라인 초과 디버깅도 비슷한 접근을 제공합니다.
마무리: “인증 이후 멈춤”은 대개 조회 지연이다
SSH 로그인 지연은 ‘SSH가 느리다’기보다, SSHD가 의존하는 이름/계정 조회가 느린 것인 경우가 대부분입니다. 특히 AD/LDAP를 붙인 서버에서 DNS가 불안정하면 SSSD가 도메인 컨트롤러 탐색부터 지연되고, 그 여파가 SSH 로그인 멈춤으로 보입니다.
이 글의 순서대로 dig -x와 getent/id 두 축만 빠르게 측정해도, 원인의 80%는 10분 안에 좁힐 수 있습니다. 이후에는 sshd_config에서 DNS/GSSAPI를 정리하고, resolver/SSSD를 안정화해 “로그인 지연”을 구조적으로 없애는 것이 최종 해법입니다.