저번 주에 보안상의 이유로 EC2의 /etc/ssh/sshd_config
를 잘못 건드려 저장하는 바람에 EC2에 접속이 막혔었습니다. (다들 한 번씩은 겪어보셨..?)
이러저러한 이유로 EC2에 접속 못하게 됐을 때 복구하는 방법이 많아 몇 가지를 알아보고자 합니다.
하지만 직렬 콘솔은 프리티어인 t2는 지원하지 않기에 자신의 인스턴스가 직렬 콘솔을 지원할 경우만 가능하다는 단점이 있기에 잘 알아보고 시도해야합니다.
직렬 콘솔에 대한 정보는 공식 문서에서 확인이 가능합니다.
복구 인스턴스 사용은 기존 인스턴스를 중지해야하는데 몇 가지 점검사항이 있으니
공식 문서를 통해 잘 이해한 뒤 시도해야합니다.
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