Amazon EC2 Linux 인스턴스 연결 문제 해결

Amazon EC2 Linux 인스턴스 연결 문제 해결

다음 정보와 일반 오류를 통해 Linux 인스턴스 연결 문제를 해결할 수 있어요. 이 절에서 연결 문제의 일반 원인과 다양한 오류의 해결 방법을 살펴볼게요.

출처: 문서

본문

다음 정보와 일반 오류를 통해 Linux 인스턴스 연결 문제를 해결할 수 있어요.

연결 문제

연결 문제의 일반 원인

다음 작업을 정확히 수행했는지 확인하는 것부터 인스턴스 연결 문제 해결을 시작할 것을 권장해요.

인스턴스의 사용자 이름 확인

사용자 계정의 사용자 이름이나 인스턴스를 시작할 때 사용한 AMI의 기본 사용자 이름으로 인스턴스에 연결할 수 있어요.

  • 사용자 계정의 사용자 이름을 가져옵니다. 사용자 계정을 만드는 방법에 대한 자세한 내용은 Manage system users on your Amazon EC2 Linux instance를 참고하세요.
  • 인스턴스를 시작할 때 사용한 AMI의 기본 사용자 이름을 가져옵니다.
인스턴스 시작에 사용한 AMI 기본 사용자 이름
Amazon Linux ec2-user
CentOS centos 또는 ec2-user
Debian admin
Fedora fedora 또는 ec2-user
FreeBSD ec2-user
RHEL ec2-user 또는 root
SUSE ec2-user 또는 root
Ubuntu ubuntu
Oracle ec2-user
Bitnami bitnami
Rocky Linux rocky
기타 AMI 제공자에게 확인

보안 그룹 규칙이 트래픽을 허용하는지 확인

인스턴스와 연결된 보안 그룹이 내 IP 주소에서 들어오는 SSH 트래픽을 허용하는지 확인합니다. VPC의 기본 보안 그룹은 기본적으로 들어오는 SSH 트래픽을 허용하지 않아요. 시작 인스턴스 마법사가 만든 보안 그룹은 기본적으로 SSH 트래픽을 활성화해요. Linux 인스턴스에 대한 인바운드 SSH 트래픽 규칙을 추가하는 단계는 Rules to connect to instances from your computer를 참고하세요. 확인 단계는 인스턴스 연결 오류: Connection timed out을 참고하세요.

인스턴스가 준비되었는지 확인

인스턴스를 시작한 후 인스턴스가 연결 요청을 받아들일 준비가 될 때까지 몇 분이 걸릴 수 있어요. 인스턴스가 실행 중이고 상태 확인을 통과했는지 확인하세요.

  • https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
  • 탐색 창에서 Instances를 선택한 다음 인스턴스를 선택합니다.
  • 다음을 확인합니다.
    • Instance state 열에서 인스턴스가 running 상태인지 확인합니다.
    • Status check 열에서 인스턴스가 모든 상태 확인을 통과했는지 확인합니다.

연결에 필요한 모든 사전 요구 사항을 충족했는지 확인

연결에 필요한 모든 정보가 있는지 확인하세요. 자세한 내용은 Connect to your Linux instance using SSH를 참고하세요.

Linux 또는 macOS X에서 연결

로컬 컴퓨터 운영 체제가 Linux나 macOS X라면 Linux 인스턴스 연결을 위한 특정 사전 요구 사항을 확인하세요.

Windows에서 연결

로컬 컴퓨터 운영 체제가 Windows라면 Linux 인스턴스 연결을 위한 특정 사전 요구 사항을 확인하세요.

인스턴스가 관리형 인스턴스인지 확인

관리형 인스턴스에 대한 사용자 시작 연결은 허용되지 않아요. 인스턴스가 관리형인지 확인하려면 인스턴스의 Managed 필드를 찾으세요. 값이 true이면 관리형 인스턴스예요. 자세한 내용은 Amazon EC2 managed instances를 참고하세요.

인스턴스 연결 오류: Connection timed out

인스턴스에 연결하려고 할 때 Network error: Connection timed out 또는 Error connecting to [instance], reason: -> Connection timed out: connect 오류 메시지가 표시되면 다음을 시도해 보세요.

보안 그룹 규칙 확인.

로컬 컴퓨터의 공용 IPv4 주소에서 적절한 포트로 들어오는 인바운드 트래픽을 허용하는 보안 그룹 규칙이 필요해요.

  • https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
  • 탐색 창에서 Instances를 선택한 다음 인스턴스를 선택합니다.
  • 콘솔 페이지 하단의 Security 탭에서 Inbound rules 아래, 선택된 인스턴스에 적용되는 규칙 목록을 확인합니다. 로컬 컴퓨터에서 포트 22(SSH)로의 트래픽을 허용하는 규칙이 있는지 확인합니다. 보안 그룹에 로컬 컴퓨터에서 들어오는 인바운드 트래픽을 허용하는 규칙이 없다면 보안 그룹에 규칙을 추가하세요. 자세한 내용은 Rules to connect to instances from your computer를 참고하세요.
  • 인바운드 트래픽을 허용하는 규칙의 Source 필드를 확인합니다. 값이 단일 IP 주소이고 IP 주소가 고정되어 있지 않다면 컴퓨터를 다시 시작할 때마다 새 IP 주소가 할당될 거예요. 이로 인해 규칙이 내 컴퓨터의 IP 주소 트래픽을 포함하지 않게 됩니다. 컴퓨터가 기업 네트워크에 있거나 ISP(인터넷 서비스 공급자)를 통해 연결하거나 컴퓨터 IP 주소가 동적이라 다시 시작할 때마다 변한다면 IP 주소가 고정되어 있지 않을 수 있어요. 보안 그룹 규칙이 로컬 컴퓨터에서 들어오는 인바운드 트래픽을 허용하도록 보장하려면 Source에 단일 IP 주소를 지정하는 대신 클라이언트 컴퓨터가 사용하는 IP 주소 범위를 지정하세요. 보안 그룹 규칙에 대한 자세한 내용은 Amazon VPC User Guide의 Security group rules를 참고하세요.
