EC2 인스턴스의 sshd_config 파일을 변경했습니다. 그랬더니 SSH를 사용하여 인스턴스에 액세스할 수 없습니다. 문제를 해결하려면 어떻게 해야 하나요?

5분 분량

Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스의 sshd_config 파일을 변경했는데 이제 SSH를 사용하여 인스턴스에 액세스할 수 없습니다. 어떻게 문제를 해결할 수 있습니까?

간략한 설명

인스턴스의 sshd_config 파일을 변경하면 SSH를 통해 연결할 때 연결 거부 오류가 발생할 수 있습니다.

연결 거부 오류로 인해 인스턴스에 액세스할 수 없음을 확인하려면 자세한 정보 표시 메시징을 사용하여 SSH를 통해 인스턴스에 액세스합니다.

$ ssh -i "myawskey.pem" ec2-user@ec2-11-22-33-44.eu-west-1.compute.amazonaws.com -vvv

앞의 예에서는 프라이빗 키 파일에 myawskey.pem을 사용하고 ec2-user@ec2.11.22.33.44를 사용자 이름으로 사용합니다. 키 파일과 사용자 이름을 예제의 키 파일과 사용자 이름으로 대체합니다. 반드시 인스턴스가 위치한 리전을 사용해야 합니다.

다음 예제 출력에서는 연결 거부 오류 메시지를 보여줍니다.

OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to ec2-11-22-33-44.eu-west-1.compute.amazonaws.com port 22.
ssh: connect to host ec2-11-22-33-44.eu-west-1.compute.amazonaws.com port 22: Connection refused

해결 방법

참고: Nitro 기반 인스턴스를 사용하는 경우 디바이스 이름은 다음 단계에 나와 있는 예와 다릅니다. 예를 들어 /dev/xvda 또는 /dev/sda1 대신 Nitro 기반 인스턴스의 디바이스 이름은 /dev/nvme입니다. 자세한 내용은 Linux 인스턴스의 디바이스 이름을 참조하세요.

방법 1: EC2 직렬 콘솔 사용

Linux용 EC2 직렬 콘솔을 활성화한 경우 이 콘솔을 사용하여 지원되는 Nitro 기반 인스턴스 유형의 문제를 해결할 수 있습니다. 직렬 콘솔을 사용하면 부팅 문제, 네트워크 구성 및 SSH 구성 문제를 해결할 수 있습니다. 직렬 콘솔은 작동 중인 네트워크 연결 없이 인스턴스에 연결됩니다. Amazon EC2 콘솔 또는 AWS 명령줄 인터페이스(AWS CLI)를 사용하여 직렬 콘솔에 액세스할 수 있습니다.

직렬 콘솔을 사용하기 전에 계정 수준에서 콘솔에 대한 액세스 권한을 부여합니다. 그런 다음 IAM 사용자에게 액세스 권한을 부여하는 AWS Identity and Access Management(IAM) 정책을 생성합니다. 또한 직렬 콘솔을 사용하는 모든 인스턴스에는 암호 기반 사용자가 한 명 이상 포함되어야 합니다. 인스턴스에 연결할 수 없고 직렬 콘솔에 대한 액세스를 구성하지 않은 경우 다음 섹션인 방법 2: 복구 인스턴스 사용의 지침을 따릅니다. Linux용 EC2 직렬 콘솔 구성에 대한 자세한 내용은 EC2 직렬 콘솔에 대한 액세스 구성을 참조하세요.

참고: AWS CLI 명령을 실행할 때 오류가 발생하는 경우 최신 버전의 AWS CLI를 사용하고 있는지 확인하세요.

방법 2: 복구 인스턴스 사용

경고: 인스턴스를 중지하고 시작하기 전에 다음을 이해해야 합니다.

