SSH 접속 지연·Connection refused 오류 해결 — 5가지 필수 점검 사항 완전 정리

SSH가 안 된다 — 어디서부터 봐야 할까

리눅스 서버 관리에서 SSH 접속 문제만큼 긴장되는 상황도 없습니다. 특히 원격지에 있는 서버에서 Connection refused 오류가 뜨거나, 접속은 되는데 패스워드 입력 화면까지 수십 초가 걸리는 경우 막막하게 느껴질 수 있습니다. 하지만 SSH 접속 문제는 원인이 몇 가지로 압축됩니다. 아래 5가지 항목을 순서대로 점검하면 대부분의 문제를 빠르게 해결할 수 있습니다.

점검 1 — SSH 데몬(sshd) 서비스 상태 확인

가장 먼저 확인해야 할 것은 SSH 서비스 자체가 실행 중인지 여부입니다. 서비스가 죽어있으면 어떤 설정을 바꿔도 접속이 불가능합니다. 콘솔 또는 BMC(iLO/XCC) 접근이 가능하다면 서버에 직접 로그인해 확인합니다.

systemctl status sshd           # 서비스 상태 확인
systemctl start sshd            # 서비스 시작
systemctl enable sshd           # 부팅 시 자동 시작 등록

상태가 failed 또는 inactive라면 서비스를 시작하고, 왜 죽었는지 로그를 확인합니다.

journalctl -u sshd -n 50        # 최근 50줄 sshd 로그 확인
journalctl -u sshd --since "1 hour ago"  # 최근 1시간 로그

자주 보이는 오류 메시지와 원인은 다음과 같습니다.

• error: Could not load host key: SSH 호스트 키 파일 손상 또는 없음 → ssh-keygen -A로 재생성
• Address already in use: 22번 포트를 다른 프로세스가 점유 → ss -tlnp | grep 22로 확인
• Permission denied on /etc/ssh/sshd_config: 설정 파일 권한 문제 → chmod 600 /etc/ssh/sshd_config

점검 2 — 포트 및 방화벽 설정 확인

sshd는 실행 중인데 외부에서 접속이 안 된다면 방화벽이 SSH 포트를 차단하고 있을 가능성이 높습니다. 또한 기본 22번 포트가 아닌 다른 포트로 변경된 경우도 있습니다.

sshd 리스닝 포트 확인

ss -tlnp | grep sshd             # sshd가 어느 포트에서 리스닝 중인지 확인
grep -i "^Port" /etc/ssh/sshd_config  # 설정 파일에서 포트 확인

방화벽 규칙 확인 및 허용

# firewalld 사용 환경 (RHEL/CentOS/Rocky)
firewall-cmd --list-all
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload

# ufw 사용 환경 (Ubuntu/Debian)
ufw status
ufw allow 22/tcp
ufw reload

# iptables 직접 사용 환경
iptables -L -n | grep 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

클라우드 환경(AWS, Azure, GCP)이라면 OS 방화벽과 별도로 보안 그룹(Security Group) 또는 네트워크 ACL에서도 인바운드 22번 포트가 허용되어 있는지 반드시 확인해야 합니다. OS 방화벽은 열려있어도 클라우드 레이어에서 막혀있는 경우가 매우 흔합니다.

점검 3 — SSH 접속 지연 원인: DNS 역조회 문제

접속은 되는데 패스워드 입력 화면까지 10~30초 이상 지연된다면 거의 대부분 DNS 역조회(Reverse DNS Lookup) 문제입니다. sshd는 기본적으로 접속을 시도한 클라이언트 IP에 대해 역방향 DNS 조회를 수행하는데, 이 조회가 실패하거나 타임아웃되면 그만큼 접속이 지연됩니다.

vi /etc/ssh/sshd_config

아래 항목을 추가하거나 수정합니다.

UseDNS no
GSSAPIAuthentication no

systemctl restart sshd

UseDNS no는 역방향 DNS 조회를 비활성화하고, GSSAPIAuthentication no는 Kerberos 기반 인증 시도를 끄는 설정으로, 사내 Kerberos 환경이 아닌 경우 불필요한 대기 시간을 유발합니다. 두 설정 적용 후 재시작하면 접속 지연이 즉시 해소되는 경우가 대부분입니다.