서브넷의 라우팅 테이블 확인.

VPC 외부로 향하는 모든 트래픽을 VPC의 인터넷 게이트웨이로 보내는 라우트가 필요해요.

  • https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
  • 탐색 창에서 Instances를 선택한 다음 인스턴스를 선택합니다.
  • Networking 탭에서 VPC ID와 Subnet ID 값을 기록해 둡니다.
  • https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.
  • 탐색 창에서 Internet Gateways를 선택합니다. VPC에 인터넷 게이트웨이가 연결되어 있는지 확인합니다. 그렇지 않으면 Create internet gateway를 선택하고 인터넷 게이트웨이 이름을 입력한 다음 Create internet gateway를 선택합니다. 그런 다음 만든 인터넷 게이트웨이에 대해 Actions, Attach to VPC를 선택하고 내 VPC를 선택한 다음 Attach internet gateway를 선택해 VPC에 연결합니다.
  • 탐색 창에서 Subnets를 선택한 다음 서브넷을 선택합니다.
  • Route table 탭에서 대상이 0.0.0.0/0이고 대상이 VPC의 인터넷 게이트웨이인 라우트가 있는지 확인합니다. 인스턴스의 IPv6 주소로 연결한다면 모든 IPv6 트래픽(::/0)에 대해 인터넷 게이트웨이를 가리키는 라우트가 있는지 확인합니다. 그렇지 않으면 다음을 수행합니다.
    • 라우팅 테이블의 ID(rtb-*xxxxxxxx*)를 선택해 라우팅 테이블로 이동합니다.
    • Routes 탭에서 Edit routes를 선택합니다. Add route를 선택하고 대상으로 0.0.0.0/0, 대상으로 인터넷 게이트웨이를 사용합니다. IPv6의 경우 Add route를 선택하고 대상 ::/0, 대상으로 인터넷 게이트웨이를 사용합니다.
    • Save routes를 선택합니다.
서브넷의 네트워크 ACL 확인.

네트워크 ACL이 포트 22의 내 로컬 IP 주소에서 들어오는 인바운드 SSH 트래픽을 허용해야 해요. 또한 임시 포트(1024-65535)로의 아웃바운드 트래픽도 허용해야 해요.

  • https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.
  • 탐색 창에서 Subnets를 선택합니다.
  • 내 서브넷을 선택합니다.
  • Network ACL 탭에서 Inbound rules에 대해 규칙이 내 컴퓨터에서 필요한 포트로 들어오는 인바운드 트래픽을 허용하는지 확인합니다. 그렇지 않으면 트래픽을 차단하는 규칙을 삭제하거나 수정합니다.
  • Outbound rules에 대해 규칙이 임시 포트에서 내 컴퓨터로 나가는 아웃바운드 트래픽을 허용하는지 확인합니다. 그렇지 않으면 트래픽을 차단하는 규칙을 삭제하거나 수정합니다.
컴퓨터가 기업 네트워크에 있는 경우

네트워크 관리자에게 내부 방화벽이 포트 22에서 컴퓨터로 들어오고 나가는 트래픽을 허용하는지 문의하세요.

컴퓨터에 방화벽이 있다면 포트 22에서 컴퓨터로 들어오고 나가는 트래픽을 허용하는지 확인합니다.

인스턴스에 공용 IPv4 주소가 있는지 확인.

없다면 인스턴스에 Elastic IP 주소를 연결할 수 있어요. 자세한 내용은 Elastic IP addresses를 참고하세요.

인스턴스의 CPU 부하를 확인합니다. 서버가 과부하 상태일 수 있어요.

AWS는 Amazon CloudWatch 지표와 인스턴스 상태 같은 데이터를 자동으로 제공하며, 이를 사용해 인스턴스의 CPU 부하가 얼마인지 확인하고 필요하다면 부하 처리 방식을 조정할 수 있어요. 자세한 내용은 Monitor your instances using CloudWatch를 참고하세요.

