EC2 인스턴스에 액세스하려고 할 때 시간 초과의 가능한 이유

내 인스턴스에 SSH를 사용할 수 없습니다. 작업 시간이 초과되었습니다. 그 이유는 무엇이며 해결하려면 어떻게해야합니까? 재부팅은 일반적으로 적용하는 데 오랜 시간이 걸리며 상황을 악화시킬 수 있습니다.

업데이트 : 권한에 관한 것이 아닙니다. 정상적으로 로그인 할 수 있습니다. 기억력 문제 때문인 것 같습니다

인스턴스에 적절한 보안 그룹을 설정 했습니까? 즉, 네트워크에서 인스턴스의 포트 22 로의 액세스를 허용하는 것입니다. (기본적으로 모든 트래픽이 허용되지 않습니다.)

업데이트 : 보안 그룹 문제가 아닙니다. 그러나 동일한 AMI에서 다른 인스턴스를 시작하고 이에 액세스하려고하면 문제가 지속됩니까? 이 특정 EC2 인스턴스가 어떤 식 으로든 무작위로 실패했을 수 있습니다. 그런 일이 발생하는 것은 시간 문제 일뿐입니다. (권장 자료 : Architecting for the Cloud : Best Practices (PDF), Amazon의 웹 서비스 전도사 인 Jinesh Varia의 논문. 특히 "Design for failure and nothing will fail"섹션을 참조하십시오.)

나는 같은 문제가 있었고 해결책은 내 로컬 컴퓨터의 IP를 활성 보안 그룹의 인바운드 규칙 목록에 추가하는 것이 었습니다. 아래 인바운드 대화 상자에서 포트 범위에 22를 입력 하고 소스 필드에 로컬 IP / 32를 입력하고 드롭 다운에 'custom tcp rule'을 남겨 둡니다.

파괴하고 새로 만들기

연결할 수있는 가용성 영역과 연결할 수없는 영역이 있습니다. 몇 시간 후 너무 답답해서 해당 가용성 영역의 모든 항목을 삭제했습니다.

모든 것을 다시 구축하기 위해 모든 것을 만들어야했습니다. 여기에는 다음이 포함됩니다.

• VPC 생성
  • CIDR: 10.0.0.0/24
• 인터넷 게이트웨이 생성
• 인터넷 게이트웨이 를 VPC에 연결
• 라우팅 테이블 생성
• 추가 항로 에 라우팅 테이블
  • Destination: 0.0.0.0/0
  • Target: <Internet Gateway from earlier>
• 서브넷 생성
  • CIDR: 10.0.0.0/24
  • Routing Table: <Routing Table from earlier

이 모든 것을 얻으려면 많은 것을 더듬어 야했습니다. 가장 효율적이라고 생각하는 방식으로 단계를 주문했지만 다음 항목에 사용할 수있는 항목을 얻으려면 단계를 조정해야 할 수도 있습니다.

암시

나는 당신이 나처럼 열핵을 사용하라고 제안하는 것이 아닙니다. 이 모든 정보를 제공하여 이러한 연결이 적절한 지 확인할 수 있도록합니다.

이 대답은 나 같은 어리석은 사람들을위한 것입니다. EC2의 퍼블릭 DNS는 다시 시작될 때 변경 될 수 있습니다. 이를 인식하지 못하고 기존 공용 DNS에 SSH를 시도하면 연결이 중단되고 시간이 초과됩니다. 이로 인해 EC2 또는 보안 그룹에 문제가 있다고 가정하거나 ... 아니요, 새 DNS에 SSH로 연결하면됩니다. ~/.ssh/config필요한 경우 파일을 업데이트하십시오 !

연결하려면 다음과 같이 ssh를 사용하십시오.

ssh -i keyname.pem username@xxx.xx.xxx.xx

keyname.pem개인 키의 이름은 어디에 있습니까? usernameOS 배포에 대한 올바른 사용자 이름 xxx.xx.xxx.xx은 공용 IP 주소입니다.

시간이 초과되거나 실패하면 다음을 확인하십시오.

보안 그룹

