EC2 SSH 접속 오류 해결 – "Error establishing SSH connection to your instance"

예전에 만들었던 프로젝트를 다시 디벨롭하고자 서버를 새로 구축하고 기존에 구성해둔 CI/CD 파이프라인을 다시 작동시키는 과정에서 SSH 접속 오류가 발생했습니다. 에러 메시지는 아래와 같았습니다.

❌ Failed to connect to your instance
Error establishing SSH connection to your instance. Try again later.

결론적으로 볼륨 복구 및 키 재설정을 통해 문제를 해결했고, CI/CD도 무사히 구축했습니다. 이 글에서는 문제 발생부터 해결까지의 흐름을 정리합니다.

[문제 상황]

이전 서버는 비용 문제로 중지하고, 계정을 탈퇴한 상황
새로운 EC2 인스턴스를 생성하며 새 키 페어를 .ppk 형식으로 생성
해당 .ppk 키를 사용해 Putty로 EC2에 접속하여 도커 설치 및 초기 서버 세팅 완료
이후 기존에 구성해두었던 CI/CD 파이프라인을 다시 실행하기 위해 GitHub Actions 시크릿에 SSH 키 등록 필요
하지만 GitHub Actions에서는 .pem 형식의 키 파일을 요구
이에 PuttyGen을 사용하여 .ppk 파일을 id_rsa 형식으로 변환한 후 GitHub 시크릿에 등록
GitHub Actions는 정상적으로 배포 성공 메시지를 출력함
그러나 Putty로는 접속이 되지 않고, AWS 콘솔에서는 다음과 같은 오류 발생

[문제 상황 설명]

"GitHub Actions에서 사용한 .pem 키에 대응되는 공개키가 EC2 인스턴스에 등록되지 않았기 때문"

.pem 파일은 비공개 키(private key)이며, 주로 GitHub Actions나 로컬 PC에서 SSH 접속 시 인증 용도로 사용됩니다. 이 비공개 키에 대응하는 공개 키는 ssh-rsa ...와 같은 형태로 되어 있으며, 해당 공개 키가 EC2 인스턴스의 ~/.ssh/authorized_keys 파일에 등록되어 있어야만 SSH 접속이 성공할 수 있습니다. 즉, .pem 파일만 가지고 있어서는 접속이 불가능하고, 반드시 이에 대응하는 공개 키가 EC2 내부에 존재해야 키 쌍이 일치하여 인증이 통과됩니다.

하지만 이번 상황에서는 공개 키가 EC2 인스턴스에 등록되지 않은 상태에서 CI/CD를 실행했고, 이로 인해 접속이 차단되어 문제가 발생한 것으로 보입니다.
또한, 공개 키를 수동으로 등록하기 위해서는 EC2에 직접 접속해야 하는데 이미 접속이 불가능한 상태였습니다. 이에 따라 아래와 같은 순서로 문제를 해결했습니다.

[해결 방법]

1.기존 EC2 인스턴스 중지

기존 인스턴스에 SSH 접속이 불가능한 상황이므로 먼저 EC2 인스턴스를 중지했습니다.

2. 기존 EC2 인스턴스의 루트 볼륨 분리

EC2 콘솔 > EBS > 해당 인스턴스의 루트 볼륨을 분리했습니다. (중지 상태여야 분리 가능)

3. 새로운 EC2 인스턴스 생성

기존 EC2와 동일한 리전, 가용영역, os로 인스턴스를 생성해야 기존 볼륨을 붙일 수 있습니다.
그리고 이때 새 인스턴스에 생성되는 볼륨은 싱경쓰지 않습니다.

4. 기존 인스턴스의 루트 볼륨을 새 인스턴스에 연결

EBS → 기존 인스턴스에서 분리한 루트 볼륨의 연결을 누르고 아래와 같이 선택합니다.
인스턴스: 새로 만든 인스턴스 선택
디바이스 이름: 예시 /dev/sdf 입력 (자동으로 /dev/xvdf 등으로 변환됨)

5. 새 인스턴스에 SSH 접속 → 볼륨 마운트

기존 EC2 인스턴스의 루트 볼륨을 새 인스턴스에 붙인 상태이므로 이 볼륨의 파일을 확인하고 수정할 수 있도록 임시 폴더에 연결(마운트) 해주는 작업을 합니다.