IPv6 주소로 인스턴스에 연결하려면 다음을 확인하세요:

  • 내 서브넷이 인터넷 게이트웨이로 가는 IPv6 트래픽(::/0) 라우트가 있는 라우팅 테이블과 연결되어 있어야 해요.
  • 내 보안 그룹 규칙이 포트 22의 내 로컬 IPv6 주소에서 들어오는 인바운드 트래픽을 허용해야 해요.
  • 내 네트워크 ACL 규칙이 인바운드·아웃바운드 IPv6 트래픽을 허용해야 해요.
  • 이전 AMI에서 인스턴스를 시작했다면 DHCPv6용으로 구성되지 않았을 수 있어요(네트워크 인터페이스에서 IPv6 주소가 자동으로 인식되지 않음). 자세한 내용은 Amazon VPC User Guide의 Configure IPv6 on your instances를 참고하세요.
  • 내 로컬 컴퓨터에 IPv6 주소가 있고 IPv6를 사용하도록 구성되어 있어야 해요.

오류: unable to load key ... Expecting: ANY PRIVATE KEY

인스턴스에 연결하려고 할 때 unable to load key ... Expecting: ANY PRIVATE KEY 오류 메시지가 표시되면 개인 키가 저장된 파일이 잘못 구성된 것입니다. 개인 키 파일이 .pem으로 끝나더라도 여전히 잘못 구성되어 있을 수 있어요. 잘못 구성된 개인 키 파일의 가능한 원인은 인증서 누락이에요.

개인 키 파일이 잘못 구성된 경우, 다음 단계로 오류를 해결하세요
참고

또는 타사 도구로 새 키 페어를 만들 수 있어요. 자세한 내용은 Create a key pair using a third-party tool and import the public key to Amazon EC2를 참고하세요.

오류: User key not recognized by server

SSH로 인스턴스에 연결하는 경우
  • 연결 중에 삼중 상세 디버깅 정보를 얻으려면 ssh -vvv를 사용하세요.
ssh -vvv -i path/key-pair-name.pem [email protected]

다음 샘플 출력은 서버가 인식하지 못하는 키로 인스턴스에 연결하려고 할 때 볼 수 있는 것을 보여줘요.

open/ANT/myusername/.ssh/known_hosts).
debug2: bits set: 504/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: boguspem.pem ((nil))
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: boguspem.pem
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey: RSA 9c:4c:bc:0c:d0:5c:c7:92:6c:8e:9b:16:e4:43:d8:b2
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
PuTTY로 인스턴스에 연결하는 경우
  • 개인 키(.pem) 파일이 PuTTY가 인식하는 형식(.ppk)으로 변환되었는지 확인합니다. 개인 키 변환에 대한 자세한 내용은 Connect to your Linux instance using PuTTY를 참고하세요.
참고

PuTTYgen에서 개인 키 파일을 로드하고 Generate가 아니라 Save Private Key를 선택하세요.

  • 내 AMI에 적절한 사용자 이름으로 연결하고 있는지 확인합니다. PuTTY Configuration 창의 Host name 상자에 사용자 이름을 입력합니다.
인스턴스 시작에 사용한 AMI 기본 사용자 이름
Amazon Linux ec2-user
CentOS centos 또는 ec2-user
Debian admin
Fedora fedora 또는 ec2-user
FreeBSD ec2-user
RHEL ec2-user 또는 root
SUSE ec2-user 또는 root
Ubuntu ubuntu
Oracle ec2-user
Bitnami bitnami
Rocky Linux rocky
기타 AMI 제공자에게 확인

오류: Permission denied 또는 connection closed by [instance] port 22

SSH로 인스턴스에 연결할 때 Host key not found in [directory], Permission denied (publickey), Authentication failed, permission denied, 또는 Connection closed by [instance] port 22 오류 중 하나가 표시되면 내 AMI에 적절한 사용자 이름으로 연결하고 있는지 그리고 인스턴스에 적절한 개인 키(.pem) 파일을 지정했는지 확인합니다.

적절한 사용자 이름은 다음과 같습니다.

인스턴스 시작에 사용한 AMI 기본 사용자 이름
Amazon Linux ec2-user
CentOS centos 또는 ec2-user
Debian admin
Fedora fedora 또는 ec2-user
FreeBSD ec2-user
RHEL ec2-user 또는 root
SUSE ec2-user 또는 root
Ubuntu ubuntu
Oracle ec2-user
Bitnami bitnami
Rocky Linux rocky
기타 AMI 제공자에게 확인

예를 들어 SSH 클라이언트로 Amazon Linux 인스턴스에 연결하려면 다음 명령을 사용하세요.

ssh -i /path/key-pair-name.pem [email protected]

인스턴스를 시작할 때 선택한 키 페어에 해당하는 개인 키 파일을 사용하고 있는지 확인합니다.

  • https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
  • 탐색 창에서 Instances를 선택한 다음 인스턴스를 선택합니다.
  • Details 탭의 Instance details 아래에서 Key pair name 값을 확인합니다.
  • 인스턴스를 시작할 때 키 페어를 지정하지 않았다면 인스턴스를 종료하고 키 페어를 지정해 새 인스턴스를 시작할 수 있어요. 계속 사용해 온 인스턴스이지만 키 페어의 .pem 파일이 더 이상 없다면 키 페어를 새 것으로 교체할 수 있어요. 자세한 내용은 개인 키를 잃어버렸어요. 인스턴스에 어떻게 연결하나요?를 참고하세요.

자체 키 페어를 생성했다면 키 생성기가 RSA 키를 만들도록 설정되어 있는지 확인합니다. DSA 키는 허용되지 않아요.

