[Linux] Create SSH-Keypair and add to Existing KeyStore – Tech Support Center 2.0 | Your AWS Partner

개요

Amazon EC2 Linux 인스턴스에 SSH로 접속할 때는 키 페어(key pair)를 사용합니다. 키 페어는 서로 짝을 이루는 퍼블릭 키(public key)와 프라이빗 키(private key)로 구성됩니다. 인스턴스를 시작(launch)할 때 키 페어를 지정하면, 인스턴스가 처음 부팅되는 순간 해당 키 페어의 퍼블릭 키가 기본 사용자(예: ec2-user, ubuntu, centos 등)의 ~/.ssh/authorized_keys 파일에 자동으로 등록됩니다. 이후 접속 시에는 이 퍼블릭 키와 짝을 이루는 프라이빗 키를 제시하여 본인임을 증명합니다.

이 매뉴얼은 이미 운영 중인 Linux 인스턴스에 접속 키를 하나 더 추가하는 방법을 다룹니다. 즉, 기본 사용자의 authorized_keys에 이미 등록된 기존 퍼블릭 키는 그대로 둔 채, 새 키 페어의 퍼블릭 키를 추가로 등록하여 두 개 이상의 키로 같은 서버에 접속할 수 있게 만드는 작업입니다. 조직 내 다른 담당자에게 별도의 키로 접근 권한을 부여하거나, 자동화 도구용 키를 추가하거나, 기존 키를 교체(추가 후 기존 키 삭제)하려는 경우에 유용합니다.

새 키 페어는 두 가지 방식으로 만들 수 있습니다.

Amazon EC2 콘솔에서 생성 — AWS가 퍼블릭 키를 보관하고, 프라이빗 키 파일(.pem 또는 .ppk)을 사용자가 다운로드합니다.
로컬에서 ssh-keygen 등 서드파티 도구로 직접 생성 — 프라이빗 키를 본인 PC에 안전하게 보관하고, 퍼블릭 키만 서버와(선택적으로) EC2로 올립니다. 프라이빗 키가 절대 네트워크를 오가지 않으므로 보안상 가장 권장되는 방식입니다.

Amazon EC2는 Linux 인스턴스에 대해 RSA 키와 ED25519 키를 모두 지원합니다(ED25519는 Linux 전용이며 Windows 인스턴스에서는 지원되지 않습니다).

키 관리 없이 접속만 하려는 경우에는 EC2 Instance Connect(퍼블릭 IP 기반 임시 키 주입)나 AWS Systems Manager Session Manager(SSH 키·인바운드 포트 불필요)와 같은 대안도 있습니다. 다만 이 매뉴얼은 기존 관행대로 authorized_keys에 정적 키를 추가하는 절차에 초점을 맞춥니다.

사전 준비

대상 인스턴스에 접속 가능한 기존 키: 새 키를 authorized_keys에 붙여 넣으려면 먼저 현재 유효한 키(또는 EC2 Instance Connect/Session Manager)로 인스턴스에 로그인할 수 있어야 합니다.
IAM 권한(콘솔에서 키 페어를 만들거나 임포트하는 경우): ec2:CreateKeyPair, ec2:ImportKeyPair, ec2:DescribeKeyPairs. 콘솔에서 키 페어 화면을 여는 데에도 ec2:DescribeKeyPairs가 필요합니다.
리전(Region): EC2 키 페어는 리전 단위 리소스입니다. 대상 인스턴스가 있는 리전(예: 서울 ap-northeast-2)에서 키 페어를 생성/임포트해야 합니다. 콘솔 오른쪽 위 리전 선택기가 올바른 리전인지 먼저 확인하십시오.
로컬 작업 환경: macOS/Linux에는 OpenSSH(ssh, ssh-keygen, scp)가 기본 포함되어 있습니다. Windows 10/11도 OpenSSH 클라이언트를 기본 제공하며(없으면 "설정 > 앱 > 선택적 기능"에서 추가), PuTTY를 쓰는 경우 .ppk 형식과 PuTTYgen을 사용합니다.
기본 사용자 이름 확인: AMI에 따라 다릅니다. Amazon Linux/RHEL/Oracle은 ec2-user, Ubuntu는 ubuntu, Debian은 admin, CentOS는 centos 또는 ec2-user입니다.
인스턴스의 퍼블릭 접속 정보: 퍼블릭 IPv4 주소 또는 퍼블릭 DNS 이름. 보안 그룹 인바운드 규칙에서 접속 출발지 IP에 대해 TCP 22(SSH)가 허용되어 있어야 합니다.

