[AWS] EC2 인스턴스 접속을 위한 키 페어 생성

VPC 퍼블릭 네트워크 구성까지 마쳤다면, 다음 단계는 그 네트워크 위에 EC2 인스턴스를 올리고 접속하는 것이다.

EC2 인스턴스를 생성하기 전에 반드시 먼저 해두어야 하는 작업이 있는데, 바로 키 페어 생성이다.

1. 키 페어의 개념

키 페어(key pair)는 퍼블릭 키(public key)와 프라이빗 키(private key) 두 개로 구성되는 보안 자격 증명 집합이다.

EC2 인스턴스에 접속할 때 "접속하려는 사람이 정당한 소유자인지"를 증명하는 데 사용된다.

Linux 인스턴스에서는 이 키 페어로 SSH 접속을 인증하고, Windows 인스턴스에서는 관리자 암호를 복호화하는 데 프라이빗 키를 사용한다.

• 퍼블릭 키 : 인스턴스 쪽에 저장된다. 잠금장치에 해당하며, 공개되어도 무방하다. AWS가 인스턴스 안에 심어둔다.
• 프라이빗 키 : 사용자가 직접 보관한다(.pem 파일). 열쇠에 해당하며, 이 키를 가진 사람은 누구나 해당 인스턴스에 접속할 수 있다. 따라서 안전한 위치에 보관해야 한다.

프라이빗 키의 보관 책임은 전적으로 사용자에게 있다.

AWS는 프라이빗 키의 사본을 보관하지 않는다.

키 페어를 생성하는 그 순간 프라이빗 키가 딱 한 번 다운로드되며, 이후 AWS에서 다시 받을 방법은 없다.

아래 시퀀스를 보면 프라이빗 키가 사용자 쪽으로 단 한 번만 전달되고, 이후 인증 과정에서는 사용자가 보관한 프라이빗 키가 인스턴스의 퍼블릭 키와 대조되는 흐름을 확인할 수 있다.

 

2. 키페어 생성

1️⃣ 콘솔

1. EC2 서비스로 이동한다.
2. 왼쪽 메뉴 → 네트워크 및 보안 → 키 페어로 진입한다.
3. 우측 상단 키 페어 생성 버튼을 클릭한다.
4. 리전이 아시아태평양(서울)로 설정되어 있는지 확인한다.
5. 다음과 같이 설정한다.
   • 이름: securedeploy-key
   • 키 페어 유형: RSA
   • 프라이빗 키 파일 형식: .pem (OpenSSH / Linux·macOS용)
6. 키 페어 생성을 클릭하면 .pem 파일이 자동으로 다운로드된다.

2️⃣ CLI

aws ec2 create-key-pair \
  --key-name securedeploy-key \
  --query 'KeyMaterial' --output text \
  --region ap-northeast-2 > securedeploy-key.pem

 

--query 'KeyMaterial' --output text는 JSON 응답에서 개인키 본문만 추출하여 텍스트로 출력하라는 의미이다.

리다이렉션(>)으로 로컬 파일에 저장한다.

 

콘솔에서 생성하든 CLI에서 생성하든, 이 때 개인키를 받지 않으면 이후에는 받을 수 없다.

 

3. 안전한 위치에 보관하기

(CLI와 SSH를 모두 리눅스 VM에서 사용한다는 전제)

발급받은 키를 ~/.ssh/ 디렉터리로 옮긴다.

처음에는 권한이 664로 되어 있다.

mkdir -p ~/.ssh
mv securedeploy-key.pem ~/.ssh/
chmod 400 ~/.ssh/securedeploy-key.pem

 

chmod 400로 권한을 변경해서 소유자만 읽기 가능하도록 한다.

(SSH 클라이언트는 개인키 파일의 권한이 과도하게 열려 있으면 접속을 거부하고 다음과 같은 오류 메시지를 출력한다.)

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for 'securedeploy-key.pem' are too open.

 

0644는 소유자 외에도 그룹·기타 사용자가 읽을 수 있는 상태이므로, SSH가 이를 안전하지 않다고 판단하여 접속을 차단하는 것이다.

