기술자료

적용 환경과 지원 상태

1. SSH 접속이 느려지는 구간 확인

SSH 지연은 발생 시점에 따라 원인이 달라집니다. 클라이언트에서 상세 로그를 활성화하면 TCP 연결, 키 교환, 인증, 셸 실행 중 어느 단계에서 멈추는지 확인할 수 있습니다.

ssh -vvv [email protected]

admin_user는 실제 사용자명으로, 203.0.113.10은 실제 서버 IP로 변경합니다. SSH 포트가 기본 22번이 아니라면 -p 포트번호를 추가합니다.

ssh -vvv -p 2222 [email protected]

2. 서버 상태와 SSH 로그 확인

먼저 운영체제 버전, OpenSSH 서버 패키지, 서비스 상태와 실제 수신 포트를 확인합니다. 서버 설정을 변경하기 전에 현재 상태를 기록해 두면 원인 분석과 원상복구가 쉬워집니다.

cat /etc/centos-release
rpm -q openssh-server
sudo systemctl status sshd.service --no-pager -l
sudo systemctl is-active sshd.service
sudo ss -lntp | grep sshd

sshd.service가 active이고 설정된 SSH 포트에서 수신 중이어야 합니다. 서비스가 반복해서 재시작되거나 CPU 사용량이 높은 경우에는 DNS나 GSSAPI보다 데몬 오류 또는 과도한 접속 시도를 먼저 확인해야 합니다.

접속 시점의 인증 로그 확인

CentOS 7에서는 보안·인증 관련 메시지가 일반적으로 /var/log/secure에 기록되며, systemd 저널에서도 sshd 서비스 로그를 확인할 수 있습니다. 한 터미널에서 로그를 관찰하고 다른 터미널에서 SSH 접속을 시도합니다.

sudo tail -f /var/log/secure

systemd 저널을 사용하는 경우에는 다음 명령을 실행합니다.

sudo journalctl -u sshd.service -f

클라이언트가 접속을 시작한 시각과 서버 로그에 첫 메시지가 기록되는 시각을 비교합니다. 로그 자체가 늦게 나타나면 네트워크 또는 연결 처리 문제를, 로그는 즉시 나타나지만 인증 단계가 오래 걸리면 DNS·GSSAPI·PAM 계층을 우선 점검합니다.

3. 역방향 DNS 조회 지연 해결

SSH 서버가 접속한 클라이언트 IP의 호스트 이름을 조회하려고 할 때 DNS 서버가 응답하지 않거나 PTR 레코드가 잘못되어 있으면 인증 화면이 늦게 표시될 수 있습니다. 특히 사설망, VPN, 동적 공인 IP 또는 외부 DNS에 역방향 영역이 없는 환경에서 자주 발생합니다.

클라이언트 IP의 이름 조회 시간 측정

아래 예시의 198.51.100.20을 실제 SSH 클라이언트 IP로 변경합니다. 명령이 즉시 끝나지 않고 수 초 이상 대기한다면 이름 조회 경로를 점검해야 합니다.

time getent hosts 198.51.100.20
grep '^hosts:' /etc/nsswitch.conf
cat /etc/resolv.conf

/etc/resolv.conf의 DNS 서버에 연결할 수 있는지, /etc/nsswitch.conf의 hosts: 항목에 더 이상 사용하지 않는 nis, ldap, mdns 같은 조회 모듈이 포함되어 있지 않은지 확인합니다. 조직의 네트워크 정책을 알지 못한 상태에서 해당 항목을 임의로 삭제하지 마십시오.

고정 관리 IP를 /etc/hosts에 등록

SSH 관리용 클라이언트가 고정 IP를 사용하고 DNS 레코드를 만들 수 없다면 서버의 /etc/hosts에 해당 IP와 호스트 이름을 등록할 수 있습니다.

198.51.100.20 admin-pc.example.com admin-pc

동적 IP나 여러 사용자가 접속하는 공개 서버에서는 /etc/hosts를 지속적으로 관리하기 어렵습니다. 이 경우에는 DNS의 정방향·역방향 레코드를 정상화하거나 SSH 서버의 불필요한 이름 조회를 비활성화하는 방법을 사용합니다.

sshd에서 UseDNS 비활성화

현재 유효한 설정값을 먼저 확인합니다.

sudo /usr/sbin/sshd -T | grep '^usedns '

설정 변경 전 원본 파일을 백업합니다.

sudo cp -a /etc/ssh/sshd_config "/etc/ssh/sshd_config.bak-$(date +%Y%m%d-%H%M%S)"