점검 4 — TCP Wrapper 및 hosts.deny 설정 확인

최신 리눅스 배포판에서는 비중이 줄었지만, 오래된 시스템이나 보안 정책이 적용된 환경에서는 TCP Wrapper(/etc/hosts.allow, /etc/hosts.deny)가 SSH 접속을 차단하는 경우가 있습니다.

cat /etc/hosts.deny
cat /etc/hosts.allow

hosts.deny에 아래와 같은 설정이 있으면 SSH 접속이 전면 차단됩니다.

ALL : ALL              # 모든 서비스, 모든 IP 차단
sshd : ALL             # SSH만 전체 차단

특정 IP만 허용하려면 hosts.allow에 추가합니다.

# hosts.allow — 특정 대역만 SSH 허용
sshd : 192.168.1.0/255.255.255.0
sshd : 10.0.0.0/255.0.0.0

# 또는 전체 허용으로 임시 해제
sshd : ALL

TCP Wrapper는 hosts.allow가 hosts.deny보다 우선 적용된다는 점을 기억하세요. allow에 명시된 항목은 deny 설정에 관계없이 접속이 허용됩니다.

점검 5 — sshd_config 설정 오류 및 인증 문제

설정 파일을 수정한 뒤 sshd를 재시작했는데 접속이 안 된다면 설정 파일 문법 오류를 의심해야 합니다. sshd는 설정 오류가 있으면 재시작 자체가 실패하거나 조용히 이전 설정으로 유지되는 경우가 있습니다.

설정 파일 문법 검사

sshd -t                          # 설정 파일 문법 검사 (오류 시 메시지 출력)
sshd -T | grep -i "permitroot"   # 현재 적용된 설정값 확인

자주 확인해야 할 sshd_config 항목

PermitRootLogin no               # root 직접 로그인 차단 여부
PasswordAuthentication yes       # 패스워드 인증 허용 여부
AllowUsers user1 user2           # 특정 사용자만 SSH 허용 (미설정 시 전체 허용)
AllowGroups sshusers             # 특정 그룹만 SSH 허용
MaxAuthTries 3                   # 인증 시도 횟수 제한

AllowUsers 또는 AllowGroups 설정이 있는 경우, 해당 목록에 없는 계정은 패스워드가 맞아도 접속이 거부됩니다. 계정이 추가됐는데 접속이 안 된다면 이 항목을 먼저 확인하세요.

공개키 인증 실패 시 권한 점검

키 기반 인증을 사용하는데 접속이 거부된다면 파일 권한 문제일 가능성이 높습니다.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

sshd는 ~/.ssh나 authorized_keys의 권한이 너무 열려있으면 보안상 키 인증을 거부합니다. 권한이 700/600이어야 정상 동작합니다.

빠른 점검 순서 요약

• Connection refused: sshd 서비스 상태 → 방화벽/포트 → TCP Wrapper 순서로 점검
• 접속 지연 (타임아웃): UseDNS no, GSSAPIAuthentication no 설정 즉시 적용
• 패스워드 맞는데 거부: AllowUsers/AllowGroups, PasswordAuthentication 항목 확인
• 키 인증 실패: ~/.ssh 및 authorized_keys 권한(700/600) 확인
• 설정 변경 후 문제 발생: sshd -t로 문법 검사 후 재시작

마무리

SSH 접속 문제는 원인이 다양해 보이지만 서비스 → 포트/방화벽 → DNS → TCP Wrapper → 설정 파일 순서로 레이어를 좁혀가면 빠르게 해결됩니다. 특히 원격 서버의 sshd_config를 수정할 때는 반드시 기존 세션을 유지한 채로 새 세션 접속 테스트를 먼저 하고, 문제없을 때 기존 세션을 닫는 습관을 들이는 것이 중요합니다. 설정 실수로 모든 SSH 세션이 끊기면 BMC 콘솔 없이는 복구가 어려워집니다.