EC2 SSH 연결 시간 초과: 확인해야 할 보안 그룹(Security Group) 규칙

EC2 SSH 연결 시간 초과(Connection timeout)는 새 인스턴스를 시작할 때 가장 흔히 발생하는 장애물 중 하나입니다. 해결 방법은 거의 항상 보안 그룹(Security Group)의 인바운드 규칙이 누락되었거나 잘못 구성된 경우입니다.

요약 — 한눈에 보는 진단 단계

단계	확인할 사항	일반적인 해결 방법
1	보안 그룹(Security Group) 인바운드 규칙	사용자 IP로부터의 SSH (TCP 22) 추가
2	서브넷 라우팅 테이블(Route table)	0.0.0.0/0이 인터넷 게이트웨이(IGW)로 라우팅되는지 확인
3	네트워크 ACL(Network ACL) 규칙	인바운드 TCP 22 및 임시(ephemeral) 반환 포트 허용
4	인스턴스 퍼블릭 IP / 탄력적 IP(Elastic IP)	퍼블릭 IP가 할당되었는지 확인
5	키 페어(Key pair) 및 SSH 사용자 이름	올바른 프라이빗 키 및 AMI 전용 사용자 이름 사용

SSH 연결이 거부(Refused)되지 않고 시간 초과(Timeout)되는 이유

연결 거부(Connection refused) 오류는 TCP 핸드셰이크가 호스트에 도달했으나 대기 중인 서비스가 없음을 의미합니다. 반면 연결 시간 초과(Connection timed out) 오류는 패킷이 도달하지 못했거나 응답이 돌아오지 못했음을 의미합니다. EC2에서 이러한 무응답은 거의 항상 OS 수준의 문제가 아닌 네트워크 계층에서의 차단 때문입니다. 인스턴스 수준의 상태 저장(stateful) 방화벽인 보안 그룹(Security Group)이 가장 먼저 의심해야 할 빈번한 원인입니다.

blockquote> 비유: 보안 그룹을 인스턴스 문 앞의 경비원이라고 생각해 보세요. SSH(포트 22)가 게스트 목록에 없으면 패킷은 거부 알림도 받지 못한 채 밖에서 무한정 대기하게 됩니다. 오직 침묵만 흐를 뿐입니다.

단계 1 — 보안 그룹 인바운드 규칙 수정

보안 그룹은 암묵적 거부(implicit deny) 모델을 사용합니다. 즉, 명시적인 허용 규칙이 없는 한 모든 인바운드 트래픽은 차단됩니다. SSH가 작동하려면 소스 IP에서 포트 22로의 인바운드 TCP를 허용하는 규칙이 필요합니다.

최소 필수 인바운드 규칙:

유형(Type): SSH
프로토콜(Protocol): TCP
포트 범위(Port range): 22
소스(Source): 사용자의 퍼블릭 IP 주소 (예: 203.0.113.10/32)

소스로 0.0.0.0/0을 사용하면 작동은 하지만 포트 22가 인터넷 전체에 노출됩니다. 프로덕션 인스턴스의 경우, 알려진 IP 또는 배스천 호스트(bastion host)의 보안 그룹 ID로 제한하세요.

🔽 AWS CLI — 보안 그룹에 SSH 인바운드 규칙 추가

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 22 \
  --cidr 203.0.113.10/32 \
  --region us-east-1

규칙을 추가하면 보안 그룹의 변경 사항이 즉시 적용되며, 인스턴스를 재부팅할 필요가 없습니다.

단계 2 — 서브넷 라우팅 테이블 확인

인바운드 규칙이 올바르더라도 서브넷에 인터넷으로 통하는 경로가 없으면 SSH 연결이 시간 초과됩니다. 퍼블릭 서브넷은 0.0.0.0/0 트래픽을 인터넷 게이트웨이(IGW)로 보내는 라우팅 경로가 필요합니다.

VPC 콘솔에서 라우팅 테이블을 확인하세요. 인스턴스를 호스팅하는 서브넷의 VPC → 라우팅 테이블(Route Tables) → 라우팅(Routes)으로 이동합니다. 다음과 같은 라우팅 경로가 있어야 합니다.

대상(Destination): 0.0.0.0/0
타겟(Target): igw-xxxxxxxxxxxxxxxxx

타겟이 NAT 게이트웨이이거나 로컬(local)만 표시된다면 인스턴스가 프라이빗 서브넷에 있는 것입니다. 인터넷에서 프라이빗 서브넷 인스턴스로 직접 SSH 연결을 할 수는 없으며, 배스천 호스트나 AWS Systems Manager Session Manager를 사용해야 합니다.

단계 3 — 네트워크 ACL 확인

