EC2에 연결할 수 없는 SSH 문제 해결 단계별 가이드

.AWS에 새로 입문한 일부 사용자는 SSH를 통해 Linux EC2 인스턴스에 연결할 때 문제가 발생할 수 있습니다. 걱정하지 마세요, 이 문서가 자주 발생하는 원인을 해결하는 데 도움을 드릴 것입니다!

SSH가 EC2에 연결할 수 없는 이유

SSH를 통해 EC2에 연결할 수 없는 일반적인 이유는 주로 두 가지로 나뉩니다: 연결 시간 초과 및 권한 오류입니다.

연결 시간 초과: 오류 메시지에는 일반적으로 "connect"와 같은 키워드가 포함되며, 예를 들어 "Connection Timed Out"이 있습니다. 이는 일반적으로 네트워크 설정 오류로 인해 발생하며, IP, 보안 그룹, ACL, 서브넷 라우팅 테이블 및 사용자의 네트워크 환경을 점검해야 합니다.

권한 오류: 오류 메시지에는 일반적으로 "permission" 또는 "key"와 같은 키워드가 포함되며, 예를 들어 "접근이 거부되었습니다(Pemission Denied)" 또는 등록되지 않았거나 존재하지 않는 키에 대한 경고가 나타납니다. 이는 일반적으로 키 또는 사용자 이름을 잘못 사용했기 때문입니다.

연결 시간 초과

문제 설명

Amazon EC2 Linux 인스턴스를 생성하고 시작했지만 SSH나 PuTTY 같은 도구를 사용하여 인스턴스에 연결할 수 없습니다. 인스턴스에 연결할 때 "Network error: Connection timed out" 또는 "[인스턴스]에 연결하는 중 오류 발생, 원인: -> Connection timed out: connect"와 같은 연결 시간 초과 오류가 발생합니다. 이 문제는 일반적으로 보안 그룹, 라우트 테이블, 네트워크 ACL과 같은 네트워크 구성 요소의 잘못된 설정으로 인해 발생합니다. 아래의 문제 해결 단계를 따라 네트워크 환경을 확인하십시오.

문제 해결

1. 보안 그룹 확인

EC2 인스턴스의 보안 그룹에서 SSH 프로토콜(기본 포트 22)의 인바운드 트래픽이 허용되도록 설정하십시오.

사무실 LAN에서 IP 주소가 고정되어 있지 않고 연결할 때마다 변경될 수 있습니다. 이 경우, 단일 IP 주소가 아닌 사무실 네트워크의 IP 범위를 소스로 설정하는 것이 좋습니다.

참고: 기본적으로 인스턴스는 핑(ping)도 불가능합니다. 이 인스턴스를 핑하려면 ICMP 프로토콜을 허용하는 규칙을 유사한 방법으로 추가해야 합니다.

• Amazon EC2 콘솔을 엽니다.

• 탐색 창에서 인스턴스를 선택하십시오.

• SSH를 통해 연결할 EC2 인스턴스를 찾습니다.

• 화면 하단의 설명 탭에서 연결할 EC2 인스턴스의 보안 그룹을 선택합니다.

• 화면 하단의 창에 있는 Inbound 탭에서 현재 공용 IP 주소에서 SSH 액세스를 허용하는 규칙이 설정되어 있는지 확인하십시오. 장치에서 사용하는 IP 주소가 목록에 없는 경우 Edit를 선택한 다음 Add rule을 선택하십시오.

• 출처에서 귀하의 현재 IP 주소를 선택하십시오. "0.0.0.0/0"은 모든 IP에 개방되어 있음을 의미합니다.

• 저장을 선택하십시오.

2. 서브넷이 공용 서브넷인지 확인

공용 서브넷은 인터넷 액세스를 허용하는 서브넷입니다. EC2가 개인 서브넷에 있는 경우 외부 인터넷에서 활성 연결할 수 없으며 SSH가 실패합니다.

• Amazon VPC 콘솔을 엽니다.

• 탐색 창에서 경로 테이블을 선택한 다음 목록에서 사용자의 VPC 경로 테이블을 선택합니다.

• 경로(Routes) 탭에서 인터넷 게이트웨이를 가리키는 기본 경로가 있는지 확인하십시오.