Permission denied (publickey) 오류가 발생하고 위의 어느 것에도 해당되지 않는다면(예: 이전에는 연결할 수 있었음) 인스턴스의 홈 디렉터리 권한이 변경되었을 수 있어요. /home/instance-user-name/.ssh/authorized_keys의 권한은 소유자만으로 제한되어야 해요.

인스턴스의 권한을 확인하려면
  • 인스턴스를 중지하고 루트 볼륨을 분리합니다. 자세한 내용은 Stop and start Amazon EC2 instances를 참고하세요.
  • 현재 인스턴스와 같은 가용 영역에서 임시 인스턴스를 시작하고(현재 인스턴스에 사용한 AMI와 유사하거나 같은 AMI를 사용), 루트 볼륨을 임시 인스턴스에 연결합니다.
  • 임시 인스턴스에 연결하고 마운트 지점을 만든 다음 연결한 볼륨을 마운트합니다.
  • 임시 인스턴스에서 연결된 볼륨의 /home/instance-user-name/ 디렉터리 권한을 확인합니다. 필요하다면 권한을 다음과 같이 조정합니다.
[ec2-user ~]$ chmod 600 mount_point/home/instance-user-name/.ssh/authorized_keys

[ec2-user ~]$ chmod 700 mount_point/home/instance-user-name/.ssh

[ec2-user ~]$ chmod 700 mount_point/home/instance-user-name
  • 볼륨을 마운트 해제하고 임시 인스턴스에서 분리한 다음 원래 인스턴스에 다시 연결합니다. 루트 볼륨의 올바른 디바이스 이름(예: /dev/xvda)을 지정해야 합니다.
  • 인스턴스를 시작합니다. 임시 인스턴스가 더 이상 필요하지 않으면 종료할 수 있어요.

오류: Unprotected private key file

개인 키 파일은 다른 사용자의 읽기·쓰기 작업으로부터 보호되어야 해요. 다른 누군가가 내 개인 키를 읽거나 쓸 수 있다면 SSH는 키를 무시하고 다음 경고 메시지를 표시합니다.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '.ssh/my_private_key.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: .ssh/my_private_key.pem
Permission denied (publickey).

인스턴스에 로그인하려고 할 때 비슷한 메시지가 보이면 오류 메시지의 첫 줄을 확인해 인스턴스에 올바른 공개 키를 사용하고 있는지 확인하세요. 위 예시는 파일 권한이 0777인 개인 키 .ssh/my_private_key.pem을 사용하는데, 이는 누구나 이 파일을 읽거나 쓸 수 있게 합니다. 이 권한 수준은 매우 안전하지 않으므로 SSH는 이 키를 무시해요.

macOS나 Linux에서 연결한다면 다음 명령을 실행해 이 오류를 해결하고, 개인 키 파일 경로를 바꿔 넣으세요.

[ec2-user ~]$ chmod 0400 .ssh/my_private_key.pem

Windows에서 Linux 인스턴스에 연결한다면 로컬 컴퓨터에서 다음 단계를 수행합니다.

  • .pem 파일로 이동합니다.
  • .pem 파일의 컨텍스트(오른쪽 클릭) 메뉴를 열고 Properties를 선택합니다.
  • Security 탭을 선택합니다.
  • Advanced를 선택합니다.
  • 파일의 소유자인지 확인합니다. 아니라면 소유자를 내 사용자 이름으로 변경합니다.
  • Disable inheritance와 Remove all inherited permissions from this object를 선택합니다.
  • Add, Select a principal을 선택하고 사용자 이름을 입력한 다음 OK를 선택합니다.
  • Permission Entry 창에서 Read 권한을 부여하고 OK를 선택합니다.
  • 모든 설정이 저장되도록 Apply를 선택합니다.
  • OK를 선택해 Advanced Security Settings 창을 닫습니다.
  • OK를 선택해 Properties 창을 닫습니다.
  • 이제 Windows에서 SSH를 사용해 Linux 인스턴스에 연결할 수 있어야 해요.

Windows 명령 프롬프트에서 다음 명령을 실행합니다.

  • 명령 프롬프트에서 .pem 파일의 파일 경로 위치로 이동합니다.
  • 다음 명령을 실행해 명시적 권한을 리셋하고 제거합니다.
icacls.exe $path /reset
  • 다음 명령을 실행해 현재 사용자에게 Read 권한을 부여합니다.
icacls.exe $path /GRANT:R "$($env:USERNAME):(R)"
  • 다음 명령을 실행해 상속을 비활성화하고 상속된 권한을 제거합니다.
icacls.exe $path /inheritance:r
  • 이제 Windows에서 SSH를 사용해 Linux 인스턴스에 연결할 수 있어야 해요.

오류: Private key must begin with "-----BEGIN RSA PRIVATE KEY-----"

ssh-keygen 같은 타사 도구로 RSA 키 페어를 만들면 OpenSSH 키 형식으로 개인 키가 생성됩니다. 인스턴스에 연결할 때 OpenSSH 형식의 개인 키로 암호를 해독하면 Private key must begin with "-----BEGIN RSA PRIVATE KEY-----" and end with "-----END RSA PRIVATE KEY-----" 오류가 발생합니다.