tcp 포트 22 및 모든 ip 또는 ip에 대한 인바운드 규칙이 있는지 확인하십시오 . 인스턴스 옵션의 ec2 메뉴를 통해 보안 그룹을 찾을 수 있습니다.

라우팅 테이블

vpc의 새 서브넷의 경우 0.0.0.0/0이 인터넷 게이트웨이 target 을 가리키는 라우팅 테이블로 변경해야합니다 . vpc에서 서브넷을 만들 때 기본적으로 인터넷에서 들어오는 트래픽을 허용하지 않는 기본 라우팅 테이블을 할당합니다. vpc 메뉴에서 라우팅 테이블 옵션을 편집 한 다음 서브넷을 편집 할 수 있습니다.

탄력적 IP

vpc의 인스턴스의 경우 퍼블릭 탄력적 IP 주소 를 할당하고 이를 인스턴스와 연결해야합니다. 사설 IP 주소는 외부에서 접근 할 수 없습니다. ec2 메뉴 (인스턴스 메뉴 아님)에서 탄력적 IP를 얻을 수 있습니다.

사용자 이름

올바른 사용자 이름을 사용하고 있는지 확인하세요 . ec2-user또는 root또는 중 하나 여야합니다 ubuntu. 필요한 경우 모두 시도해보십시오.

개인 키

올바른 프라이빗 키 (인스턴스를 시작할 때 다운로드하거나 선택하는 키)를 사용하고 있는지 확인합니다 . 당연한 것 같지만 복사 붙여 넣기가 두 번 나왔습니다.

인스턴스의 콘솔 출력을 보셨습니까? AWS 콘솔을 통해이 작업을 수행 할 수 있습니다 (인스턴스-> 인스턴스를 마우스 오른쪽 버튼으로 클릭-> 시스템 로그 가져 오기). EC2 인스턴스의 네트워크 서비스가 올바르게 시작되지 않아 SSH 연결 시간이 초과되는 경우가있었습니다. 인스턴스를 다시 시작하면 일반적으로 문제가 해결되었습니다.

2 시간 후 나는 이것을 발견했다

참고로 ssh ip 120.138.105.251/32

• aws 인스턴스 IP 주소가 아닙니다.

• 그것은 당신의 지역 IP가 아닙니다 127.0.0.1

• 그것은 당신의 지역 IP가 아닙니다 localhost

그러나 그러나

그것의 당신의 당신의 공용 IP 주소를 개인 컴퓨터가 있는 당신은 액세스 AWS 인스턴스에 노력

1. 이동 https://www.whatismyip.com/ 에서 어떤 IP 주소를 넣어 SSH

모든 IP 주소에 대해 SSH를 완전히 열려면

이것이 바로 접근 가능한 항목의 모양입니다. 기본 권장 사항입니다.

이것이 제가 생산에서 사용하고있는 것입니다.

다음은 가능한 문제입니다.

• 가장 가능성이 높은 것은 보안 그룹이 포트 22에서 SSH 액세스를 ip에 제공하도록 제대로 구성되지 않았기 때문입니다. 보안 설정 변경은 서버를 다시 시작할 필요가 없습니다. 응용할 수 있는.

• 로컬 방화벽 구성이 서버에 대한 SSH 액세스를 허용하지 않습니다. (다른 인터넷 연결, 휴대폰 / 동글을 사용해보십시오)

• 서버가 제대로 시작되지 않은 경우 (Amazon 콘솔에서도 액세스 확인이 실패 함),이 경우 서버를 중지하고 시작해야합니다.

AWS 문서에서이 도움말 페이지를 확인하십시오.

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectionTimeout 여기에서 솔루션을 찾을 수 있습니다. 나를 위해이 부분이 수정했습니다.

[EC2-VPC] 서브넷의 라우팅 테이블을 확인합니다. VPC 외부로 향하는 모든 트래픽을 VPC의 인터넷 게이트웨이로 보내는 경로가 필요합니다.

• https://console.aws.amazon.com/vpc/ 에서 Amazon VPC 콘솔을 엽니 다 .