네트워크 ACL(Network ACL, 서브넷 수준의 상태 비저장 방화벽)은 트래픽이 인스턴스에 도달하기 전에 평가됩니다. 보안 그룹과 달리 ACL은 상태 비저장(stateless)이므로 인바운드 요청과 아웃바운드 응답을 모두 명시적으로 허용해야 합니다.

SSH에 필요한 ACL 규칙:

인바운드(Inbound): 소스 IP로부터의 TCP 포트 22 허용
아웃바운드(Outbound): 소스 IP로 돌아가는 임시 포트(ephemeral port) 범위의 TCP 허용 (정확한 범위는 클라이언트 OS에 따라 다르므로 최신 가이드는 AWS VPC 문서를 참조하세요)

기본 VPC는 모든 트래픽을 허용하는 기본 네트워크 ACL과 함께 제공됩니다. 사용자 지정 ACL은 모든 트래픽을 거부하는 규칙으로 시작하므로, 팀이 사용자 지정 VPC로 마이그레이션할 때 자주 혼란을 겪는 원인이 됩니다.

단계 4 — 퍼블릭 IP 할당 여부 확인

올바른 라우팅 테이블을 가진 퍼블릭 서브넷의 인스턴스라도 퍼블릭 IP가 없으면 연결할 수 없습니다. EC2 콘솔의 인스턴스 세부 정보에서 퍼블릭 IPv4 주소(Public IPv4 address)를 확인하세요.

해당 필드가 비어 있다면 다음 중 하나에 해당합니다.

시작 시 퍼블릭 IP 자동 할당이 비활성화됨 (서브넷 기본값 또는 명시적 설정)
연결된 탄력적 IP(Elastic IP)가 없음

인스턴스가 시작된 후에는 탄력적 IP를 사용하지 않고 실행 중인 인스턴스에 퍼블릭 IP를 추가할 수 없습니다. 탄력적 IP를 할당하고 EC2 콘솔 또는 CLI에서 인스턴스에 연결하세요.

단계 5 — 키 페어 및 SSH 사용자 이름

네트워크 액세스가 확인된 후, 프라이빗 키나 SSH 사용자 이름이 일치하지 않으면 인증 오류가 발생합니다. 하지만 이는 TCP 연결이 성공한 이후에만 발생합니다. 여전히 시간 초과가 발생한다면 이 단계가 원인이 아닙니다. 시간 초과는 해결되었지만 이제 권한 거부(permission denied) 오류가 표시된다면 다음 사항을 확인하세요.

프라이빗 키 파일: 시작 시 선택한 키 페어에 해당하는 .pem 파일이어야 합니다. 권한은 chmod 400이어야 합니다.
SSH 사용자 이름: AMI에 따라 다릅니다. 공식 AMI의 일반적인 기본값은 다음과 같습니다.
- Amazon Linux 2 / Amazon Linux 2023: ec2-user
- Ubuntu: ubuntu
- RHEL: ec2-user 또는 root (AMI 설명 확인)
- SUSE: ec2-user
- Debian: AMI에 따라 다름 — AMI 설명 또는 제공업체 문서를 확인하세요. 모든 Debian 이미지가 동일한 기본 사용자 이름을 사용하는 것은 아닙니다.

공식 AWS AMI 중 일부만 표준화되고 잘 문서화된 기본 사용자 이름을 가지고 있습니다. 마켓플레이스 또는 커뮤니티 AMI(많은 Debian 이미지 포함)의 경우, 사용자 이름은 AMI 게시자가 설정하므로 연결하기 전에 AMI 설명이나 게시자의 문서에서 확인해야 합니다.

전체 진단 흐름

graph LR A[SSH 시도] --> B{퍼블릭 IP 할당됨?} B -- 아니오 --> C[탄력적 IP 할당] B -- 예 --> D{IGW 라우팅 존재?} D -- 아니오 --> E[프라이빗 서브넷 - 배스천 또는 SSM 사용] D -- 예 --> F{네트워크 ACL 포트 22 허용?} F -- 아니오 --> G[ACL 인바운드 및 아웃바운드 규칙 추가] F -- 예 --> H{보안 그룹이 IP로부터의 TCP 22 허용?} H -- 아니오 --> I[보안 그룹 인바운드 규칙 추가] H -- 예 --> J[TCP 연결됨 - 인증 시작]

시작: 로컬 머신에서 SSH 시도.
퍼블릭 IP 확인: 퍼블릭 IP가 없으면 패킷이 갈 곳이 없습니다. 탄력적 IP를 할당하세요.
라우팅 테이블 확인: IGW 라우팅 경로가 없으면 서브넷이 프라이빗 상태입니다. 배스천 호스트나 Session Manager를 사용하세요.
네트워크 ACL 확인: ACL이 포트 22 또는 임시 반환 포트를 차단하는 경우, 명시적 허용 규칙을 추가합니다.
보안 그룹 확인: 사용자 IP로부터의 TCP 22를 허용하는 인바운드 규칙이 없으면 추가합니다. 가장 흔한 해결책입니다.
연결 수립: TCP 핸드셰이크가 성공하고 SSH 인증이 시작됩니다.