이 오류를 해결하려면 개인 키가 PEM 형식이어야 해요. 다음 명령으로 PEM 형식의 개인 키를 만드세요:

ssh-keygen -m PEM

오류: Host key verification failed

이 오류는 인스턴스의 known_hosts 파일에 저장된 호스트 키와 클라이언트의 호스트 키가 일치하지 않을 때 발생합니다. 예를 들어 하나의 공용 IP 주소로 인스턴스에 연결한 다음 다른 공용 IP 주소로 다시 연결하려고 하면 불일치가 발생할 수 있어요. Elastic IP 주소를 추가하거나 제거하면 인스턴스의 공용 IP 주소가 변경되므로 이런 일이 발생할 수 있어요.

이 오류를 해결하려면 먼저 호스트 키나 인스턴스의 네트워크 구성에 예상된 변경이 있었는지 확인하세요. 인스턴스에 연결하기 전에 호스트 지문을 확인할 수도 있어요. 인스턴스에 연결한 후에는 known_hosts 파일에서 이전 호스트 키를 제거할 수 있어요. 지침은 인스턴스에서 사용 중인 Linux 배포판의 문서를 참고하세요.

오류: Server refused our key 또는 No supported authentication methods available

PuTTY로 인스턴스에 연결할 때 Error: Server refused our key 또는 Error: No supported authentication methods available 오류 중 하나가 표시되면 내 AMI에 적절한 사용자 이름으로 연결하고 있는지 확인합니다. PuTTY Configuration 창의 User name에 사용자 이름을 입력합니다.

적절한 사용자 이름은 다음과 같습니다.

인스턴스 시작에 사용한 AMI 기본 사용자 이름
Amazon Linux ec2-user
CentOS centos 또는 ec2-user
Debian admin
Fedora fedora 또는 ec2-user
FreeBSD ec2-user
RHEL ec2-user 또는 root
SUSE ec2-user 또는 root
Ubuntu ubuntu
Oracle ec2-user
Bitnami bitnami
Rocky Linux rocky
기타 AMI 제공자에게 확인

또한 다음을 확인해야 합니다.

  • 최신 버전의 PuTTY를 사용하고 있는지. 자세한 내용은 PuTTY 웹 페이지를 참고하세요.
  • 개인 키(.pem) 파일이 PuTTY가 인식하는 형식(.ppk)으로 올바르게 변환되었는지. 개인 키 변환에 대한 자세한 내용은 Connect to your Linux instance using PuTTY를 참고하세요.

인스턴스를 ping할 수 없음

ping 명령은 일종의 ICMP 트래픽이에요. 인스턴스에 ping을 보낼 수 없다면 인바운드 보안 그룹 규칙이 모든 소스, 또는 명령을 실행하는 컴퓨터나 인스턴스에서 Echo Request 메시지에 대한 ICMP 트래픽을 허용하는지 확인합니다.

인스턴스에서 ping 명령을 보낼 수 없다면 아웃바운드 보안 그룹 규칙이 모든 대상, 또는 ping하려는 호스트로 Echo Request 메시지에 대한 ICMP 트래픽을 허용하는지 확인합니다.

Ping 명령은 방화벽에 의해 차단되거나 네트워크 지연 시간이나 하드웨어 문제로 인해 시간 초과될 수도 있어요. 추가 문제 해결을 위해 로컬 네트워크 또는 시스템 관리자에게 문의하세요.

오류: Server unexpectedly closed network connection

PuTTY로 인스턴스에 연결할 때 "Server unexpectedly closed network connection" 오류가 발생하면 PuTTY Configuration의 Connection 페이지에서 keepalive를 활성화해 연결이 끊기지 않도록 했는지 확인합니다. 일부 서버는 지정된 기간 내에 데이터를 받지 못하면 클라이언트의 연결을 끊어요. Seconds between keepalives를 59초로 설정합니다.

keepalive를 활성화한 후에도 문제가 지속되면 PuTTY Configuration의 Connection 페이지에서 Nagle 알고리즘을 비활성화해 보세요.

오류: EC2 Instance Connect의 Host key validation failed

인스턴스 호스트 키를 순환(rotate)하면 새 호스트 키가 AWS 신뢰 호스트 키 데이터베이스에 자동으로 업로드되지 않아요. 이로 인해 EC2 Instance Connect 브라우저 기반 클라이언트로 인스턴스에 연결하려고 할 때 호스트 키 검증이 실패하고 인스턴스에 연결할 수 없게 됩니다.

이 오류를 해결하려면 인스턴스에서 eic_harvest_hostkeys 스크립트를 실행해야 하며, 이 스크립트는 새 호스트 키를 EC2 Instance Connect에 업로드합니다. 스크립트는 Amazon Linux 2 인스턴스에서는 /opt/aws/bin/에, Ubuntu 인스턴스에서는 /usr/share/ec2-instance-connect/에 있습니다.

Amazon Linux 2