• 아니면, 네비게이션 창에서 인터넷 게이트웨이를 선택하고 인터넷 게이트웨이 ID를 복사하십시오. 인터넷 게이트웨이가 없는 경우 새로 생성하고 해당 VPC에 연결하십시오. 새 인터넷 게이트웨이 ID를 복사하십시오.

• 다시 Route Tables로 돌아가서, 그런 다음 Routes  탭을 선택하십시오.

• “0.0.0.0/0”가 인터넷 게이트웨이 ID를 가리키도록 라우트를 편집하고 생성하십시오.

• 라우트 테이블을 저장합니다.

3. 서브넷의 네트워크 액세스 제어 목록(ACL) 확인

ACL은 서브넷 수준의 방화벽입니다. 기본 네트워크 ACL은 모든 인바운드 및 아웃바운드 트래픽을 허용합니다. ACL에 변경 사항을 적용하지 않은 경우, 이 단계를 건너뛰세요.

• Amazon VPC 콘솔을 엽니다.

• 탐색 창에서 서브넷을 선택한 다음 귀하의 서브넷을 선택하십시오.

• 설명 탭에서 네트워크 ACL을 찾아 ID(acl-xxxxxxxx)를 선택하십시오.

• 네트워크 ACL을 선택하십시오. 인바운드 규칙의 경우, 귀하의 컴퓨터에서 오는 트래픽을 허용하는지 확인하십시오. 그렇지 않다면 귀하의 컴퓨터에서 오는 트래픽을 차단하는 규칙을 삭제하거나 수정하십시오. 아웃바운드 규칙의 경우, 귀하의 컴퓨터로 가는 트래픽을 허용하는지 확인하십시오. 그렇지 않다면 귀하의 컴퓨터로 가는 트래픽을 차단하는 규칙을 삭제하거나 수정하십시오.

4. IP 주소가 변경되었는지 확인

• 탐색 창에서 인스턴스를 선택합니다.

• SSH를 통해 연결할 EC2 인스턴스를 찾습니다.

• 화면 하단의 설명 탭에서 공용 IP가 사용 중인 IP 주소와 일치하는지 확인하십시오. IP 주소가 변경된 경우, 새 IP 주소를 사용하십시오.

5. AMI 확인

현재 퀵 스타트(Quick Start) 또는 마켓플레이스(Marketplace)에서 AMI를 사용하고 있는지 확인하십시오. 특정 AMI의 보안 상태를 확신할 수 없다면 커뮤니티 이미지 사용을 최대한 자제하십시오. 커뮤니티 이미지는 개인 사용자에 의해 제공되며, AWS는 이를 모니터링할 수 없습니다. 일부 커뮤니티 이미지에는 특별한 보안 관리 및 설정이 적용되어 있어 SSH 접근을 직접 차단할 수도 있습니다. 이런 경우, 현재 서버를 중지하고 공식 이미지나 마켓플레이스 이미지로 새 서버를 시작하시기 바랍니다.

6. 인스턴스 부하 확인

서버에 과부하가 발생하여 sshd 서비스가 제대로 작동하지 않고 새로운 SSH 요청을 수락하지 않을 수 있습니다. 이는 CloudWatch 메트릭을 확인하여 문제를 진단할 수 있습니다. 이 시점에서 가장 간단한 방법은 인스턴스를 재부팅하여 문제를 해결할 수 있는지 확인하는 것입니다. 만약 그렇지 않다면 System Manager의 Session Manager 도구를 사용하여 세션을 열고 불필요한 리소스를 종료하는 명령어를 실행하십시오.

7. 기타 사유

위의 모든 단계를 확인했음에도 문제가 없다면, 다음 원인을 확인하십시오:

• 포트 22가 차단됨: 사무실이나 호텔 공공 Wi-Fi 지역에 있다면, 공공 네트워크에서 포트 22를 차단했는지 확인하기 위해 다른 네트워크를 사용해 보세요.

• 컴퓨터의 방화벽에서 포트 22를 차단하고 있는지 확인하십시오.

권한 문제

문제 설명