사용하는 인스턴스가 인스턴스 스토어 지원 인스턴스이거나 데이터가 포함된 인스턴스 스토어 볼륨이 있으면 인스턴스를 중지할 때 데이터가 손실됩니다. 자세한 내용은 인스턴스의 루트 디바이스 유형 확인을 참조하세요.
인스턴스가 Amazon EC2 Auto Scaling 그룹의 일부인 경우 인스턴스를 중지하면 인스턴스가 종료될 수 있습니다. Amazon EMR, AWS CloudFormation 또는 AWS Elastic Beanstalk를 사용하여 인스턴스를 시작한 경우 인스턴스가 AWS Auto Scaling 그룹의 일부일 수 있습니다. 이 시나리오에서 인스턴스의 종료는 Auto Scaling 그룹에 대한 인스턴스 확대 보호 설정에 따라 달라집니다. 인스턴스가 Auto Scaling 그룹의 일부인 경우, 문제 해결 단계를 시작하기 전에 Auto Scaling 그룹에서 일시적으로 인스턴스 제거합니다.
인스턴스를 중지하고 다시 시작하면 인스턴스의 퍼블릭 IP 주소가 변경됩니다. 외부 트래픽을 인스턴스로 라우팅할 때에는 퍼블릭 IP 주소 대신 탄력적 IP 주소를 사용하는 것이 모범 사례입니다. Route 53를 사용하는 경우 퍼블릭 IP가 변경될 때 Route 53 DNS 레코드를 업데이트해야 할 수 있습니다.

1. Virtual Private Cloud(VPC)에서 새 EC2 인스턴스를 시작합니다. 손상된 인스턴스와 동일한 가용 영역에서 동일한 Amazon Machine Image(AMI)를 사용합니다. 새 인스턴스가 복구 인스턴스가 됩니다.

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

참고: 스토어 지원 인스턴스를 사용하거나 데이터가 포함된 인스턴스 스토어 볼륨이 있는 경우 인스턴스를 중지하면 데이터가 손실됩니다. 자세한 내용은 인스턴스의 루트 디바이스 유형 확인을 참조하세요.

3. 손상된 인스턴스에서 Amazon Elastic Block Store(Amazon EBS) 루트 볼륨(/dev/xvda 또는 /dev/sda1)을 분리합니다.

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. 4단계에서 복구 인스턴스에 연결한 새 볼륨의 탑재 지점 디렉터리(/rescue)를 생성합니다.

$ sudo mkdir /mnt/rescue

8. 7단계에서 생성한 디렉터리에 볼륨을 마운트합니다.

$ sudo mount -t xfs -o nouuid /dev/xvdf1 /mnt/rescue/

ext3 및 ext4 파일 시스템을 마운트하려면 다음 명령을 실행합니다.

$ sudo mount /dev/xvdf1 /mnt/rescue

참고: 이전 mount 명령의 구문은 다를 수 있습니다. 자세한 내용을 보려면 man mount 명령을 실행하세요.

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

sshd_config 파일 수정 또는 복사

손상된 인스턴스에서 sshd_config 파일을 조사하고 변경 사항을 롤백할 수 있습니다. SSH 자세한 정보 표시 메시징 출력을 사용하여 파일의 오류 위치로 안내합니다.

$ sudo vi /mnt/rescue/etc/ssh/sshd_config

또는 다음 명령을 사용하여 복구 인스턴스에서 손상된 인스턴스로 sshd_config 파일을 복사합니다. 이 명령은 원본 인스턴스에 있는 sshd_config 파일의 내용을 대체합니다.

$ sudo cp /etc/ssh/sshd_config /mnt/resscue/etc/ssh/sshd_config

볼륨을 원래 인스턴스에 다시 연결하고 연결을 테스트

참고: 방법 2: 복구 인스턴스 사용을 사용한 경우 다음 단계를 완료하십시오.

1. umount 명령을 실행하여 볼륨의 마운트를 해제합니다.

$ sudo umount /mnt/rescue/

2. 복구 인스턴스에서 보조 볼륨을 분리한 다음 볼륨을 원래 인스턴스에 /dev/xvda(루트 볼륨)로 연결합니다.

3. 인스턴스 시작

4. SSH를 사용하여 인스턴스에 연결할 수 있는지 확인합니다.