1. SSH 접속

새로 만든 EC2 인스턴스에 .pem 파일이나 .ppk 파일을 이용해 SSH로 접속합니다.

ssh -i [키파일.pem] ubuntu@[퍼블릭 IP 주소]

2. 볼륨이 연결되었는지 확인

아래 명령어로 현재 연결된 디스크를 확인할 수 있습니다:

lsblk

일반적으로 기존 볼륨은 /dev/xvdf 또는 /dev/nvme1n1 등의 이름으로 표시됩니다.
이 디스크의 하위 파티션(예: /dev/xvdf1, /dev/nvme1n1p1)이 있으면 그것이 실제 데이터가 들어있는 공간입니다.

3. 마운트할 디렉토리 생성

연결된 디스크의 내용을 보기 위해 빈 폴더를 하나 만듭니다:

sudo mkdir /mnt/old

4. 볼륨 마운트

실제 볼륨을 위에서 만든 디렉토리에 마운트합니다:

sudo mount /dev/xvdf1 /mnt/old

이때 xvdf1은 상황에 따라 xvdf, nvme1n1p1, nvme1n1 등으로 다를 수 있으니, lsblk 명령으로 확인한 장치 이름을 정확히 입력해야 합니다.

"마운트(mount)란?"

하드디스크나 외장 저장장치를 특정 폴더에 연결해서, 그 안의 파일을 일반 폴더처럼 접근할 수 있게 만드는 작업입니다.
예를 들어 /mnt/old 폴더로 들어가면 마치 옛날 인스턴스의 루트 디렉토리에 들어가는 것처럼 파일들을 볼 수 있게 됩니다.

6. 마운트된 볼륨의 authorized_keys 수정

Puttygen으로 .ppk를 Load하고, Public key for pasting into OpenSSH authorized_keys file 내용을 복사합니다.
복사한 키는 ssh-rsa ... 형식입니다.

sudo nano /mnt/old/home/ubuntu/.ssh/authorized_keys

편집기가 열리면 맨 아래에 복사한 ssh-rsa ... 공개키를 붙여넣습니다.
Ctrl + O → Enter로 저장하고, Ctrl + X로 편집기를 종료합니다.

이 작업은 GitHub Actions나 로컬 PC에서 사용하는 비공개 키(.pem)와 연결되는 공개키를 EC2 인스턴스에 등록하는 작업입니다. 그래야 SSH 인증이 성공합니다.

7. 언마운트

우리가 수정한 볼륨은 현재 임시 디렉터리(/mnt/old)에 연결된 상태입니다. 이 연결을 끊는 작업이 언마운트(unmount)입니다.
볼륨 사용을 마쳤다면 반드시 연결을 끊어야 시스템에 안전합니다.

sudo umount /mnt/old

8. 볼륨 분리

새 인스턴스에서 해당 볼륨을 분리합니다.

9. 다시 기존 EC2 인스턴스에 루트 볼륨 연결

다시 해당 루트 볼륨을 원래 EC2 인스턴스에 연결합니다.
디바이스 이름은 반드시 /dev/sda1로 설정해야 루트 볼륨으로 인식됩니다.

10. 기존 EC2 인스턴스 시작(Start)

EC2 콘솔에서 중지했던 원래 인스턴스를 Start합니다.
이제 SSH 키가 정상화되었기 때문에 정상적으로 접속 가능해야 합니다.

11. SSH 접속 및 GitHub Actions CI/CD 모두 정상 작동

[결론]

이번 경험을 통해 SSH 접속 방식에 대해 확실히 배웠다. Putty에서 사용하는 .ppk는 비공개 키이고, 이와 짝이 맞는 공개 키(ssh-rsa ...)가 EC2 내부 ~/.ssh/authorized_keys에 있어야 접속이 가능하다는 것을 이해할 수 있었다.

이전 EC2 인스턴스를 중지한 상태에서 직접 볼륨을 분리하고, 새 인스턴스에 마운트한 뒤 authorized_keys를 수정하는 방식으로 SSH 접속 문제를 해결하는 과정을 통해 EC2 EBS 볼륨 마운트, SSH 키 구조, 접속 복구 흐름까지 익힐 수 있었다.

DevLog