chmod 400으로 소유자 전용 읽기 모드로 변경하면 해결된다.

콘솔에서 다운로드한 경우에도, 리눅스 VM에서 SSH에 사용할 것이라면 파일을 VM으로 옮긴 뒤 동일하게 chmod 400을 적용해야 한다.

🔵 보관 원칙

• ~/.ssh/에 격리하면 프로젝트 디렉터리에서 실수로 git add되는 사고를 방지할 수 있다.
• 저장소 폴더 안에는 두지 않는 것이 좋다. 안전장치로 .gitignore에 *.pem을 추가하는 방법도 있다.

echo "*.pem" >> ~/aws-pentest-lab-hardened/.gitignore

• 클라우드 동기화 폴더(구글 드라이브, OneDrive, Dropbox)나 GitHub에는 절대 업로드하지 않는다.

4. AWS 등록 확인 (서버 쪽)

키페어가 AWS에 정상적으로 등록되었는지 확인한다.

1️⃣ 콘솔

EC2 → 네트워크 및 보안 → 키 페어 목록에서 securedeploy-key가 보이면 정상이다.

지문(Fingerprint), 키 페어 ID(key-xxxx), 생성 시각을 확인할 수 있다.

 

2️⃣ CLI

aws ec2 describe-key-pairs \
  --key-names securedeploy-key \
  --region ap-northeast-2

 

출력 예시:

{
    "KeyPairs": [
        {
            "KeyPairId": "key-0a1b2c3d4e5f6g7h8",
            "KeyFingerprint": "aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99",
            "KeyName": "securedeploy-key",
            "KeyType": "rsa",
            "CreateTime": "2025-07-06T12:00:00+00:00"
        }
    ]
}

 

KeyPairs 배열에 키 이름(securedeploy-key)이 포함되어 있으면 AWS에 정상 등록된 것이다.

 

4. 로컬 파일 확인 (VM 쪽)

개인키 파일이 잘 저장되었는지 확인한다.

ls -l ~/.ssh/securedeploy-key.pem
head -1 ~/.ssh/securedeploy-key.pem

5. 키페어가 없을 때의 문제

만약 인스턴스를 먼저 만들고 키 페어를 지정하지 않으면, 부팅 시 authorized_keys에 배치할 퍼블릭 키가 없는 상태로 인스턴스가 뜬다.

이 상태에서는 SSH 접속에 사용할 열쇠 자체가 인스턴스에 등록되어 있지 않다.

문제는 나중에 키를 주입하기가 어렵다는 것이다.

 

AWS가 프라이빗 키를 저장하지 않기 때문에, 인스턴스를 생성한 뒤 키가 없다는 것을 알아차려도 기존 인스턴스에 손쉽게 키를 끼워 넣을 수 없다.

이 경우 접속을 복구하려면 인스턴스의 루트 볼륨을 분리해 다른 인스턴스에 연결한 뒤 authorized_keys를 직접 수정하고 다시 붙이는 식의 별도 작업이 필요하다. 이런 복구 절차를 피하려면 키 페어를 먼저 준비해 두는 것이 좋다.

 

프라이빗 키를 분실한 경우도 마찬가지다.

AWS에는 사본이 없으므로 원본을 그대로 복구할 방법은 없다.

다만 위와 유사한 볼륨 조작 방식으로 새 퍼블릭 키를 심어 접속을 되살리는 우회 경로는 존재한다.

 

키 페어의 대안으로, SSH 키 없이 브라우저 기반 셸이나 AWS CLI로 접속하는 AWS Systems Manager Session Manager를 사용할 수도 있다.

다만 이 방식은 인스턴스에 SSM 에이전트와 적절한 IAM 역할이 구성되어 있어야 하므로, 기본적인 접속 수단으로는 키 페어를 준비해 두는 것이 더 간단하고 편리하다.

 

6. 다음 단계

키페어 준비가 완료되었으므로, 이후 작업은 다음 순서로 진행한다.

 

🔵 보안 그룹 확인

🔵 AMI 조회 → EC2 인스턴스 생성 → SSH 접속 → IntraPortal 배포