/etc/ssh/sshd_config를 편집하고 기존 UseDNS 항목을 찾아 다음과 같이 설정합니다. 동일한 지시문을 여러 번 추가하지 말고 기존 값을 수정하는 것이 좋습니다.

UseDNS no

문법을 검사한 뒤 설정을 다시 읽도록 합니다. sshd -t에서 출력이 없고 종료 코드가 0이면 기본 문법 검사를 통과한 것입니다.

sudo /usr/sbin/sshd -t
sudo systemctl reload sshd.service
sudo /usr/sbin/sshd -T | grep '^usedns '

4. GSSAPI 인증 지연 해결

GSSAPI는 Kerberos 기반 통합 인증에 사용할 수 있지만, Kerberos·Active Directory·FreeIPA 환경을 사용하지 않는 서버에서 활성화되어 있으면 클라이언트와 서버가 불필요한 자격 증명 또는 DNS 조회를 시도하면서 접속이 지연될 수 있습니다.

클라이언트에서 일회성 비교 테스트

먼저 서버 설정을 변경하지 않고 클라이언트에서 GSSAPI 인증을 끈 상태로 접속 시간을 비교합니다.

time ssh -o GSSAPIAuthentication=no [email protected]

이 명령에서는 접속이 즉시 이루어지고 일반 접속만 느리다면 GSSAPI 또는 Kerberos 조회 경로가 원인일 가능성이 높습니다.

서버의 GSSAPI 인증 비활성화

현재 유효한 값을 확인합니다.

sudo /usr/sbin/sshd -T | grep '^gssapiauthentication '

Kerberos SSO를 사용하지 않는 것이 확인되면 /etc/ssh/sshd_config의 설정을 다음과 같이 변경합니다.

GSSAPIAuthentication no

문법 검사 후 SSH 데몬이 설정을 다시 읽도록 합니다.

sudo /usr/sbin/sshd -t
sudo systemctl reload sshd.service
sudo /usr/sbin/sshd -T | grep '^gssapiauthentication '

클라이언트별로만 GSSAPI 비활성화

서버 전체 설정을 변경할 수 없거나 특정 서버에서만 지연이 발생한다면 Linux·macOS 클라이언트의 ~/.ssh/config에 호스트별 설정을 추가할 수 있습니다.

Host centos7-server
    HostName 203.0.113.10
    User admin_user
    GSSAPIAuthentication no

설정 후에는 ssh centos7-server로 접속할 수 있습니다. 이 방식은 다른 SSH 서버의 GSSAPI 사용 여부에 영향을 주지 않습니다.

5. PAM·SSSD·LDAP 인증 지연 점검

비밀번호 입력 후 인증 결과가 나오기까지 오래 걸리거나, 로컬 계정도 간헐적으로 지연된다면 SSH 자체보다 PAM 또는 NSS가 연결하는 중앙 인증 서비스가 원인일 수 있습니다. SSSD, LDAP, NIS, winbind, Active Directory 서버가 중단되었거나 DNS 검색이 실패하면 각 인증 모듈의 타임아웃이 누적됩니다.

현재 인증 구성 확인

sudo authconfig --test
grep -Ev '^[[:space:]]*(#|$)' /etc/pam.d/sshd
grep -E '^(passwd|shadow|group|hosts):' /etc/nsswitch.conf
sudo systemctl status sssd.service nslcd.service winbind.service --no-pager -l

설치되지 않은 서비스에는 Unit ... could not be found가 표시될 수 있으며, 그 자체는 오류가 아닙니다. 실제로 사용 중인 인증 공급자와 관련된 서비스가 failed 또는 장시간 activating 상태인지 확인합니다.

계정 조회 시간 측정

NSS 계정 조회가 느리면 SSH 인증도 함께 느려질 수 있습니다. 실제 로그인 사용자명을 사용해 조회 시간을 측정합니다.

time getent passwd admin_user
time id admin_user

두 명령이 수 초 이상 걸리면 sshd_config보다 SSSD·LDAP·NIS·winbind 연결, 인증 서버 DNS, 방화벽 및 타임아웃 설정을 우선 점검합니다.

SSSD 로그 확인

sudo journalctl -u sssd.service --since "30 minutes ago" --no-pager
sudo ls -l /var/log/sssd
sudo tail -n 100 /var/log/sssd/sssd_pam.log 2>/dev/null

