Amazon EC2 - Không có SSH sau khi khởi động lại, từ chối kết nối

Tôi đã sao chép điều này hai hoặc ba lần, vì vậy tôi đoán có điều gì đó không ổn với những gì tôi đang làm.

Đây là các bước của tôi:

1. Khởi chạy phiên bản mới thông qua bảng điều khiển Quản lý EC2 bằng cách sử dụng: Ubuntu Server 13.10 - ami-ace67f9c (64-bit)
2. Khởi chạy với mặc định (sử dụng cặp khóa hiện tại của tôi)
3. Ví dụ bắt đầu. Tôi có thể SSH tới nó bằng cách sử dụng Putty hoặc thiết bị đầu cuối Mac. Sự thành công!
4. Tôi khởi động lại ví dụ

5. 10 phút sau, khi cá thể sẽ được sao lưu và chạy, kết nối đầu cuối của tôi hiển thị:

   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$
   

Tốt, tôi hiểu rằng địa chỉ IP công cộng có thể thay đổi, vì vậy kiểm tra bảng điều khiển quản lý EC2, tôi xác minh rằng nó giống nhau. Kỳ dị. Để giải trí, tôi thử kết nối với tên máy chủ DNS công cộng: ec2-54-201-200-208.us-west-2.compute.amazonaws.com. Không có xúc xắc, kết quả tương tự.

Ngay cả khi sử dụng máy khách Connect qua Java SSH được tích hợp trong bảng điều khiển EC2, tôi vẫn bị từ chối kết nối.

Tôi đã kiểm tra các nhóm bảo mật. Trường hợp này là trong nhóm launch-wizard-4. Nhìn vào cấu hình gửi đến cho nhóm này, Cổng 22 được cho phép từ 0.0.0.0/0, do đó, nên ở bất cứ đâu. Tôi biết rằng tôi đang đánh cá thể của tôi và đây là nhóm bảo mật phù hợp, vì tôi không thể ping cá thể. Nếu tôi kích hoạt ICMP cho nhóm bảo mật này, tất cả các ping của tôi sẽ bất ngờ xuất hiện.

Tôi đã tìm thấy một vài bài đăng khác trên internet với thông báo lỗi tương tự, nhưng hầu hết có thể dễ dàng giải quyết bằng cách điều chỉnh cài đặt tường lửa. Tôi đã thử một vài trong số này, không có may mắn.

Tôi đoán có một bước EC2 đơn giản mà tôi đang thiếu. Cảm ơn vì bất kỳ sự giúp đỡ nào bạn có thể cung cấp và tôi rất vui được cung cấp thêm thông tin hoặc kiểm tra thêm!

Cập nhật - Dưới đây là nhật ký hệ thống của tôi từ bảng điều khiển Amazon EC2: http://pastebin.com/4M5pwGRt

Hôm nay có một hành vi tương tự trên ví dụ ec2 của tôi và đã theo dõi điều này: khi tôi làm sudo reboot now máy bị treo và tôi phải khởi động lại nó một cách thủ công từ bảng điều khiển quản lý aws khi tôi sudo reboot khởi động lại tốt. Rõ ràng "ngay bây giờ" không phải là một tùy chọn hợp lệ để khởi động lại như được chỉ ra ở đây https://askubfox.com/questions/397502/reboot-a-server-from-command-line

suy nghĩ?

Từ bài đăng Diễn đàn nhà phát triển AWS về chủ đề này :

Hãy thử dừng phiên bản bị hỏng, tách âm lượng EBS và gắn nó làm âm lượng phụ cho một thể hiện khác. Khi bạn đã gắn âm lượng bị hỏng ở đâu đó trên ví dụ khác, hãy kiểm tra tệp / etc / sshd_config (gần phía dưới). Tôi đã có một vài trường hợp RHEL trong đó Yum đã vặn sshd_config chèn các dòng trùng lặp ở phía dưới khiến sshd không khởi động được do lỗi cú pháp.

Khi bạn đã sửa nó, chỉ cần ngắt âm lượng, tách ra, gắn lại vào phiên bản khác của bạn và kích hoạt lại nó.

Hãy phá vỡ điều này, với các liên kết đến tài liệu AWS:

1. Dừng phiên bản bị hỏng và tách âm lượng EBS (root) bằng cách vào Bảng điều khiển quản lý EC2, nhấp vào "Cửa hàng khối đàn hồi"> "Tập", nhấp chuột phải vào âm lượng được liên kết với phiên bản bạn đã dừng.
2. Bắt đầu một thể hiện mới trong cùng một khu vực và của cùng một hệ điều hành với thể hiện bị hỏng sau đó đính kèm âm lượng gốc EBS ban đầu như một ổ đĩa thứ cấp vào thể hiện mới của bạn . Các lệnh trong bước 4 bên dưới giả sử bạn gắn âm lượng vào thư mục có tên là "dữ liệu".
3. Khi bạn đã gắn âm lượng bị hỏng ở đâu đó vào ví dụ khác ,
4. kiểm tra tệp "/ etc / sshd_config" để biết các mục trùng lặp bằng cách ban hành các lệnh sau:
   • cd /etc/ssh
   • sudo nano sshd_config
   • ctrl-v một loạt các lần để đi đến cuối tập tin
   • ctrl-k tất cả các dòng ở dưới cùng đề cập đến "PermitRootLogin không có mật khẩu" và "UseDNS no"
   • ctrl-xvà Yđể lưu và thoát tệp đã chỉnh sửa