프라이빗 키는 비밀번호와 같습니다. 서버(특히 여러 사람이 공유하는 서버) 위에서 프라이빗 키를 생성해 두거나, 서버에 있는 프라이빗 키를 로컬로 내려받는 방식은 권장하지 않습니다. 프라이빗 키는 사용할 본인 PC에서 생성해 그 자리에 보관하고, 서버에는 퍼블릭 키만 올리는 것이 원칙입니다.

콘솔 작업 절차

아래 절차는 "새 키 페어 만들기 → 퍼블릭 키 확보 → 인스턴스의 authorized_keys에 추가 → 새 키로 접속 확인" 순서로 진행됩니다. [방법 A]는 EC2 콘솔에서 키 페어를 생성하는 방식, [방법 B]는 로컬 ssh-keygen으로 생성하는 방식입니다. 둘 중 하나만 선택해 1단계를 수행한 뒤, 3단계부터는 공통입니다.

[방법 A] EC2 콘솔에서 새 키 페어 생성하기
1. AWS Management Console 상단의 검색창에 EC2를 입력하고 EC2 서비스를 클릭해 EC2 대시보드로 이동합니다. 콘솔 주소는 https://console.aws.amazon.com/ec2/ 입니다.
2. 오른쪽 위 리전 선택기에서 대상 인스턴스가 있는 리전(예: 아시아 태평양(서울) ap-northeast-2)을 선택합니다. 리전이 다르면 만든 키 페어가 인스턴스와 같은 목록에 보이지 않습니다.
3. 왼쪽 탐색 창에서 Network & Security(네트워크 및 보안) 그룹 아래의 Key Pairs(키 페어)를 클릭합니다.
4. 오른쪽 위 Create key pair(키 페어 생성) 버튼을 클릭합니다.
5. Name(이름) 필드에 키 페어를 식별할 이름을 입력합니다(예: myserver-second-key). 최대 255자의 ASCII 문자를 쓸 수 있고, 앞뒤 공백은 불가합니다. 이 이름이 곧 AWS에 등록되는 키 페어의 이름이 됩니다.
  
  이 이름은 AWS가 퍼블릭 키를 관리하기 위한 식별자일 뿐, 서버의 authorized_keys에 들어가는 주석(뒤에 붙는 라벨)과는 별개입니다. 나중에 어떤 키인지 알아보기 쉽게 용도가 드러나는 이름을 권장합니다.
6. Key pair type(키 페어 유형)에서 RSA 또는 ED25519 중 하나를 선택합니다.
  - ED25519: 비교적 최신 알고리즘으로 키 길이가 짧으면서도 보안성이 높고 인증 속도가 빠릅니다. Linux 인스턴스에 접속하는 용도라면 특별한 호환성 제약이 없는 한 ED25519를 권장합니다. 단, Windows 인스턴스에서는 지원되지 않습니다.
  - RSA: 가장 널리 호환되는 방식입니다. 오래된 클라이언트/도구와의 호환이 필요하거나 Windows 인스턴스를 함께 다뤄야 한다면 RSA를 선택합니다.
7. Private key file format(프라이빗 키 파일 형식)에서 저장 형식을 선택합니다.
  - .pem: OpenSSH에서 사용하는 형식입니다. macOS/Linux 터미널이나 Windows OpenSSH의 ssh 명령으로 접속한다면 .pem을 선택합니다(권장).
  - .ppk: PuTTY에서 사용하는 형식입니다. Windows에서 PuTTY로 접속할 계획이라면 .ppk를 선택합니다.