로그에서 DNS 조회 실패, LDAP·Kerberos 서버 연결 실패, 인증 공급자 오프라인 전환, TLS 인증서 오류 또는 반복되는 타임아웃을 확인합니다. 원격 인증 서버의 주소와 방화벽을 수정하거나, /etc/sssd/sssd.conf에 더 이상 존재하지 않는 공급자가 등록되어 있다면 조직의 인증 정책에 맞게 정리합니다.

6. 로그인 셸과 홈 디렉터리 지연 점검

인증 성공 메시지는 즉시 기록되지만 로그인 후 셸 프롬프트가 늦게 나타난다면 사용자의 셸 시작 파일, 네트워크 홈 디렉터리 또는 자동 마운트가 원인일 수 있습니다.

비대화형 명령과 대화형 로그인 비교

클라이언트에서 단순 명령 실행 시간을 측정합니다.

time ssh [email protected] /bin/true

이 명령은 빠르지만 일반 대화형 로그인이 느리다면 ~/.bash_profile, ~/.bashrc, /etc/profile, /etc/profile.d/의 명령을 점검합니다. 시작 파일에서 외부 API 호출, DNS 조회, 원격 명령, 느린 파일시스템 접근을 수행하면 로그인할 때마다 지연됩니다.

grep -nE '(curl|wget|ssh|scp|hostname|nslookup|dig|mount)' \
  /home/admin_user/.bash_profile \
  /home/admin_user/.bashrc \
  /etc/profile 2>/dev/null

sudo find /etc/profile.d -maxdepth 1 -type f -name '*.sh' -print

검색 결과가 있다고 해서 모두 오류는 아닙니다. 실제로 로그인 때 실행되는 코드인지 확인하고, 느린 네트워크 작업은 로그인 경로에서 제거하거나 타임아웃을 지정합니다.

NFS·CIFS·autofs 홈 디렉터리 확인

findmnt -T /home/admin_user
mount | grep -E ' type (nfs|nfs4|cifs|fuse)'
sudo systemctl status autofs.service --no-pager -l

홈 디렉터리가 NFS나 CIFS에 있고 저장소 서버가 응답하지 않으면 공개 키 파일 확인, 홈 디렉터리 진입, 셸 시작 파일 읽기 단계가 모두 지연될 수 있습니다. 네트워크 스토리지의 연결 상태와 마운트 옵션을 복구하고, 사용하지 않는 자동 마운트 정의를 정리합니다.

디스크와 inode 확인

df -h
df -i
sudo du -sh /var/log /tmp 2>/dev/null

루트 파일시스템이나 /var, /home의 공간 또는 inode가 소진되면 로그인 기록, 임시 파일, 세션 파일 생성이 늦어지거나 실패할 수 있습니다. 용량 부족이 확인되면 불필요한 로그와 임시 파일의 원인을 확인한 뒤 안전하게 정리합니다.

7. 서버 부하와 네트워크 문제 확인

SSH 상세 로그가 TCP 연결 또는 키 교환 초반에서 오래 멈춘다면 서버 자원과 네트워크 상태를 확인합니다. DNS·GSSAPI 설정을 바꿔도 네트워크 손실이나 CPU·메모리 부족은 해결되지 않습니다.

서버 자원 상태 확인

uptime
free -m
vmstat 1 5
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -n 15
sudo ss -ant state syn-recv | grep ':22 '

로드 평균이 CPU 수에 비해 계속 높거나 스왑 사용과 I/O 대기가 크면 자원 부족 원인을 먼저 해결합니다. SYN-RECV 연결이 비정상적으로 많다면 스캔·공격, 방화벽 또는 연결 대기열 문제도 확인해야 합니다.

클라이언트에서 네트워크 지연 확인

ping -c 10 203.0.113.10
ssh -vvv -o ConnectTimeout=10 [email protected]

왕복 지연이 비정상적으로 크거나 패킷 손실이 발생하면 서버와 클라이언트 사이의 라우팅, VPN, 보안 장비, 클라우드 보안 그룹 및 통신사 구간을 점검합니다. 특정 네트워크에서만 느리다면 다른 회선이나 관리망에서 비교 접속하는 것도 원인 분리에 도움이 됩니다.

8. 해결 여부 확인

설정 변경 후 SSH 데몬의 문법과 유효 설정을 다시 확인합니다.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep -E '^(usedns|gssapiauthentication) '
sudo systemctl is-active sshd.service
sudo systemctl status sshd.service --no-pager -l

현재 세션을 유지한 상태에서 별도의 터미널을 열고 접속 시간을 비교합니다.

time ssh -vv [email protected]

