SSH 접속 실패는 메시지가 비슷해 보여도 원인은 완전히 다를 수 있습니다. Permission denied는 인증 문제일 가능성이 크고, Connection timed out은 네트워크 경로 문제일 가능성이 큽니다. 둘을 같은 방식으로 해결하려고 하면 시간을 많이 잃습니다.

이 글은 개인 서버, OCI/AWS/GCP/Azure VPS, 홈서버에서 SSH가 안 될 때 확인할 순서를 정리합니다. 핵심은 무작정 설정을 바꾸지 않고, 내 컴퓨터 → 네트워크 → 서버 → 인증 순서로 범위를 좁히는 것입니다.

핵심 판단

  • Timeout은 보통 IP, 포트, 방화벽, 클라우드 보안그룹 문제입니다.
  • Permission denied는 사용자명, 키 파일, 공개키 등록, 서버 인증 설정 문제일 가능성이 큽니다.
  • Host key 경고는 서버 재설치일 수도 있지만 중간자 공격 가능성도 있어 원인을 확인해야 합니다.
  • 가장 먼저 실행할 명령은 ssh -vvv입니다. 추측보다 로그가 빠릅니다.

1단계: 에러 메시지부터 구분하기

메시지 주요 원인 먼저 볼 곳
Connection timed out 서버까지 TCP 연결이 안 됨 IP, 포트, 보안그룹, 방화벽
Connection refused 서버는 응답하지만 해당 포트에 SSH가 없음 sshd 실행 여부, 포트 설정
Permission denied (publickey) 키 인증 실패 사용자명, 개인키, authorized_keys
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED 서버 호스트 키 변경 서버 재설치 여부, known_hosts

2단계: 접속 대상이 맞는지 확인

가장 단순하지만 가장 자주 틀리는 부분입니다.

  • 서버 IP가 맞는가?
  • 공인 IP와 사설 IP를 혼동하지 않았는가?
  • SSH 포트가 22번이 맞는가?
  • 클라우드 인스턴스가 running 상태인가?
  • 접속해야 하는 사용자가 root, ubuntu, ec2-user, opc 중 무엇인가?

예를 들어 Ubuntu 이미지는 보통 ubuntu, Oracle Linux는 opc, Amazon Linux는 ec2-user를 사용합니다. 사용자명이 틀리면 키가 맞아도 접속이 실패합니다.

3단계: 포트가 열려 있는지 확인

Timeout이라면 인증보다 네트워크를 먼저 봐야 합니다.

nc -vz 서버_IP 22

또는 포트를 바꿨다면 해당 포트를 확인합니다.

nc -vz 서버_IP 2222

연결이 안 되면 다음을 확인합니다.

  • 클라우드 Security Group / Security List / NSG 인바운드 규칙
  • 서버 내부 UFW 또는 firewalld
  • 공유기 포트포워딩
  • 서버의 공인 IP 연결 여부
  • 회사·학교 네트워크에서 22번 포트가 막혀 있는지

4단계: ssh -vvv로 인증 흐름 보기

OpenSSH 클라이언트는 -v 옵션으로 디버그 로그를 늘릴 수 있습니다. 문제 상황에서는 다음처럼 실행합니다.

ssh -vvv -i ~/.ssh/id_ed25519 ubuntu@서버_IP

여기서 봐야 할 포인트는 다음입니다.

  • 내가 의도한 키 파일을 실제로 시도하는가?
  • 서버가 publickey 인증을 허용하는가?
  • 어느 단계에서 Offering public key 이후 거절되는가?
  • 너무 많은 키를 시도하다가 Too many authentication failures가 나는가?

키가 여러 개라면 IdentitiesOnly yes를 ~/.ssh/config에 넣어 의도한 키만 쓰게 하는 것도 도움이 됩니다.

5단계: 키 파일과 권한 확인

Permission denied (publickey)가 뜬다면 키와 권한을 확인합니다.

ls -l ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

서버에 접근할 수 있는 다른 경로가 있다면 서버 쪽도 확인합니다.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

authorized_keys에는 공개키 한 줄이 들어가야 합니다. 개인키 전체를 붙여넣었거나 줄바꿈이 깨졌다면 인증이 실패합니다.

6단계: 서버의 sshd 상태 확인

Connection refused라면 서버에서 SSH 데몬이 실행 중인지 봐야 합니다. 콘솔, VNC, 클라우드 serial console 등으로 들어갈 수 있다면 다음을 확인합니다.

sudo systemctl status ssh
sudo systemctl status sshd

배포판에 따라 서비스명이 ssh 또는 sshd일 수 있습니다. 설정을 바꿨다면 재시작 전 문법 검사도 해야 합니다.

sudo sshd -t

OpenSSH의 sshd 매뉴얼은 -t를 설정 파일과 키의 sanity check 용도로 설명합니다. 원격 서버에서 SSH 설정을 바꿀 때는 기존 세션을 닫지 말고, 새 터미널로 접속 테스트를 먼저 하는 습관이 안전합니다.

7단계: 로그 확인

서버 쪽 로그는 원인을 좁히는 데 가장 확실합니다.

sudo journalctl -u ssh -n 100 --no-pager
sudo journalctl -u sshd -n 100 --no-pager

Ubuntu 계열에서는 다음 파일도 볼 수 있습니다.

sudo tail -n 100 /var/log/auth.log

로그에서 Authentication refused: bad ownership or modes가 보이면 권한 문제입니다. Invalid user가 보이면 사용자명이 틀린 것입니다.

8단계: known_hosts 경고 처리

서버를 재설치했거나 같은 IP에 다른 서버를 붙이면 호스트 키가 바뀔 수 있습니다. 이때 다음 경고가 나옵니다.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

정말 내가 서버를 재설치한 것이 맞다면 기존 호스트 키 기록을 제거할 수 있습니다.

ssh-keygen -R 서버_IP

하지만 이유 없이 갑자기 이 경고가 떴다면 무시하면 안 됩니다. DNS, IP, 네트워크 경로, 클라우드 콘솔의 인스턴스 정보를 먼저 확인해야 합니다.

빠른 진단 순서

  1. ssh -vvv user@host로 실제 실패 지점을 본다.
  2. Timeout이면 IP·포트·클라우드 보안규칙·방화벽을 본다.
  3. Permission denied면 사용자명·개인키·authorized_keys·권한을 본다.
  4. Connection refused면 sshd 실행 여부와 포트 설정을 본다.
  5. Host key 경고는 서버 변경 여부를 확인한 뒤 처리한다.
  6. 설정 변경 전에는 현재 SSH 세션을 닫지 않는다.

출처와 검증

이 글은 OpenSSH 매뉴얼과 일반적인 Linux 서버 운영 흐름을 기준으로 SSH 접속 문제를 빠르게 좁히는 ActualStack 트러블슈팅 가이드입니다.