• 탐색 창에서 인터넷 게이트웨이를 선택합니다. VPC에 연결된 인터넷 게이트웨이가 있는지 확인합니다. 그렇지 않으면 인터넷 게이트웨이 생성을 선택하고 지침에 따라 인터넷 게이트웨이를 생성하고 인터넷 게이트웨이를 선택한 다음 VPC에 연결을 선택하고 지침에 따라 VPC에 연결합니다.

• 탐색 창에서 서브넷을 선택한 다음 서브넷을 선택합니다.

• 라우팅 테이블 탭에서 대상이 0.0.0.0/0이고 대상이 VPC에 대한 인터넷 게이트웨이 인 경로가 있는지 확인합니다. 그렇지 않으면 라우팅 테이블의 ID (rtb-xxxxxxxx)를 선택하여 라우팅 테이블의 라우팅 탭으로 이동하고 편집, 다른 라우팅 추가를 선택하고 대상에 0.0.0.0/0을 입력하고 대상에서 인터넷 게이트웨이를 선택한 다음 저장을 선택합니다.

그러나 위의 링크에서 다루는 모든 옵션을 확인하는 것이 좋습니다. 거기에서 하나 이상의 문제를 찾을 수 있습니다.

내 문제- "내 IP"에 대해 포트 22가 열려 있고 인터넷 연결 및 IP 주소 변경이 발생했습니다. 그래서 그것을 다시 바꿔야했습니다.

오프 구축 @ted.strauss의 대답을 선택할 수 있습니다 SSH및 MyIP대신 타사 사이트로 이동의 드롭 다운 메뉴에서.

규칙을 적용한 후 Ec2 인스턴스를 재부팅하면됩니다.

ufw에서 ssh 및 포트 22를 허용 한 다음 활성화하고 상태 명령으로 확인합니다.

sudo ufw allow ssh
sudo ufw allow 22
sudo ufw enable
sudo ufw status

또 하나의 가능성. AWS 보안 그룹은 특정 수신 IP 주소에서만 작동하도록 설정되어 있습니다. 이러한 방식으로 보안 그룹이 설정된 경우 사용자 (또는 계정 소유자)는 보안 그룹에 IP 주소를 추가해야합니다. 이렇게하려면 AWS 대시 보드를 열고 보안 그룹을 선택하고 보안 그룹을 선택한 다음 인바운드 탭을 클릭합니다. 그런 다음 적절하게 IP를 추가하십시오.

나는 같은 문제가 있었고 해결책은 어디에서나 활성 보안 그룹의 인바운드 규칙 목록에 대한 액세스를 허용하는 것이 었습니다. 인바운드 대화 상자에서, 포트 범위에 22를 입력 어디서든 소스 필드에, 그리고 드롭 다운에서 'SSH'를 선택합니다.

추신 : 이것은이 인스턴스가 모든 시스템에서 ssh'ed 될 수 있음을 의미하므로 권장되는 솔루션이 아닐 수 있지만 내 로컬 IP와 함께 작동하지 못했습니다.

비밀번호가없는 공용 Wi-Fi를 사용할 때도 비슷한 문제가 발생했습니다. 인터넷 연결을 보안 연결로 전환하면 문제가 해결되었습니다.

SSH 액세스가 EC2 인스턴스에 대해 작동하지 않는 경우 다음을 확인해야합니다.

• 인스턴스의 보안 그룹 이 인바운드 SSH 액세스를 허용하고 있습니다 (확인 : 규칙보기 ).

VPC 인스턴스를 사용하는 경우 (인스턴스에 VPC ID 와 서브넷 ID가 연결되어 있음) 다음을 확인하십시오.

1. VPC 대시 보드에서 VPC에 연결된 사용 된 서브넷 ID를 찾습니다.
2. 0.0.0.0/0대상으로, 인터넷 게이트웨이 를 대상 으로 해야하는 첨부 된 라우팅 테이블 을 확인하십시오 .

리눅스에, 당신은 또한에 경로 정보를 확인 할 수 있습니다 시스템 로그 에 네트워킹 인스턴스, 예를 들면의 :

