인스턴스에 저장된 퍼블릭 키가 변경되서 접속이 안될 때 EC2 Instance Connect API를 사용한 대응법

인스턴스에 저장된 퍼블릭 키가 변경되서 접속이 안될 때 EC2 Instance Connect API를 사용한 대응법

Clock Icon2024.06.24 06:07

안녕하세요. 임채정입니다.
이번 블로그에서는 EC2 Instance Connect API를 사용해서 SSH 접속해보는 방법을 정리했습니다.

아래 블로그에서 키페어를 통해 SSH로 접속할 때의 동작 방법에 대해 정리를 했었는데, 이 때 인스턴스 안에 있는 퍼블릭 키가 변경되었을 때 어떻게 되는지도 같이 테스트해봤습니다.
변경한 후에는 퍼블릭키를 통해 암호화를 복호화할 수 없었기 때문에 인스턴스에 접속이 불가능하게 됐습니다.
궁금하시면 아래 블로그를 참고하세요(번외3) ↓

물론 퍼블릭 키가 쉽게 변경되거나 하지는 않겠지만 혹시 변경되었을 때에는 새롭게 인스턴스를 생성해서 기존 인스턴스의 EBS를 할당하는 등의 대응법이 있습니다.
이번 블로그에서는 EC2 Instance Connect API를 사용해서 인스턴스를 변경하지 않고 기존의 키페어를 그대로 사용할 수는 대응법을 정리했습니다.

검증 환경

  • 인스턴스 이름: test-server
  • OS: Amazon Linux 2023
  • 인스턴스 유형: t2.micro (테스트)
  • 키페어: test-key
  • 세큐리티 그룹
    • 유형-SSH, port-22, 소스-내IP
  • 네트워크 설정: (생략)

인스턴스 안의 퍼블릭 키 변경 후 확인

인스턴스를 생성하면 설정한 키페어의 퍼블릭키가 인스턴스의 ~/.ssh/authorized_keys 파일 안에 저장됩니다.
이 퍼블릭 키은 유저가 인스턴스에 SSH 접속할때 반드시 필요한 것입니다.
어느날 이 파일이 변경되면 어떻게 될까 궁금해져서 ~/.ssh/authorized_keys 파일 안에 있는 퍼블릭 키를 변경해버렸습니다.
퍼블릭 키는 수정은 생각보다 쉽게 되네요.
vi 명령어를 실행하니 쉽게 변경할 수 있었습니다.

$ vi  ~/.ssh/authorized_keys

그 후에 인스턴스에서 나온 뒤 다시 접속하려고 했더니 접속이 안됩니다.
에러 내용을 확인해보니 권한이 거부되었다고 출력되었습니다.
이는 SSH 클라이언트가 인증에 실패했을 때 나오는 에러로 쉽게 말해 사용자 인증을 실패했다는 의미입니다.

> ssh -i .ssh/test-key.pem ec2-user@xx.xx.xx.xx
ec2-user@xx.xx.xx.xx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

인스턴스 자체를 중지한 후 다시 재기동해서 접속을 해보면 서버 인증을 되고 있지만 사용자 인증이 실패되고 있다는 걸 확인할 수 있습니다.
정확하게는 인스턴스의 authorized_keys 폴더에 저장되어 있는 퍼블릭 키은 사용자 인증 시에 사용되는 것이기 때문에 그 퍼블릭 키가 변경된게 원인이라는 걸 알수 있습니다.

ssh -i .ssh/test-key.pem ec2-user@5xx.xx.xx.xx
The authenticity of host '54.238.238.27 (54.238.238.27)' can't be established.
ED25519 key fingerprint is SHA256:3gHzEsSjwi/0EvlRlSOIQGBXa216NDOOwxhEi4cBEzI.
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:103: yy.yy.yy.yy
# 서버 인증이 되고 있다는 증거
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'xx.xx.xx.xx' (ED25519) to the list of known hosts.
ec2-user@xx.xx.xx.xx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