8. (선택) Add tag(태그 추가)를 눌러 키/값 형태의 태그를 지정하면 소유자·용도·환경 등을 기록해 관리와 비용 추적에 도움이 됩니다. 필수는 아닙니다.
9. 아래쪽 Create key pair(키 페어 생성) 버튼을 클릭합니다. 그러면 프라이빗 키 파일(예: myserver-second-key.pem)이 브라우저를 통해 자동으로 다운로드됩니다.
  
  프라이빗 키 파일을 다운로드할 수 있는 기회는 이때 한 번뿐입니다. 다시 받을 수 없으므로 안전한 위치에 즉시 보관하십시오. 분실하면 이 키로는 접속할 수 없습니다.
10. macOS/Linux에서 접속할 예정이라면 다운로드한 프라이빗 키 파일의 권한을 소유자만 읽을 수 있도록 좁힙니다. 권한이 너무 개방적이면 SSH가 키 사용을 거부합니다.
```
chmod 400 myserver-second-key.pem
```
[방법 B] 로컬에서 ssh-keygen으로 새 키 페어 생성하기 (콘솔 대신 본인 PC에서 생성)

본인 PC의 터미널에서 다음 명령을 실행합니다. 프라이빗 키가 PC를 벗어나지 않아 가장 안전합니다.
```
# ED25519 키 생성(권장)
ssh-keygen -t ed25519 -f ~/.ssh/myserver-second-key -C "your-name@example.com"

# 또는 RSA 4096비트 키 생성(호환성이 필요할 때)
ssh-keygen -t rsa -b 4096 -f ~/.ssh/myserver-second-key -C "your-name@example.com"
```
주요 옵션의 의미는 다음과 같습니다.
- -t: 키 알고리즘 유형(ed25519 또는 rsa). 위 개요의 유형 설명과 동일한 기준으로 선택합니다.
- -b 4096: (RSA에만 해당) 키 길이(비트). 길수록 안전하지만 값이 커집니다. RSA는 최소 2048, 권장 4096입니다. ED25519는 길이가 고정이라 -b가 필요 없습니다.
- -f ~/.ssh/myserver-second-key: 생성될 파일 경로/이름. 이 경로에 프라이빗 키(myserver-second-key)와 퍼블릭 키(myserver-second-key.pub) 두 파일이 만들어집니다. -f를 지정하지 않으면 대화형으로 저장 위치를 물어보며 기본값은 ~/.ssh/id_rsa 또는 ~/.ssh/id_ed25519입니다.
- -C "...": 퍼블릭 키 끝에 붙는 주석(라벨). 보통 이메일이나 용도를 적어 "이 키가 누구/무엇의 것인지" 구분하는 데 씁니다. 인증 자체에는 영향이 없습니다.
- 실행 중 passphrase(암호문구)를 물어봅니다. 값을 넣으면 프라이빗 키 파일이 그 암호로 추가 암호화되어, 파일이 유출되어도 암호 없이는 사용할 수 없습니다(보안 강화, 권장). 무인 자동화용이라 매번 입력이 곤란하면 빈 값(엔터)으로 둘 수 있습니다.
서드파티 도구로 만든 키를 AWS에도 등록해 두면(선택 사항) 콘솔의 키 페어 목록에서 관리·조회할 수 있습니다. 아래 CLI 대안 절의 import-key-pair를 참고하십시오. 등록은 퍼블릭 키만 올리는 작업이며 접속 자체에는 필수가 아닙니다.

PEM 형식의 프라이빗 키가 꼭 필요한 도구를 쓴다면 ssh-keygen -m PEM ... 옵션으로 생성하십시오. 최신 OpenSSH의 기본 프라이빗 키 형식은 OpenSSH 전용 형식입니다.
새 키 페어의 퍼블릭 키 확보하기
- [방법 B]로 만든 경우: ~/.ssh/myserver-second-key.pub 파일 내용이 곧 퍼블릭 키입니다. 파일을 열어(cat ~/.ssh/myserver-second-key.pub) ssh-ed25519 AAAA... 또는 ssh-rsa AAAA...로 시작하는 한 줄 전체를 복사합니다.
- [방법 A]로 만들어 .pem만 가지고 있는 경우: 프라이빗 키에서 퍼블릭 키를 다음 명령으로 추출합니다.
```
ssh-keygen -y -f myserver-second-key.pem
```
  출력되는 ssh-rsa AAAA...(또는 ssh-ed25519 ...) 한 줄이 authorized_keys에 넣을 퍼블릭 키입니다. 옵션 -y는 "프라이빗 키에서 퍼블릭 키를 도출해 출력"하라는 의미이고, -f는 대상 프라이빗 키 파일 경로입니다.