비밀번호 또는 키 인증 화면이 즉시 표시되고, 인증 후 셸 프롬프트도 지연 없이 나타나는지 확인합니다. 한 번의 결과만으로 판단하지 말고 같은 네트워크에서 3회 이상 접속해 지연이 재현되지 않는지 비교하는 것이 좋습니다.

서버 로그에 새로운 오류가 없는지도 확인합니다.

sudo tail -n 100 /var/log/secure
sudo journalctl -u sshd.service --since "10 minutes ago" --no-pager

9. 증상별 점검표

10. SSH 설정 원상복구 방법

설정 변경 후 인증 방식이 달라지거나 예상하지 못한 문제가 발생하면 작업 전에 생성한 백업 파일을 확인합니다.

sudo ls -lt /etc/ssh/sshd_config.bak-*

복원할 백업 파일명을 확인한 뒤 아래의 백업파일명을 실제 파일명으로 변경합니다.

sudo cp -a /etc/ssh/sshd_config.bak-백업파일명 /etc/ssh/sshd_config
sudo /usr/sbin/sshd -t
sudo systemctl reload sshd.service
sudo systemctl is-active sshd.service

문법 검사에서 오류가 발생하면 SSH 데몬을 다시 읽지 말고 오류가 표시된 행을 먼저 수정합니다. 복원 후 별도 터미널에서 정상 로그인되는지 확인한 다음 기존 세션을 종료합니다.

관련 지구 IDC 기술자료

• SSH 접속 프로그램 PuTTY 사용법

공식 참고자료

• CentOS Project — June 2024 News: CentOS Linux 7의 2024년 6월 30일 지원 종료와 이전 권고 확인. 조회일: 2026년 7월 21일.
• Red Hat — RHEL 7 System Administrator’s Guide: OpenSSH: openssh-server, sshd.service, /etc/ssh/sshd_config 및 서비스 관리 방식 확인. 조회일: 2026년 7월 21일.
• Red Hat Customer Portal — SSH reverse mapping checking 문제 해결 문서: PTR 레코드, /etc/hosts, UseDNS no, GSSAPIAuthentication no를 이용한 진단 방향 확인. 조회일: 2026년 7월 21일.
• OpenBSD Project / OpenSSH — sshd_config(5): SSH 서버 설정 지시문과 설정 파일 처리 방식 확인. 조회일: 2026년 7월 21일.
• OpenBSD Project / OpenSSH — sshd(8): -t 문법 검사와 -T 유효 설정 출력 기능 확인. 조회일: 2026년 7월 21일.
• Red Hat — RHEL 7 System-Level Authentication Guide: SSSD: 중앙 인증 공급자와 오프라인 인증, SSSD 구성 및 로그 점검 방향 확인. 조회일: 2026년 7월 21일.

자주 묻는 질문

UseDNS no와 GSSAPIAuthentication no를 모두 설정해야 하나요?

반드시 둘 다 변경할 필요는 없습니다. ssh -vvv, getent 조회 시간, GSSAPI 비활성화 비교 테스트로 원인을 확인한 뒤 필요한 항목만 변경하는 것이 좋습니다.

sshd를 reload하면 현재 SSH 연결이 끊어지나요?

일반적으로 이미 인증된 세션은 유지되고 새 연결부터 변경된 설정이 적용됩니다. 그러나 잘못된 설정이나 별도 자동화 환경에서는 문제가 발생할 수 있으므로 현재 세션을 유지하고 새 터미널에서 재접속을 확인해야 합니다.

IP로 접속해도 DNS 때문에 느려질 수 있나요?

가능합니다. 클라이언트가 서버 IP를 직접 입력했더라도 서버는 접속한 클라이언트 IP에 대해 역방향 이름 조회를 수행할 수 있습니다. 클라이언트 IP의 PTR 레코드와 서버 DNS 응답 상태를 확인해야 합니다.

비밀번호가 틀렸을 때만 응답이 느린 것은 정상인가요?

OpenSSH와 PAM은 무차별 대입 공격을 어렵게 하기 위해 인증 실패 응답을 의도적으로 지연할 수 있습니다. 정상 계정의 성공 로그인도 느리다면 DNS, GSSAPI, PAM·SSSD 및 서버 부하를 별도로 점검해야 합니다.

CentOS 7을 계속 사용해도 되나요?

CentOS Linux 7은 2024년 6월 30일 공식 지원이 종료되었습니다. 단기적인 장애 해결은 가능하지만, 보안 업데이트와 최신 암호화 정책을 고려하면 지원되는 운영체제로 이전하는 것이 필요합니다.