그럼 이 경우 이제 이 서버는 다시 사용할 수 없게 되는 걸까요?

EC2 Instance Connect API를 사용한 대응법

대응법은 AWS 설명서 페이지를 참고했습니다.

먼저 사용자가 가지고 있는 프라이빗키로 퍼블릭키를 얻겠습니다. (일부분은 x로 대체)

ssh-keygen -y -f ~/.ssh/test-key.pem

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBOuXE2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxlu3LbU0DcqoPQXsMYuoz6SuOcpnzp4/BRDoxEv2rcL8EMrTVdPmFYjm3HBQ/M4dMdLecB/

취득한 퍼블릭 키의 내용은 test-key.pub 파일에 저장합니다.
그리고 다음의 Instance Connect 명령어를 실행해서 인스턴스의 메타데이터에 퍼블릭 키를 일시적으로 저장합니다.

aws ec2-instance-connect send-ssh-public-key \
    --region [리전 ex.ap-northeast-1] \
    --availability-zone [AZ ex.ap-northeast-1a] \
    --instance-id [인스턴스ID] \
    --instance-os-user ec2-user \
    --ssh-public-key file://.ssh/test-key.pub

# 성공 결과
# usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
# {
#     "RequestId": "bf262e48-7749-4bd5-9edf-44d81bd39696",
#     "Success": true
# }
# (END)

명렁어를 실행했으니 실제로 서버에 접속을 해보면 다음과 같이 문제 없이 접속할 수 있습니다.

ssh -i .ssh/test-key.pem ec2-user@xx.xx.xx.xx
   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
Last login: Fri Jun  7 19:10:22 2024 from zz.zz.zz.zz

그럼 인스턴스 안에 저장되어 있는 퍼블릭 키도 변경이 되었는지 확인해보겠습니다.

cat  ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1y8EMrTVdPmFYjm3HBQ/ test-key

퍼블릭 키는 아까 변경된 잘못된 내용 그대로 입니다.
왜냐하면 EC2 Instance Connect API를 사용해서 접속할 때는 인스턴스에 저장된 퍼블릭키 자체를 변경하는게 아니라 인스턴스의 메타데이터에 60초동안 저장해두는 것이기 때문입니다.

그러면 명령어를 실행하고 60초가 넘으면 어떻게 되는지도 확인해보겠습니다.

위에서 접속했던 인스턴스에서 나가서 60초가 지나고 다시 접속해보겠습니다.
그러면 아래와 같이 다시 에러가 발생합니다.

> ssh -i .ssh/test-key.pem ec2-user@xx.xx.xx.xx
ec2-user@xx.xx.xx.xx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

그럼 이번에는 authorized_keys 파일의 퍼블릭 키 내용을 수정해보겠습니다.
위에서 실행한 Instance Connect 명령어를 다시 실행해서 인스턴스에 접속합니다.
그리고 퍼블릭 키가 저장된 authorized_keys 파일 내용을 수정합니다.

vi  ~/.ssh/authorized_keys
# 파일을 수정해서 위에서 취득한 올바른 퍼블릭 키로 변경하고 저장합니다.

# 제대로 수정되었는지 확인
cat  ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBOuXE2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxlu3LbU0DcqoPQXsMYuoz6SuOcpnzp4/BRDoxEv2rcL8EMrTVdPmFYjm3HBQ/M4dMdLecB/ test-key

퍼블릭 키를 올바른 내용으로 수정했으니 다시 접속해보겠습니다.
다음과 같이 문제 없이 접속 되었습니다.

ssh -i .ssh/test-key.pem ec2-user@xx.xx.xx.xx
   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
Last login: Sat Jun  8 05:34:16 2024 from zz.zz.zz.zz

이걸로 인스턴스나 키페어를 변경하지도 않고 다시 인스턴스를 사용할 수 있게 되었습니다.
만약 프라이빗 키를 분실했을 때에도 활용할 수 있을 것같습니다.
하지만 이 방법을 사용할 일 없게 키페어를 잘 관리하는게 중요한 것같습니다.

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.