Amazon Linux 2 인스턴스에서 host key validation failed 오류 해결
  • SSH로 인스턴스에 연결합니다. EC2 Instance Connect CLI를 사용하거나, 인스턴스를 시작할 때 할당된 SSH 키 페어와 인스턴스를 시작할 때 사용한 AMI의 기본 사용자 이름을 사용해 연결할 수 있어요. Amazon Linux 2의 기본 사용자 이름은 ec2-user예요. 예를 들어 인스턴스가 Amazon Linux 2로 시작되었고, 인스턴스의 공용 DNS 이름이 ec2-a-b-c-d.us-west-2.compute.amazonaws.com이며 키 페어가 my_ec2_private_key.pem이라면 다음 명령으로 인스턴스에 SSH로 접속하세요.
$ ssh -i my_ec2_private_key.pem [email protected]

인스턴스 연결에 대한 자세한 내용은 Connect to your Linux instance using an SSH client를 참고하세요.

  • 다음 폴더로 이동합니다.
[ec2-user ~]$ cd /opt/aws/bin/
  • 인스턴스에서 다음 명령을 실행합니다.
[ec2-user ~]$ ./eic_harvest_hostkeys

성공적인 호출은 출력이 없다는 점에 유의하세요.

이제 EC2 Instance Connect 브라우저 기반 클라이언트로 인스턴스에 연결할 수 있어요.

Ubuntu

Ubuntu 인스턴스에서 host key validation failed 오류 해결
  • SSH로 인스턴스에 연결합니다. EC2 Instance Connect CLI를 사용하거나, 인스턴스를 시작할 때 할당된 SSH 키 페어와 인스턴스를 시작할 때 사용한 AMI의 기본 사용자 이름을 사용해 연결할 수 있어요. Ubuntu의 기본 사용자 이름은 ubuntu예요. 예를 들어 인스턴스가 Ubuntu로 시작되었고, 인스턴스의 공용 DNS 이름이 ec2-a-b-c-d.us-west-2.compute.amazonaws.com이며 키 페어가 my_ec2_private_key.pem이라면 다음 명령으로 인스턴스에 SSH로 접속하세요.
$ ssh -i my_ec2_private_key.pem [email protected]

인스턴스 연결에 대한 자세한 내용은 Connect to your Linux instance using an SSH client를 참고하세요.

  • 다음 폴더로 이동합니다.
[ec2-user ~]$ cd /usr/share/ec2-instance-connect/
  • 인스턴스에서 다음 명령을 실행합니다.
[ec2-user ~]$ ./eic_harvest_hostkeys

성공적인 호출은 출력이 없다는 점에 유의하세요.

이제 EC2 Instance Connect 브라우저 기반 클라이언트로 인스턴스에 연결할 수 있어요.

EC2 Instance Connect로 Ubuntu 인스턴스에 연결할 수 없음

EC2 Instance Connect로 Ubuntu 인스턴스에 연결할 때 연결 시도 중 오류가 발생한다면 다음 정보를 사용해 문제를 해결해 보세요.

가능한 원인

인스턴스의 ec2-instance-connect 패키지가 최신 버전이 아님.

해결책

인스턴스의 ec2-instance-connect 패키지를 최신 버전으로 다음과 같이 업데이트합니다.

  • EC2 Instance Connect 이외의 방법으로 인스턴스에 연결합니다.
  • 인스턴스에서 다음 명령을 실행해 ec2-instance-connect 패키지를 최신 버전으로 업데이트합니다.
apt update && apt upgrade

개인 키를 잃어버렸어요. 인스턴스에 어떻게 연결하나요?

EBS 지원 인스턴스의 개인 키를 잃어버렸다면 인스턴스에 대한 접근을 되찾을 수 있어요. 인스턴스를 중지하고 루트 볼륨을 분리해 다른 인스턴스에 데이터 볼륨으로 연결하고, 새 공개 키로 authorized_keys 파일을 수정하고, 볼륨을 원래 인스턴스로 다시 옮기고, 인스턴스를 다시 시작해야 해요. 인스턴스 시작, 연결, 중지에 대한 자세한 내용은 Amazon EC2 instance state changes를 참고하세요.

이 절차는 EBS 루트 볼륨이 있는 인스턴스에서만 지원됩니다. 인스턴스에 인스턴스 스토어 루트 볼륨이 있다면 이 절차로 인스턴스에 대한 접근을 되찾을 수 없어요. 개인 키가 있어야 인스턴스에 연결할 수 있습니다. 인스턴스의 루트 볼륨 유형을 확인하려면 Amazon EC2 콘솔을 열고 Instances를 선택한 다음 인스턴스를 선택하고 Storage 탭을 선택한 뒤 Root device details 섹션에서 Root device type 값을 확인하세요.

값은 EBS 또는 INSTANCE-STORE입니다.

다음 단계 외에도 개인 키를 잃어버렸을 때 Linux 인스턴스에 연결하는 다른 방법이 있어요. 자세한 내용은 How can I connect to my Amazon EC2 instance if I lost my SSH key pair after its initial launch?를 참고하세요.

다른 키 페어로 EBS 지원 인스턴스에 연결하는 단계

1단계: 새 키 페어 만들기

Amazon EC2 콘솔이나 타사 도구를 사용해 새 키 페어를 만듭니다. 새 키 페어 이름을 잃어버린 개인 키와 정확히 같게 지정하려면 먼저 기존 키 페어를 삭제해야 해요. 새 키 페어 생성에 대한 자세한 내용은 Create a key pair using Amazon EC2 또는 Create a key pair using a third-party tool and import the public key to Amazon EC2를 참고하세요.