기존 키로 인스턴스에 접속하기

본인 PC 터미널에서 현재 유효한(기존) 키로 대상 인스턴스에 로그인합니다.
```
ssh -i /path/to/existing-key.pem ec2-user@<퍼블릭_IP_또는_퍼블릭_DNS>
```
- -i: 인증에 사용할 프라이빗 키 파일 경로.
- ec2-user: AMI에 맞는 기본 사용자 이름으로 바꿉니다(Ubuntu면 ubuntu 등).
- 주소 부분은 EC2 콘솔의 Instances(인스턴스) 화면에서 대상 인스턴스를 선택하면 하단 Details(세부 정보) 탭의 Public IPv4 address 또는 Public IPv4 DNS에서 확인할 수 있습니다.
인스턴스의 authorized_keys에 새 퍼블릭 키 추가하기

기본 사용자에게 키를 하나 더 부여하려는 경우입니다. 접속한 서버에서 텍스트 편집기로 파일을 엽니다.
```
nano ~/.ssh/authorized_keys
# 또는
vi ~/.ssh/authorized_keys
```
파일에는 이미 기존 퍼블릭 키가 한 줄로 들어 있습니다. 그 아래 줄에 3단계에서 확보한 새 퍼블릭 키를 붙여 넣고 저장합니다. 결과 예시는 다음과 같습니다(값은 예시이며 실제 키는 훨씬 깁니다).
```
ssh-rsa AAAAB3NzaC1yc2E...기존키... existing-key
ssh-ed25519 AAAAC3NzaC1lZDI1...새로추가한키... your-name@example.com
```
퍼블릭 키는 반드시 줄바꿈 없이 한 줄로 붙여 넣어야 합니다. 중간에 줄이 나뉘면 인증에 실패합니다. 편집기 자동 줄바꿈(word wrap) 때문에 화면상 여러 줄로 보여도 실제 개행이 없으면 괜찮습니다.

명령 한 줄로 안전하게 추가(append)하려면 서버에서 다음처럼 실행할 수도 있습니다. 리디렉션은 반드시 >>(추가)를 사용하십시오. >(덮어쓰기)를 쓰면 기존 키가 지워집니다.
```
echo "ssh-ed25519 AAAAC3NzaC1lZDI1...새로추가한키... your-name@example.com" >> ~/.ssh/authorized_keys
```
파일과 디렉터리 권한이 정확해야 SSH가 키를 인정합니다. 권한이 지나치게 개방적이면 로그인 자체가 거부됩니다.
```
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
```
- .ssh 디렉터리 700: 소유자만 읽기/쓰기/접근 가능.
- authorized_keys 파일 600: 소유자만 읽기/쓰기 가능.
기본 사용자가 아니라 새로운 시스템 사용자(예: 담당자 개인 계정)를 만들어 그 사용자에게만 키를 부여하려면, 서버에서 sudo adduser newuser로 사용자를 만든 뒤 sudo su - newuser로 전환하고, 해당 사용자 홈에 mkdir .ssh && chmod 700 .ssh, touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys를 수행한 다음 그 파일에 퍼블릭 키를 붙여 넣습니다. 이렇게 하면 사용자별로 파일·작업 공간과 접속 키를 분리할 수 있어, 여러 사람이 기본 사용자를 공유하는 것보다 안전합니다.
새 키로 접속 테스트하기

기존 세션은 그대로 두고(잠금 방지), 새 터미널에서 새 프라이빗 키로 접속을 시도합니다.
```
ssh -i ~/.ssh/myserver-second-key ec2-user@<퍼블릭_IP_또는_퍼블릭_DNS>

# [방법 A]에서 .pem을 받은 경우
ssh -i myserver-second-key.pem ec2-user@<퍼블릭_IP_또는_퍼블릭_DNS>
```
정상적으로 로그인되면 추가 작업이 완료된 것입니다. 접속이 안 되면 8단계 확인 방법과 주의사항을 점검하십시오.

