개요

---

저번 주에 보안상의 이유로 EC2의 /etc/ssh/sshd_config를 잘못 건드려 저장하는 바람에 EC2에 접속이 막혔었습니다. (다들 한 번씩은 겪어보셨..?)

이러저러한 이유로 EC2에 접속 못하게 됐을 때 복구하는 방법이 많아 몇 가지를 알아보고자 합니다.

1. EC2 직렬 콘솔 사용

---

가장 간단한 방법은 `EC2 직렬 콘솔`을 통해 연결하여 sshd_config를 직접 수정하는 방법입니다.

하지만 직렬 콘솔은 프리티어인 t2는 지원하지 않기에 자신의 인스턴스가 직렬 콘솔을 지원할 경우만 가능하다는 단점이 있기에 잘 알아보고 시도해야합니다.

직렬 콘솔에 대한 정보는 공식 문서에서 확인이 가능합니다.

2. 복구 인스턴스 사용

---

직렬 콘솔로 복구가 안될 경우 복구 인스턴스를 사용할 수 있습니다.

복구 인스턴스 사용은 기존 인스턴스를 중지해야하는데 몇 가지 점검사항이 있으니

공식 문서를 통해 잘 이해한 뒤 시도해야합니다.

1. 중지할 인스턴스에 인스턴스 스토어 볼륨이 있으면 인스턴스를 중지할 때 데이터가 손실됩니다.
2. 중지할 인스턴스가 Auto Scaling 그룹의 일부인 경우 그룹에서 일시적으로 인스턴스를 제거한 뒤 시도합니다.
3. 인스턴스를 재가동하면 퍼블릭 IP 주소가 변경되므로, 탄력적 IP주소를 사용하는 게 좋습니다.

위 항목을 점검하고 준비를 완료했다면 아래의 절차대로 진행할 수 있습니다.

1. VPC에서 새 EC2 인스턴스(복구용)을 시작합니다.

중지한 인스턴스와 동일한 가용영역(ap-northeast-2a 등)과 동일한 AMI를 사용하여 새 인스턴스를 만들어줍니다.


2. 손상된 인스턴스를 중지합니다.

인스턴스 볼륨 스토어, Auto Scaling 등 영향을 받을 수 있는 항목들을 점검한 뒤 인스턴스를 중지해줍니다.


3. 손상된 인스턴스에서 루트볼륨(EBS)을 분리합니다.

루트볼륨은 인스턴스 중지가 끝난 뒤에 분리할 수 있습니다.


4. 복구 인스턴스에 보조 디바이스(/dev/sdf)로 EBS 볼륨을 연결합니다.

5. SSH를 사용하여 복구 인스턴스에 연결합니다.

6. lsblk 명령을 실행하여 디바이스를 봅니다.

$ 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   8G  0 disk
 └─xvdf1 202:81   0   8G  0 part

7. 복구 인스턴스에 기존 볼륨을 마운트할 디렉토리(/rescue)를 생성합니다.

# rescue 대신 원하는 명칭 사용 가능
sudo mkdir /mnt/rescue

8. 생성한 디렉토리에 볼륨을 마운트합니다.

sudo mount /dev/xvdf1 /mnt/rescue

9. lsblk 명령을 다시 실행하여 볼륨이 디렉토리에 마운트 되었는 지 확인합니다.

$ 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   8G  0 disk
└─xvdf1 202:81   0   8G  0 part /mnt/rescue

10. sshd_config 파일을 수정하거나 복사합니다.

# 수정
sudo vi /mnt/rescue/etc/ssh/sshd_config

# 복사
$ sudo cp /etc/ssh/sshd_config /mnt/resscue/etc/ssh/sshd_config

11. 볼륨을 원래 인스턴스에 다시 연결하고 테스트합니다.
기존 볼륨을 명령어를 통해 마운트 해제시켜준 뒤 AWS Console을 통해 볼륨을 해제 시켜주면 됩니다.

# target is busy 오류가 날 경우 해당 디렉토리에서 다시 빠져나와서 명령어를 입력해줍니다.
sudo umount /mnt/rescue

참고

---

• sshd_config 파일 변경 시 해결방법 - AWS 공식문서