5. @Telegard chỉ ra (trong bình luận của anh ấy) rằng chúng tôi chỉ sửa lỗi triệu chứng. Chúng tôi có thể khắc phục nguyên nhân bằng cách nhận xét 3 dòng liên quan trong tệp "/etc/rc.local". Vì thế:
   • cd /etc
   • sudo nano rc.local
   • tìm kiếm các dòng "PermitRootLogin ..." và xóa chúng
   • ctrl-xvà Yđể lưu và thoát tệp đã chỉnh sửa
6. Khi bạn đã sửa nó, chỉ cần ngắt âm lượng ,
7. tách ra bằng cách vào Bảng điều khiển quản lý EC2, nhấp vào "Cửa hàng khối đàn hồi"> "Tập", nhấp chuột phải vào âm lượng được liên kết với phiên bản bạn đã dừng,
8. gắn lại vào trường hợp khác của bạn và
9. cháy nó trở lại một lần nữa .

Nó có thể không giúp ích gì cho tình huống này, nhưng tôi đã thấy một số trường hợp khởi động lại trên EC2 bị 'kẹt'. Nếu bạn thực hiện 'đặt lại' trên VM và sau đó truy xuất nhật ký hệ thống, nó có thể thay đổi hành vi. Hãy chắc chắn rằng các bản ghi là từ lần khởi động thứ hai chứ không phải lần đầu tiên - chúng có xu hướng bị trì hoãn trên các bản cập nhật.

Một điều khác để kiểm tra là đảm bảo rằng cá thể đó đang phản hồi trên IP. Dường như bạn nhận được một kết nối bị từ chối ở trên, có vẻ như thể hiện đã hết, nhưng SSH không chạy hoặc bị tường lửa, nhưng hãy chắc chắn rằng phiên bản đó đã được khởi động lại hoàn toàn.

Bạn cũng có thể thử mở tất cả các cổng từ một hệ thống kiểm tra và xem những gì 'nmap' hiển thị cho bạn - là bất kỳ dịch vụ nào khác phản hồi trên ví dụ.

Nhấp chuột phải vào tên dụ và nhấp vào "Thay đổi nhóm bảo mật". Đảm bảo rằng nhóm Bảo mật bạn đã tạo cho phép mọi người từ bất kỳ nơi nào đến Cổng 22 được kiểm tra và áp dụng cho trường hợp này.

Tôi gặp vấn đề này sau khi thực hiện sudo reboot nowqua SSH trên máy chủ EC2 của tôi chạy Ubuntu 14.04. Hoạt động tốt sau khi khởi động lại một lần nữa bằng Bảng điều khiển quản lý EC2.

Trong trường hợp của tôi, tôi đã thiết lập một nhóm bảo mật để chỉ cho phép kết nối cổng 22 từ IP của tôi. Vài ngày sau, ISP của tôi đã thay đổi địa chỉ IP của tôi, do đó nhóm bảo mật cần cập nhật.

Tôi gặp vấn đề tương tự, phiên bản EC2 Amazon Linux của tôi không thể truy cập được nữa sau khi chạy sudo restart .

Không có quyền truy cập SSH, các lệnh dừng / bắt đầu / khởi động lại từ bảng điều khiển quản trị viên Amazon cũng không cho tôi kết quả.

Cuối cùng tôi đã có thể khởi động lại cá thể của mình bằng cách tạo một hình ảnh thông qua bảng điều khiển Amazon. Quá trình tạo hình ảnh dường như khắc phục trạng thái cá thể.

Hy vọng nó giúp ;)

Tôi đã có vấn đề tương tự sau khi chạy một sudo rebootlệnh vanilla . Tôi thấy rằng tôi có thể giải quyết vấn đề bằng cách dừng hoàn toàn (không khởi động lại) AMI của tôi bằng bảng điều khiển AWS và sau đó khởi động lại.

Vì bất kỳ lý do gì, khởi động lại AMI từ bảng điều khiển AWS, vì khi nhấp vào hành động khởi động lại thay vì dừng lại và sau đó bắt đầu phiên bản, đã không khắc phục được sự cố.

Như đã đề cập, có lẽ bạn đã nhầm với / etc / fstab /

Tôi đã có vấn đề này. Trước tiên, bạn phải thêm lại âm lượng tại / dev / sda1 như thông báo cảnh báo nói.

Sau đó tôi không thể ssh. Tôi nhận ra rằng tôi phải thêm tập khác mà tôi đã tạo và đã khắc phục sự cố ssh.

Sau đó, bạn có thể đăng nhập và sửa lỗi fstab trở lại ban đầu.