++++++++++++++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++++++++++++++
+--------+------+------------------------------+---------------+-------+-------------------+
| Device |  Up  |           Address            |      Mask     | Scope |     Hw-Address    |
+--------+------+------------------------------+---------------+-------+-------------------+
|   lo   | True |          127.0.0.1           |   255.0.0.0   |   .   |         .         |
|  eth0  | True |         172.30.2.226         | 255.255.255.0 |   .   | 0a:70:f3:2f:82:23 |
+--------+------+------------------------------+---------------+-------+-------------------+
++++++++++++++++++++++++++++Route IPv4 info+++++++++++++++++++++++++++++
+-------+-------------+------------+---------------+-----------+-------+
| Route | Destination |  Gateway   |    Genmask    | Interface | Flags |
+-------+-------------+------------+---------------+-----------+-------+
|   0   |   0.0.0.0   | 172.30.2.1 |    0.0.0.0    |    eth0   |   UG  |
|   1   |   10.0.3.0  |  0.0.0.0   | 255.255.255.0 |   lxcbr0  |   U   |
|   2   |  172.30.2.0 |  0.0.0.0   | 255.255.255.0 |    eth0   |   U   |
+-------+-------------+------------+---------------+-----------+-------+

여기서 UG당신에게 당신의 인터넷 게이트웨이를 나타내는 플래그.

자세한 내용 은 Amazon 문서에서 인스턴스 연결 문제 해결을 참조하십시오 .

VPC 서브넷의 인스턴스에 대해 인터넷에서 SSH 액세스를 활성화하려면 다음을 수행하십시오.

• 인터넷 게이트웨이를 VPC에 연결합니다.
• 서브넷의 라우팅 테이블이 인터넷 게이트웨이를 가리키는 지 확인합니다.
• 서브넷의 인스턴스에 전역 적으로 고유 한 IP 주소 (퍼블릭 IPv4 주소, 탄력적 IP 주소 또는 IPv6 주소)가 있는지 확인합니다.
• 네트워크 액세스 제어 (VPC 수준) 및 보안 그룹 규칙 (ec2 수준)이 관련 트래픽이 인스턴스를 오가는 것을 허용하는지 확인합니다. 네트워크 공용 IP 주소가 둘 다에 대해 활성화되어 있는지 확인하십시오. 기본적으로 Network AcL은 명시 적으로 구성된 경우를 제외하고 모든 인바운드 및 아웃 바운드 트래픽을 허용합니다.

저에게는 EC2 인스턴스 자체가 아니라 t2.micro Linux EC2 인스턴스에서 호스팅되는 Apache 서버였습니다.

다음과 같이 수정했습니다.

sudo su

service httpd restart

나는 같은 문제가 있었고 보안 그룹에 규칙을 추가하여 해결했습니다.

인바운드 SSH 0.0.0.0/0

또는 IP 주소 만 추가 할 수 있습니다.

저에게는 부팅 볼륨에서 모든 것을 삭제했습니다. 더 이상 인스턴스에 연결할 수 없습니다.

나는 인스턴스에서 작업하고 있었고 다음날 내 인스턴스에 SSH를 시도했을 때 연결 시간 초과라고 말했습니다.

이 게시물을 살펴 보려고했지만 아무것도 작동하지 않았습니다. 그래서 나는-

온 Edit inbound rules에서 소스 열을 선택 MY IP하고 자동으로 CIDR 형식으로 공개 IP 주소를 채 웁니다 ( XXX.XXX.XXX.XX/32).

로컬 IP를 제공하여 @ ted.strauss 답변을 시도했지만 제 경우에는 도움이되지 않았습니다. 그래서 내 IP를 선택하고 작동했습니다.

이것이 누군가를 돕기를 바랍니다!

먼저 DNS를 ping합니다. 실패하면 시작 마법사에서 인바운드 / 아웃 바운드 규칙을 구성하십시오. 모든 트래픽과 모든 프로토콜을 구성하고 기본 옵션으로 저장하십시오. 로컬 시스템으로 다시 핑하면 작동합니다.

방금 새 인스턴스를 생성했는데 연결할 수없는 경우 해당 인스턴스를 종료하고 새 인스턴스를 생성하여 문제를 해결할 수있었습니다. 물론 이것은 새 인스턴스이고 더 이상 작업을 수행하지 않은 경우에만 작동합니다.