새 키 접속이 성공한 것을 확인하기 전에는 기존 접속 세션을 닫지 마십시오. 만약 새 키에 문제가 있는데 기존 세션까지 닫으면 서버에 접근할 수 없게 될 수 있습니다.
(선택) 기존 키를 교체하는 경우: 이전 퍼블릭 키 제거

기존 키를 완전히 무효화하려는 목적이라면, 새 키로 접속이 잘 되는 것을 확인한 뒤 다시 서버에 접속해 ~/.ssh/authorized_keys에서 이전 퍼블릭 키가 있는 줄만 삭제하고 저장합니다.

authorized_keys에서 모든 퍼블릭 키를 지우고 접속을 끊으면, 다른 로그인 수단(EC2 Instance Connect, Session Manager 등)을 미리 마련해 두지 않은 한 다시 접속할 수 없습니다. 최소 한 개의 유효한 키는 남겨 두십시오.
확인용 참고: 콘솔 키 페어 목록 확인

EC2 콘솔의 Key Pairs(키 페어) 화면에서 새로 만든(또는 임포트한) 키 페어가 목록에 나타나는지 확인합니다. 각 항목의 Name, Type(rsa/ed25519), Fingerprint를 볼 수 있습니다.

콘솔의 키 페어 목록은 "AWS가 보관하는 퍼블릭 키 등록부"일 뿐, 실행 중인 인스턴스의 authorized_keys 실제 내용과 자동으로 동기화되지 않습니다. 콘솔에서 키 페어를 삭제해도 이미 인스턴스에 올라간 퍼블릭 키는 그대로 남고, 반대로 authorized_keys를 직접 수정해도 콘솔 목록은 바뀌지 않습니다. 접속 허용 여부는 서버의 authorized_keys가 최종 결정합니다.

CLI 대안

콘솔 대신 AWS CLI로 키 페어를 생성·임포트·확인할 수 있습니다.

# 1) EC2가 키 페어를 생성하고 프라이빗 키를 .pem으로 저장(방법 A의 CLI 버전)
aws ec2 create-key-pair \
    --key-name myserver-second-key \
    --key-type ed25519 \
    --key-format pem \
    --query "KeyMaterial" \
    --output text > myserver-second-key.pem
chmod 400 myserver-second-key.pem

--key-name: AWS에 등록할 키 페어 이름.
--key-type: rsa 또는 ed25519.
--key-format: pem(OpenSSH) 또는 ppk(PuTTY).
--query "KeyMaterial" --output text: 응답에서 프라이빗 키 본문만 뽑아 텍스트로 출력하고, >로 파일에 저장합니다.

# 2) 로컬에서 만든 퍼블릭 키를 EC2에 등록(방법 B의 선택 단계)
aws ec2 import-key-pair \
    --key-name myserver-second-key \
    --public-key-material fileb://~/.ssh/myserver-second-key.pub

--public-key-material fileb://...: 로컬 퍼블릭 키 파일을 바이너리로 읽어 그대로 업로드합니다. 이 명령은 퍼블릭 키만 등록하며 프라이빗 키는 전송되지 않습니다.

# 3) 임포트/생성 결과 확인
aws ec2 describe-key-pairs --key-names myserver-second-key

확인 방법

새 키로 로그인 성공: ssh -i <새_프라이빗_키> <user>@<주소>로 셸 프롬프트가 정상적으로 뜨면 성공입니다.
상세 로그 확인: 실패 시 ssh -v -i <키> <user>@<주소>로 자세한 협상 로그를 볼 수 있습니다. "Server accepts key", "Authentication succeeded (publickey)" 메시지가 보이면 키가 정상 동작한 것입니다.
서버 측 등록 상태: 서버에서 cat ~/.ssh/authorized_keys로 기존 키와 새 키가 각각 한 줄씩, 총 두 줄(또는 그 이상)로 들어 있는지 확인합니다.
지문(fingerprint) 대조: 로컬에서 ssh-keygen -l -f ~/.ssh/myserver-second-key.pub로 새 키의 지문을 확인하고, EC2 콘솔 Key Pairs 목록의 Fingerprint 또는 aws ec2 describe-key-pairs --key-names myserver-second-key 결과와 일관되는지 교차 확인할 수 있습니다.

