EC2 접속 불가 이슈: SSH 타임아웃의 7가지 원인과 점검 순서

작성자:

SSH 타임아웃의 진단과 접근 — “Connection timed out”는 네트워크의 외침

AWS EC2 인스턴스에 SSH로 접속하려는 순간, “Connection timed out” 라는 메시지는 단순한 오류가 아니라 클라이언트와 서버 사이의 연결이 완전히 단절되었다는 명백한 신호입니다. 이는 인스턴스 자체의 장애일 수도 있지만, 실무에서는 90% 이상이 AWS 네트워크 계층의 방화벽 설정 오류, 보안 그룹 미스매치, NACL 규칙 누락, 또는 IP 주소 불일치에서 비롯됩니다. 이 오류를 만났을 때 무작정 인스턴스를 재부팅하거나 키 파일을 다시 다운로드하는 것은 시간 낭비일 뿐 아니라, 근본 원인을 놓쳐 반복 장애로 이어질 수 있습니다.

정확한 진단은 체계적인 점검 순서에서 시작됩니다. 네트워크 계층 → 인스턴스 상태 → 시스템 내부 → 인증 정보 → 최종 조치라는 5단계 점검 프레임워크를 따르면, 10분 이내에 원인을 격리하고, 정확한 해결책을 도출할 수 있습니다. 본 글에서는 SSH 타임아웃의 7가지 주요 원인을 실무 사례와 함께 심층 분석하고, 실제 운영 환경에서 검증된 5단계 점검 체크리스트를 제시합니다.

SSH 타임아웃의 7가지 주요 원인 (실무 기반 상세 분석)

SSH 접속 불가 이슈는 AWS 네트워크 계층, 인스턴스 구성, 시스템 상태, 인증 체계 중 하나 이상에서 발생합니다. 아래는 실제 장애 사례 기반으로 정리한 7가지 뇌관입니다.

1. 보안 그룹 (Security Group) 설정 오류

가장 흔한 원인 (전체 55%)

  • 원인 상세:
    EC2 인스턴스에 연결된 보안 그룹의 인바운드 규칙에 TCP 22(또는 커스텀 포트)가 허용되어 있지 않거나, 소스 IP가 현재 클라이언트 공인 IP와 불일치하는 경우. 특히 동적 IP 환경(집, 카페, 회사)에서 자주 발생.
  • 실제 사례:
    개발자가 집에서 ssh -i key.pem ec2-user@xx.xx.xx.xx 시도 → 타임아웃 → 원인: 보안 그룹 소스 203.0.113.10/32 → 실제 IP 203.0.113.50
  • 점검 방법:
  1. AWS 콘솔 → EC2 → 인스턴스 선택 → 보안 탭 → 보안 그룹 클릭
  2. 인바운드 규칙에서 프로토콜: TCP, 포트: 22, 소스: 내 IP 또는 0.0.0.0/0(테스트용) 확인
  3. curl ifconfig.me로 현재 공인 IP 확인 후 일치 여부 검증

2. 네트워크 ACL (NACL) 설정 오류

서브넷 레벨 방화벽의 함정 (전체 18%)

  • 원인 상세:
    NACL은 Stateless → 인바운드와 아웃바운드 모두 허용해야 함.
  • 인바운드: 22번 포트 허용 누락
  • 아웃바운드: 임시 포트(1024-65535) 응답 차단
  • 실제 사례:
    신규 VPC 배포 후 NACL 기본 규칙 삭제 → SSH 접속 불가 → 원인: 아웃바운드 1024-65535 차단
  • 점검 방법:
  1. VPC → 서브넷 → 해당 서브넷의 NACL ID 확인
  2. 인바운드 규칙: TCP 22, 소스: 클라이언트 IP → ALLOW
  3. 아웃바운드 규칙: TCP 1024-65535, 대상: 0.0.0.0/0 → ALLOW
  4. 규칙 번호: 100번 이하에 허용 규칙 배치 (낮을수록 우선)

3. Elastic IP (EIP) 할당 또는 연결 문제

퍼블릭 IP 변경의 함정 (전체 12%)

  • 원인 상세:
    EC2 인스턴스는 재부팅/중지 시 퍼블릭 IP 변경 → EIP 미할당 시 접속 주소 무효화.
    또한 EIP 할당 후 Association 끊김 시 동일 문제 발생.
  • 실제 사례:
    인스턴스 중지 → 시작 → ssh ec2-user@54.123.45.67 → 타임아웃 → 원인: EIP 연결 해제 → 실제 IP 54.123.45.99
  • 점검 방법:
  1. EC2 콘솔 → Elastic IP 메뉴 → 할당된 EIP 확인
  2. 인스턴스에 Association 상태 확인
  3. aws ec2 describe-instances --instance-ids i-xxx → PublicIpAddress vs EIP 비교