EC2를 생성 및 시작했지만 SSH를 통해 인스턴스에 연결할 수 없으며, "[디렉터리]에 호스트 키가 없음", "권한 거부됨 (공개 키)", 또는 "인증 실패, 권한 거부됨"과 같은 오류 메시지가 발생할 수 있습니다. 이 문제는 일반적으로 키 또는 사용자 이름이 잘못되었기 때문입니다. 다음은 구체적인 문제 해결 방법입니다.

문제 해결

1. 키 air가 올바른지 확인하십시오

각 EC2 인스턴스는 시작할 때 키를 가지고 있습니다. 이 키는 EC2에 처음 로그인할 수 있는 유일한 방법이며, 인스턴스를 시작하기 전에만 다운로드할 수 있습니다. 먼저 인스턴스를 선택하고 설명 페이지에서 키 페어 이름을 확인하여 올바른 키를 사용하고 있는지 확인하십시오.

이 항목이 비어 있으면 인스턴스에 SSH로 연결할 수 없습니다. 인스턴스를 중지하고 새 인스턴스를 시작한 후 키를 다운로드하는 것을 잊지 마십시오.

2. 잘못된 사용자 이름

공식 이미지를 사용하는 경우, 올바른 사용자 이름은 다음과 같습니다:

AMI의 커뮤니티 버전인 경우 사용자 이름을 보장할 수 없습니다. AMI 생성자에게 문의하거나 공식 AMI로 전환하시기 바랍니다.

3. 키 형식 확인

일반적으로 SSH에 필요한 키는 “pem” 형식입니다. 윈도우 컴퓨터를 사용하고 PuTTY로 로그인하는 경우, “pem” 형식을 “ppk” 형식으로 변환해야 합니다.

4. 주요 권한 확인

오류가 발생하면 "bad permissions: ignore key: my_private_key.pem Permission denied (publickey)".

이 상황은 개인 키 파일 권한이 너무 높아 모든 사용자가 읽고 쓸 수 있기 때문에 발생합니다. SSH는 귀하의 키를 무시하게 됩니다. 개인 키 파일을 보호하기 위해서는 다음 명령어를 사용하여 키 권한을 변경해야 합니다:

chmod 400 my_private_key.pem

5. known_host 관련 오류

이러한 상황은 예를 들어, EIP 전환 시에 흔히 발생합니다. 키 A와 함께 머신 A에 할당되었던 EIP가 키 B와 함께 머신 B로 전환될 때, 이 IP에 대한 known_host 기록이 일치하지 않습니다.

해결 방법은 known_host 파일(Linux/mac 주소: ~/.ssh/known_host)을 열고 이 IP에 해당하는 기록을 삭제하는 것입니다.

보안 EC2 백업 솔루션 선택

Vinchin Backup & Recovery 는 AWS EC2 백업을 지원하여 사용자가 AWS 액세스 키 ID로 인스턴스를 추가하고 전체, 증분 또는 차등 백업을 설정할 수 있도록 합니다. 전체 인스턴스, 개별 볼륨 및 특정 파일 등 다양한 복구 옵션을 제공하며 다른 가상화 플랫폼으로 직접 복구할 수 있습니다. Amazon S3와 연동되어 안전한 아카이빙이 가능하며 VMware, Hyper-V, Proxmox 등의 플랫폼으로의 V2V 마이그레이션&nbsp기능도 지원합니다. 직관적인 인터페이스로 백업 관리 및 설정이 용이합니다.

Vinchin Backup & Recovery로 EC2 인스턴스를 백업하려면 다음 단계를 따르십시오:

1. 백업할 EC2 인스턴스 선택

2. 백업 대상 선택

3. 백업 전략 선택

4. 작업 검토하고 제출

Vinchin Backup & Recovery의 안전하고 자원 효율적인 백업 솔루션을 체험해 보세요. 지금 60일간의 무료 체험판 을 시작하거나, 맞춤형 계획을 원하시면 문의하기를 클릭하십시오.

결론

위 단계를 통해 잠재적 문제를 해결함으로써 문제를 신속하게 해결하고 인스턴스에 다시 액세스할 수 있습니다. 신뢰할 수 있는 IP 주소만 액세스를 허용하고 보안 그룹 및 네트워크 설정을 정기적으로 검토하는 등의 좋은 보안 습관을 항상 실천하는 것을 잊지 마세요.