인스턴스의 sshd_config 파일을 변경한 후 SSH를 사용하여 EC2 인스턴스에 액세스하려면 어떻게 해야 합니까?

간략한 설명

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

연결 거부 오류로 인해 인스턴스에 액세스할 수 없음을 확인하려면 상세 메시징을 켜고 SSH를 통해 인스턴스에 액세스하세요. 다음 예제를 참조하세요.

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

이 예제에서는 DNS 이름을 사용하여 연결하고 myawskey.pem을 프라이빗 키 파일, ec2-user를 사용자 이름으로 사용합니다. 예제의 키 파일과 사용자 이름을 해당하는 키 파일 및 사용자 이름으로 대체하세요.

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

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 기반 인스턴스를 사용하는 경우 기기 이름은 다음 단계에 제공된 예와 다릅니다. 예를 들어, Nitro 기반 인스턴스의 디바이스 이름은 /dev/xvda나 /dev/sda1가 아니라 /dev/nvme입니다. 자세한 내용은 Linux 인스턴스의 디바이스 이름을 참조하세요.

방법 1: EC2 직렬 콘솔 사용

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

직렬 콘솔을 사용하기 전에 계정 수준에서 콘솔에 대한 액세스 권한을 부여하세요. 그런 다음 IAM 사용자에게 액세스 권한을 부여하는 AWS ID 및 액세스 관리 (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 주소가 변경됩니다. 인스턴스를 다시 시작하거나 종료할 때 EC2 퍼블릭 IP 주소가 변경되지 않도록 하려면 Elastic IP 주소를 사용하세요. Amazon 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. EBS 볼륨을 보조 디바이스**(/dev/sdf**)로 복구 인스턴스에 연결합니다.

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

**참고:**이전 마운트 명령의 구문은 다를 수 있습니다. 자세한 내용을 보려면 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/rescue/etc/ssh/sshd_config

볼륨을 원본 인스턴스에 다시 연결하고 연결을 테스트합니다.

**참고:**방법 2를 사용한 경우: 복구 인스턴스를 사용한 후 다음 단계를 완료하세요.

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

$ sudo umount /mnt/rescue/

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

3. 인스턴스를 시작합니다.

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

관련 정보

SSH를 사용하여 Amazon EC2 Linux 인스턴스에 연결할 수 없는 이유는 무엇입니까?