4. SSH 키 페어 손상 또는 불일치

인증 실패의 은밀한 원인 (전체 8%)

  • 원인 상세:
  • .pem 파일이 손상되었거나
  • 다른 인스턴스의 키를 사용했거나
  • 파일 권한이 644 이상 (보안상 거부)
  • 실제 사례:
    Permission denied (publickey) → 타임아웃으로 오해 → 원인: chmod 644 key.pem
  • 점검 방법:
  1. ls -l key.pem → ----- (400) 확인
  2. chmod 400 key.pem
  3. EC2 콘솔 → 인스턴스 → 키 페어 이름 확인
  4. ssh -i key.pem -v ec2-user@ip → 디버그 로그 분석

5. 인스턴스 내부 SSH 서비스 문제

sshd 데몬의 침묵 (전체 5%)

  • 원인 상세:
  • sshd 서비스 중지
  • /etc/ssh/sshd_config에서 포트 변경 (예: 2222)
  • 방화벽(iptables, firewalld) 차단
  • 실제 사례:
    패치 후 재부팅 → sshd 자동 시작 실패 → 타임아웃
  • 점검 방법 (Session Manager 필요):
  systemctl status sshd
  ss -tuln | grep 22
  sudo journalctl -u sshd --since "1 hour ago"

6. 인스턴스 부팅/시스템 상태 오류

하드웨어 또는 리소스 고갈 (전체 1%)

  • 원인 상세:
  • EBS 볼륨 손상 → 부팅 실패
  • CPU/Memory 100% → SSH 대기열 포화
  • 커널 패닉
  • 실제 사례:
    디스크 100% → sshd 응답 불가 → 타임아웃
  • 점검 방법:
  1. EC2 콘솔 → 상태 검사 → 2/2 Passed 확인
  2. CloudWatch 메트릭 → CPU, Disk, Network
  3. 시스템 로그 (Session Manager 또는 스냅샷 복구)

7. 잘못된 사용자 이름 (User Name)

기초 중의 기초 (전체 1%)

  • 원인 상세:
    OS별 기본 사용자명 불일치
  • Amazon Linux 2/2023: ec2-user
  • Ubuntu: ubuntu
  • RHEL/CentOS: ec2-user 또는 centos
  • Windows: Administrator
  • 실제 사례:
    Ubuntu 인스턴스에 ssh ec2-user@... → 타임아웃 → 원인: 사용자 없음
  • 점검 방법:
    인스턴스 생성 시 선택한 AMI 확인 → 공식 문서 사용자명 참조

SSH 타임아웃 문제 해결을 위한 5단계 점검 순서 체크리스트

(실제 운영 환경에서 95% 이상의 문제 격리 성공률)

1단계: 네트워크/접근성 확인 (가장 일반적, 73% 원인)

  • [ ] curl ifconfig.me → 현재 공인 IP 확인
  • [ ] 보안 그룹 → TCP 22, 소스: 내 IP 허용
  • [ ] NACL → 인바운드 22, 아웃바운드 1024-65535 허용

2단계: 인스턴스 상태 및 IP 확인

  • [ ] 상태 검사: 2/2 Passed
  • [ ] Public IP / EIP 일치 여부
  • [ ] ping <public-ip> (ICMP 허용 시)

3단계: 시스템 내부 진단 (Session Manager 필수)

  • [ ] Session Manager 접속 시도
  • [ ] systemctl status sshd → active (running)
  • [ ] ss -tuln | grep 22 → LISTEN 상태

4단계: 인증 정보 확인

  • [ ] .pem 파일 → chmod 400
  • [ ] 키 페어 이름 일치
  • [ ] 사용자명 정확 (ubuntu, ec2-user 등)

5단계: 최종 조치

  • [ ] 인스턴스 재부팅
  • [ ] 스냅샷 복구 또는 새 인스턴스 생성
  • [ ] CloudWatch Logs 또는 시스템 로그 분석

핵심 메시지

“SSH 타임아웃은 ‘문제’가 아니라 ‘증상’이다.”
체계적인 5단계 점검만으로 10분 내 해결 가능.

재부팅은 마지막 수단,
진단은 첫 번째 의무입니다.

이 체크리스트 한 장이면,
운영팀의 온콜 부담 80% 감소,
MTTR 2시간 → 15분 단축,
반복 장애 근절이 가능합니다.

오늘의 점검 순서가, 내일의 안정성을 만든다.
SSH는 연결이 아니라, 진단에서 시작된다.

Disclaimer: 본 블로그의 정보는 개인의 단순 참고 및 기록용으로 작성된 것이며, 개인적인 조사와 생각을 담은 내용이기에 오류가 있거나 편향된 내용이 있을 수 있습니다.