주의사항

프라이빗 키 취급: 프라이빗 키는 절대 공유·전송하지 마십시오. 서버 위에서 프라이빗 키를 만들어 로컬로 내려받는 방식(scp로 서버의 프라이빗 키를 가져오기 등)은 유출 위험이 크므로 피하고, 사용할 PC에서 직접 생성해 그 자리에 보관하십시오.
퍼블릭 키는 한 줄: authorized_keys에 넣는 퍼블릭 키는 개행 없이 한 줄이어야 합니다. 복사·붙여넣기 과정에서 줄이 끊기지 않았는지 확인하십시오.
권한 값 준수: ~/.ssh는 700, authorized_keys는 600, 프라이빗 키 파일은 400이어야 합니다. 권한이 과도하게 열려 있으면 SSH가 보안상 사용을 거부합니다.
모든 키 제거 금지: authorized_keys에서 모든 퍼블릭 키를 지우면 대체 접속 수단 없이는 재접속이 불가능합니다. 교체 작업 시에는 새 키 접속 성공을 확인한 뒤에 기존 키를 지우십시오.
콘솔 키 페어와 서버 실제 상태의 분리: 콘솔에서 키 페어를 삭제해도 인스턴스에 이미 올라간 퍼블릭 키는 제거되지 않습니다. 접근을 실제로 차단하려면 인스턴스의 authorized_keys에서 해당 키를 직접 지워야 합니다.
리전 스코프: 키 페어는 리전별 리소스입니다. 다른 리전의 인스턴스에는 그 리전에서 만든(또는 임포트한) 키 페어를 사용해야 합니다.
Auto Scaling·시작 템플릿·시작 구성 반영: 키를 교체하는데 Auto Scaling 그룹, EC2 Fleet, 시작 템플릿/시작 구성에서 이전 키 페어를 참조하고 있다면 함께 갱신하십시오. 그렇지 않으면 새로 시작되는 인스턴스가 예상과 다른 키를 갖게 되거나 시작에 실패할 수 있습니다.
AMI 복제 시 키 상속: 인스턴스로 AMI를 만들면 그 시점의 퍼블릭 키가 AMI에 함께 복사됩니다. 특정 키의 접근을 원치 않는다면 AMI를 만들기 전에 원본 인스턴스에서 해당 퍼블릭 키를 제거하십시오.
키 유형/길이 제약: Amazon EC2는 DSA 키를 허용하지 않습니다. ED25519는 Linux 전용입니다. EC2 Instance Connect API를 함께 사용할 때는 지원 키 길이가 RSA 2048/4096으로 제한됩니다.

참고 공식 문서

Add or replace a public key on your Linux instance — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/replacing-key-pair.html
Create a key pair for your Amazon EC2 instance (콘솔/CLI 생성, 서드파티 도구 생성 및 퍼블릭 키 임포트) — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/create-key-pairs.html
Manage system users on your Amazon EC2 Linux instance (신규 사용자 생성 및 퍼블릭 키 등록) — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/managing-users.html
Connect to your Linux instance using SSH — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html
Import a public key (AWS CLI import-key-pair 예시) — https://docs.aws.amazon.com/ec2/latest/devguide/example_ec2_ImportKeyPair_section.html

ssh-keygen의 대화형 프롬프트(저장 경로·passphrase 입력)와 ssh/scp/chmod의 동작은 AWS 고유 기능이 아니라 표준 OpenSSH 동작을 근거로 서술했습니다. 실제 화면 문구는 클라이언트 버전에 따라 미세하게 다를 수 있으며, 그 외 콘솔 절차는 위 공식 문서 기준으로 작성했습니다.

검색

Tech Support Center 2.0

개요