2단계: 원래 인스턴스와 그 루트 볼륨에 대한 정보 가져오기

이 절차를 완료하는 데 필요하므로 다음 정보를 기록해 둡니다.

원래 인스턴스에 대한 정보 가져오기
  • https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
  • 탐색 창에서 Instances를 선택한 다음 연결하려는 인스턴스를 선택합니다. (이 인스턴스를 원래 인스턴스라고 하겠습니다.)
  • Details 탭에서 인스턴스 ID와 AMI ID를 기록해 둡니다.
  • Networking 탭에서 가용 영역을 기록해 둡니다.
  • Storage 탭의 Root device name 아래에서 루트 볼륨의 디바이스 이름(예: /dev/xvda)을 기록해 둡니다. 그런 다음 Block devices 아래에서 이 디바이스 이름을 찾아 볼륨 ID(예: vol-0a1234b5678c910de)를 기록해 둡니다.

3단계: 원래 인스턴스 중지

Instance state, Stop instance를 선택합니다. 이 옵션이 비활성화되어 있다면 인스턴스가 이미 중지되었거나 루트 볼륨이 인스턴스 스토어 볼륨입니다.

경고

인스턴스를 중지하면 인스턴스 스토어 볼륨의 데이터가 손실됩니다. 이 데이터를 보존하려면 영구 스토리지에 백업하세요.

4단계: 임시 인스턴스 시작

임시 인스턴스 시작
  • 탐색 창에서 Instances를 선택한 다음 Launch instances를 선택합니다.
  • Name and tags 섹션의 Name에 Temporary를 입력합니다.
  • Application and OS Images 섹션에서 원래 인스턴스를 시작할 때 사용한 것과 같은 AMI를 선택합니다. 이 AMI를 사용할 수 없다면 중지된 인스턴스에서 사용할 수 있는 AMI를 만들 수 있어요. 자세한 내용은 Create an Amazon EBS-backed AMI를 참고하세요.
  • Instance type 섹션에서 기본 인스턴스 유형을 유지합니다.
  • Key pair 섹션의 Key pair name에서 사용할 기존 키 페어를 선택하거나 새로 만듭니다.
  • Network settings 섹션에서 Edit을 선택한 다음 Subnet에서 원래 인스턴스와 같은 가용 영역의 서브넷을 선택합니다.
  • Summary 패널에서 Launch를 선택합니다.

5단계: 원래 인스턴스에서 루트 볼륨 분리해 임시 인스턴스에 연결

  • 탐색 창에서 Volumes를 선택하고 원래 인스턴스의 루트 볼륨을 선택합니다(이전 단계에서 볼륨 ID를 기록해 두었어요). Actions, Detach volume을 선택한 다음 Detach를 선택합니다. 볼륨의 상태가 available이 될 때까지 기다립니다. (Refresh 아이콘을 선택해야 할 수도 있어요.)
  • 볼륨이 여전히 선택된 상태에서 Actions를 선택한 다음 Attach volume을 선택합니다. 임시 인스턴스의 인스턴스 ID를 선택하고 Device name 아래에 지정된 디바이스 이름(예: /dev/sdf)을 기록해 둔 다음 Attach volume을 선택합니다.
참고

AWS Marketplace AMI에서 원래 인스턴스를 시작했고 볼륨에 AWS Marketplace 코드가 포함되어 있다면 볼륨을 연결하기 전에 먼저 임시 인스턴스를 중지해야 해요.

6단계: 임시 인스턴스에 마운트된 원래 볼륨의 authorized_keys에 새 공개 키 추가

  • 임시 인스턴스에 연결합니다.
  • 임시 인스턴스에서 인스턴스에 연결한 볼륨을 마운트해 파일 시스템에 접근할 수 있게 합니다. 예를 들어 디바이스 이름이 /dev/sdf라면 다음 명령을 사용해 볼륨을 /mnt/tempvol로 마운트합니다.
참고

디바이스 이름은 인스턴스에서 다르게 보일 수 있어요. 예를 들어 /dev/sdf로 마운트된 디바이스는 인스턴스에서 /dev/xvdf로 표시될 수 있습니다. Red Hat의 일부 버전(또는 CentOS 같은 변형)은 끝 글자를 4자씩 늘려 /dev/sdf가 /dev/xvdk가 될 수도 있어요.

  • lsblk 명령으로 볼륨이 파티션되어 있는지 확인합니다.
