Amazon EC2-재부팅 후 SSH 없음, 연결 거부

나는 이것을 두세 번 복제 했으므로 내가하고있는 일에 문제가 있다고 생각합니다.

내 단계는 다음과 같습니다.

1. 다음을 사용하여 EC2 관리 콘솔을 통해 새 인스턴스를 시작하십시오. Ubuntu Server 13.10-ami-ace67f9c (64 비트)
2. 기본값으로 시작 (기존 키 페어 사용)
3. 인스턴스가 시작됩니다. Putty 또는 Mac 터미널을 사용하여 SSH로 연결할 수 있습니다. 성공!
4. 인스턴스를 재부팅합니다

5. 10 분 후 인스턴스를 백업하고 실행해야 할 때 터미널 연결에 다음이 표시됩니다.

   stead:~ stead$ ssh -v -i Dropbox/SteadCloud3.pem ubuntu@54.201.200.208
   OpenSSH_5.6p1, Op`enSSL 0.9.8y 5 Feb 2013
   debug1: Reading configuration data /etc/ssh_config
   debug1: Applying options for *
   debug1: Connecting to 54.201.200.208 [54.201.200.208] port 22.
   debug1: connect to address 54.201.200.208 port 22: Connection refused
   ssh: connect to host 54.201.200.208 port 22: Connection refused
   stead:~ stead$
   

퍼블릭 IP 주소가 변경 될 수 있음을 이해하고 EC2 관리 콘솔을 확인하면 동일한 지 확인합니다. 기묘한. 재미를 위해 공개 DNS 호스트 이름 ec2-54-201-200-208.us-west-2.compute.amazonaws.com으로 연결을 시도합니다. 주사위도없고 같은 결과입니다.

EC2 콘솔에 내장 된 Java SSH 클라이언트를 통한 연결을 사용하더라도 연결이 거부됩니다.

보안 그룹을 확인했습니다. 이 인스턴스는 launch-wizard-4 그룹에 있습니다. 이 그룹의 인바운드 구성을 살펴보면 포트 22는 0.0.0.0/0부터 허용되므로 어디에서나 가능합니다. 인스턴스에 타격을 가하고 있는데 인스턴스를 핑할 수 없기 때문에 이것이 올바른 보안 그룹입니다. 이 보안 그룹에 ICMP를 사용하면 갑자기 핑이 발생합니다.

인터넷에서 비슷한 오류 메시지가있는 다른 게시물을 찾았지만 대부분 방화벽 설정을 조정하면 쉽게 해결할 수 있습니다. 나는 운이없이 몇 가지를 시도했습니다.

누락 된 간단한 EC2 단계가 있다고 생각합니다. 도움을 주셔서 감사합니다. 추가 정보를 제공하거나 추가로 테스트 해 드리겠습니다.

업데이트-Amazon EC2 콘솔의 시스템 로그는 다음과 같습니다. http://pastebin.com/4M5pwGRt

오늘 내 ec2 인스턴스에서 비슷한 동작이 있었으며이를 추적했습니다. sudo reboot now 시스템을 중지하면 시스템이 sudo reboot 재부팅 되면 aws 관리 콘솔에서 수동으로 다시 시작해야 합니다. /ubuntu/397502/reboot-a-server-from-command-line에서 지적한 것처럼 "지금"은 재부팅에 유효한 옵션이 아닙니다.

생각?

에서 이 주제에 대한 AWS 개발자 포럼 게시물 :

손상된 인스턴스를 중지하고 EBS 볼륨을 분리 한 후 다른 인스턴스에 보조 볼륨으로 연결하십시오. 다른 인스턴스 어딘가에 고장난 볼륨을 마운트했으면 / etc / sshd_config 파일 (하단 근처)을 확인하십시오. Yum이 바닥에 중복 줄을 삽입하여 sshd_config를 검색하여 구문 오류로 인해 시작시 sshd가 실패한 RHEL 인스턴스가 몇 개있었습니다.

수정 한 후에는 볼륨을 마운트 해제하고 분리 한 후 다른 인스턴스에 다시 연결하고 다시 실행하십시오.

AWS 설명서에 대한 링크를 사용하여이를 분류 해 보겠습니다.

1. EC2 관리 콘솔로 이동하여 "Elastic Block Store"> "Volumes"를 클릭하여 중지 된 인스턴스와 관련된 볼륨을 마우스 오른쪽 버튼으로 클릭 하여 손상된 인스턴스를 중지하고 EBS (루트) 볼륨을 분리하십시오.
2. 손상된 인스턴스와 동일한 리전 및 동일한 OS에서 새 인스턴스 를 시작한 다음 원래 EBS 루트 볼륨을 보조 볼륨으로 새 인스턴스에 연결합니다 . 아래 4 단계의 명령은 볼륨을 "data"라는 폴더에 마운트한다고 가정합니다.
3. 당신이하면 다른 인스턴스에서 깨진 볼륨 어딘가를 장착 ,
4. 다음 명령을 실행하여 "/ etc / sshd_config"파일에서 중복 항목을 확인하십시오.
   • cd /etc/ssh
   • sudo nano sshd_config
   • ctrl-v 파일의 맨 아래에 도착하는 여러 번
   • ctrl-k "비밀번호없이 PermitRootLogin"및 "UseDNS no"를 언급하는 모든 줄
   • ctrl-x및 Y저장하고 편집 된 파일을 종료합니다
5. @Telegard는 (그의 의견으로는) 증상을 고쳤다 고 지적합니다 . "/etc/rc.local"파일에서 3 개의 관련 줄을 주석 처리 하여 원인 을 해결할 수 있습니다 . 그래서:
   • cd /etc
   • sudo nano rc.local
   • "PermitRootLogin ..."행을 찾아 삭제하십시오.
   • ctrl-x및 Y저장하고 편집 된 파일을 종료합니다
6. 수정 한 후에 는 볼륨을 마운트 해제하십시오 .
7. EC2 관리 콘솔로 이동하여 "Elastic Block Store"> "볼륨"을 클릭하고 중지 한 인스턴스와 관련된 볼륨을 마우스 오른쪽 버튼으로 클릭 한 다음,
8. 다른 인스턴스에 다시 연결 하고
9. 다시 발사하십시오 .

상황에 도움이되지 않을 수도 있지만 EC2의 재부팅이 '고정'되는 경우를 보았습니다. VM에서 '재설정'을 수행 한 다음 시스템 로그를 검색하면 동작이 변경 될 수 있습니다. 로그는 첫 번째 부팅이 아닌 두 번째 부팅에서 온 것이어야합니다. 업데이트시 로그가 지연되는 경향이 있습니다.

확인해야 할 또 다른 사항은 인스턴스가 IP에서 응답하는지 확인하는 것입니다. 위의 연결이 거부 된 것 같습니다. 인스턴스가 작동하는 것처럼 들리지만 SSH가 실행 중이 아니거나 방화벽 상태이지만 인스턴스가 완전히 재부팅되었는지 확인하십시오.

또한 테스트 시스템에서 모든 포트를 열어보고 'nmap'이 표시하는 것을 볼 수 있습니다. 인스턴스에서 응답하는 다른 서비스입니다.

인스턴스 이름을 마우스 오른쪽 단추로 클릭하고 "보안 그룹 변경"을 클릭하십시오. 어느 곳에서나 포트 22까지 누구나 허용하는 보안 그룹을 확인하고이 인스턴스에 적용해야합니다.

sudo reboot nowUbuntu 14.04를 실행하는 EC2 서버에서 SSH를 통해이 문제를 겪었습니다. EC2 관리 콘솔을 사용하여 다시 재부팅 한 후 정상적으로 작동했습니다.

필자의 경우 IP의 포트 22 연결 만 허용하도록 보안 그룹을 설정했습니다. 며칠 후 ISP가 내 IP 주소를 변경 했으므로 보안 그룹을 업데이트해야합니다.

비슷한 문제가 발생하여 sudo reboot를 실행 한 후 EC2 Amazon Linux 인스턴스에 더 이상 연결할 수 없습니다 .

SSH 액세스, Amazon 관리 콘솔의 중지 / 시작 / 재부팅 명령이 나에게 아무런 결과도주지 못했습니다.

마침내 Amazon 콘솔을 통해 이미지를 생성하여 인스턴스를 다시 시작할 수있었습니다. 이미지 생성 프로세스가 인스턴스 상태를 수정하는 것 같습니다.

그것이 도움이되기를 바랍니다.)

바닐라 sudo reboot명령 을 실행 한 후에도 같은 문제가 발생했습니다 . AWS 콘솔을 사용하여 AMI를 완전히 중지 (재부팅하지 않음) 한 다음 다시 시작하여 문제를 해결할 수 있음을 발견했습니다.

어떤 이유로 든 인스턴스를 중지했다가 다시 시작하는 대신 다시 시작 동작을 클릭 할 때와 같이 AWS 콘솔에서 AMI를 다시 시작해도 문제가 해결 되지 않았습니다 .

언급했듯이 / etc / fstab /

나는이 문제가 있었다. 먼저 경고 메시지와 같이 / dev / sda1에 볼륨을 다시 추가해야합니다.

그런 다음 ssh 수 없습니다. 나는 내가 만든 다른 볼륨을 추가해야하고 ssh 문제를 해결해야한다는 것을 깨달았습니다.

그런 다음 fstab을 다시 로그인하여 원본으로 수정할 수 있습니다.