프로덕션 환경의 함정 — 내 IP는 바뀌지만, 규칙은 그대로

유동 IP를 사용하는 가정이나 사무실 환경에서 흔히 발생하는 함정입니다. your-ip/32로 범위를 지정한 SSH 규칙을 추가하여 정상 작동했으나, 다음 날 다시 시간 초과가 발생합니다. ISP(인터넷 서비스 제공업체)가 퍼블릭 IP를 변경했기 때문이며, 보안 그룹 규칙은 여전히 이전 IP를 가리키고 있습니다. 팀에서는 가끔 편의를 위해 소스를 0.0.0.0/0으로 영구적으로 넓히기도 하는데, 이는 편의성을 위해 실제 공격 표면(attack surface)을 노출하는 위험한 타협입니다.

올바른 접근 방식: 포트 22를 전혀 열지 않고 대화형 셸 액세스를 제공하는 AWS Systems Manager Session Manager를 사용하거나, 탄력적 IP가 있는 전용 배스천 호스트를 유지하고 해당 배스천 호스트의 보안 그룹을 SSH 소스로 참조하는 것입니다.

흔히 하는 실수 — 잘못된 보안 그룹 수정

EC2 인스턴스에는 여러 보안 그룹이 연결될 수 있습니다. 종종 한 그룹에 SSH 규칙을 추가하고 올바르게 설정되었는지 확인하지만, 실제 인스턴스는 포트 22 규칙이 없는 다른 보안 그룹을 사용하고 있을 수 있습니다. 규칙이 누락되었다고 결론 내리기 전에, EC2 → 인스턴스 → 보안(Security) 탭에서 해당 인스턴스에 어떤 보안 그룹이 연결되어 있는지 확인한 다음, 연결된 각 그룹의 인바운드 규칙을 검증하세요.

절충안 — SSH 제한 vs. 운영 편의성

SSH를 단일 /32 IP로 제한하는 것은 안전하지만, 유동 IP를 사용하거나 여러 엔지니어가 있는 팀에게는 운영상 번거로울 수 있습니다. 알아둘 만한 아키텍처적 절충안은 다음과 같습니다. AWS Systems Manager Session Manager는 IAM 인증을 사용하여 브라우저 기반 및 CLI 셸 액세스를 제공하므로, 인바운드 보안 그룹 규칙이 필요 없고 CloudTrail 및 S3로의 전체 세션 로깅을 지원합니다. 새로운 배포의 경우, 이는 SSM 에이전트 실행 및 적절한 IAM 인스턴스 프로파일 연결이 필요하다는 비용을 대가로 SSH 키 관리 및 포트 노출 문제를 완전히 해결해 줍니다.

마무리

대부분의 EC2 SSH 시간 초과 문제는 단계 1(보안 그룹의 TCP 22 인바운드 규칙 누락)에서 해결됩니다. 보안 그룹 → 라우팅 테이블 → 네트워크 ACL → 퍼블릭 IP → 키/사용자 이름 순서대로 5단계를 진행해 보세요. 장기적인 보안을 위해 직접 SSH 연결 대신 Session Manager를 도입하여 포트 22 노출을 완전히 제거하는 것을 고려해 보세요.

용어 사전

용어	정의
보안 그룹(Security Group)	인바운드 및 아웃바운드 트래픽을 제어하는 상태 저장(stateful) 방식의 인스턴스 수준 가상 방화벽입니다. 명시적으로 허용되지 않는 한 모든 인바운드 트래픽을 암묵적으로 거부합니다.
네트워크 ACL(Network ACL)	보안 그룹보다 먼저 평가되는 상태 비저장(stateless) 방식의 서브넷 수준 방화벽입니다. 요청과 응답 방향 모두에 대해 명시적인 허용 규칙이 필요합니다.
인터넷 게이트웨이(Internet Gateway, IGW)	VPC 내의 인스턴스와 인터넷 간의 통신을 가능하게 하는 수평 확장형 VPC 구성 요소입니다.
탄력적 IP(Elastic IP)	AWS 계정에 할당하고 EC2 인스턴스에 연결할 수 있는 정적 퍼블릭 IPv4 주소입니다.
Session Manager	개방된 인바운드 포트나 SSH 키 없이도 EC2 인스턴스에 안전하고 감사 가능한 셸 액세스를 제공하는 AWS Systems Manager의 기능입니다.

📄 EC2 SSH 연결 타임아웃 완전 해결 가이드: Security Group 인바운드 규칙부터 라우팅까지

이 블로그 검색

SW BBANG K