[ec2-user ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk
└─xvda1 202:1 0 8G 0 part /
xvdf 202:80 0 101G 0 disk
└─xvdf1 202:81 0 101G 0 part
xvdg 202:96 0 30G 0 disk

앞선 예시에서 /dev/xvda와 /dev/xvdf는 파티션된 볼륨이고 /dev/xvdg는 파티션되지 않았습니다. 볼륨이 파티션되어 있다면 다음 단계에서 원시 디바이스(/dev/xvdf) 대신 파티션(/dev/xvdf1)을 마운트합니다.

  • 볼륨을 마운트할 임시 디렉터리를 만듭니다.
[ec2-user ~]$ sudo mkdir /mnt/tempvol
  • 앞서 식별한 볼륨 이름이나 디바이스 이름을 사용해 임시 마운트 지점에 볼륨(또는 파티션)을 마운트합니다. 필요한 명령은 운영 체제의 파일 시스템에 따라 달라져요. 디바이스 이름은 인스턴스에서 다르게 보일 수 있다는 점에 유의하세요. 자세한 내용은 6단계의 참고를 참고하세요.
    • Amazon Linux, Ubuntu, Debian
[ec2-user ~]$ sudo mount /dev/xvdf1 /mnt/tempvol
  • Amazon Linux 2, CentOS, SUSE Linux 12, RHEL 7.x
[ec2-user ~]$ sudo mount -o nouuid /dev/xvdf1 /mnt/tempvol
참고

파일 시스템이 손상되었다는 오류가 표시되면 다음 명령을 실행해 fsck 유틸리티로 파일 시스템을 확인하고 문제를 복구하세요.

[ec2-user ~]$ sudo fsck /dev/xvdf1
  • 임시 인스턴스에서 다음 명령을 사용해 마운트된 볼륨의 authorized_keys를 임시 인스턴스의 authorized_keys에서 가져온 새 공개 키로 업데이트합니다.
중요

다음 예시는 Amazon Linux 사용자 이름 ec2-user를 사용합니다. Ubuntu 인스턴스의 ubuntu 같은 다른 사용자 이름으로 바꿔야 할 수도 있어요.

[ec2-user ~]$ cp .ssh/authorized_keys /mnt/tempvol/home/ec2-user/.ssh/authorized_keys

이 복사가 성공했다면 다음 단계로 갈 수 있어요.

(선택 사항) 그렇지 않으면 /mnt/tempvol의 파일을 편집할 권한이 없다면 sudo로 파일을 업데이트한 다음 원래 인스턴스에 로그인할 수 있는지 권한을 확인해야 해요. 다음 명령을 사용해 파일의 권한을 확인합니다.

[ec2-user ~]$ sudo ls -l /mnt/tempvol/home/ec2-user/.ssh
total 4
-rw------- 1 222 500 398 Sep 13 22:54 authorized_keys

이 예시 출력에서 222는 사용자 ID이고 500은 그룹 ID입니다. 다음으로 sudo를 사용해 실패한 복사 명령을 다시 실행합니다.

[ec2-user ~]$ sudo cp .ssh/authorized_keys /mnt/tempvol/home/ec2-user/.ssh/authorized_keys

권한이 변경되었는지 확인하기 위해 다음 명령을 다시 실행합니다.

[ec2-user ~]$ sudo ls -l /mnt/tempvol/home/ec2-user/.ssh

사용자 ID와 그룹 ID가 변경되었다면 다음 명령으로 복원합니다.

[ec2-user ~]$ sudo chown 222:500 /mnt/tempvol/home/ec2-user/.ssh/authorized_keys

7단계: 임시 인스턴스에서 원래 볼륨 마운트 해제·분리하고 원래 인스턴스에 다시 연결

  • 임시 인스턴스에서 원래 인스턴스에 다시 연결할 수 있도록 연결한 볼륨을 마운트 해제합니다. 예를 들어 다음 명령으로 /mnt/tempvol의 볼륨을 마운트 해제합니다.
[ec2-user ~]$ sudo umount /mnt/tempvol
  • 임시 인스턴스에서 볼륨을 분리합니다(이전 단계에서 마운트 해제했어요): Amazon EC2 콘솔에서 탐색 창의 Volumes를 선택하고 원래 인스턴스의 루트 볼륨을 선택한 다음(이전 단계에서 볼륨 ID를 기록해 두었어요) Actions, Detach volume을 선택한 다음 Detach를 선택합니다. 볼륨의 상태가 available이 될 때까지 기다립니다. (Refresh 아이콘을 선택해야 할 수도 있어요.)
  • 볼륨을 원래 인스턴스에 다시 연결합니다: 볼륨이 여전히 선택된 상태에서 Actions, Attach volume을 선택합니다. 원래 인스턴스의 인스턴스 ID를 선택하고 2단계에서 원래 루트 볼륨 연결을 위해 기록해 둔 디바이스 이름(/dev/sda1 또는 /dev/xvda)을 지정한 다음 Attach volume을 선택합니다.
중요

원래 연결과 같은 디바이스 이름을 지정하지 않으면 원래 인스턴스를 시작할 수 없어요. Amazon EC2는 루트 볼륨이 sda1 또는 /dev/xvda에 있을 것으로 기대합니다.

8단계: 새 키 페어로 원래 인스턴스에 연결

원래 인스턴스를 선택하고 Instance state, Start instance를 선택합니다. 인스턴스가 running 상태에 들어간 후 새 키 페어의 개인 키 파일로 인스턴스에 연결할 수 있어요.

참고

새 키 페어의 이름과 해당 개인 키 파일이 원래 키 페어의 이름과 다르다면 인스턴스에 연결할 때 새 개인 키 파일의 이름을 지정해야 합니다.

9단계: 정리

(선택 사항) 임시 인스턴스를 더 이상 사용할 필요가 없으면 종료할 수 있어요. 임시 인스턴스를 선택하고 Instance state, Terminate (delete) instance를 선택합니다.

더 알아보기