Điều gì gây ra sự cố SSH sau khi khởi động lại máy chủ 14.04?

Tại sao việc khởi động lại máy chủ chạy Ubuntu 14.04 lại cho tôi lỗi 'Kết nối bị từ chối'?

Tôi thấy ssh: connect to host <IP-address-here> port 22: Connection refusednhưng chỉ cho 14.04 và chỉ sau khi khởi động lại. Tôi đang sử dụng máy tính để bàn 12.04 tại nhà. Làm thế nào để tôi khắc phục sự cố này?

Để làm cho câu hỏi rõ ràng hơn, đây là những gì không hoặc không làm việc cho tôi:

• SSH vào bản cài đặt mới 12.04> đăng xuất> SSH vào lại> hoạt động
• SSH vào bản cài đặt mới 12.04> khởi động lại> SSH vào lại> hoạt động
• SSH vào bản cài đặt mới 14.04> đăng xuất> SSH vào lại> hoạt động
• SSH vào bản cài đặt mới 14.04> khởi động lại> SSH vào lại> Kết nối bị từ chối

Vấn đề tôi gặp phải là duy nhất đến 14.04 và chỉ xảy ra sau khi khởi động lại. Tôi có một số máy chủ chạy 12.04 trước đó và mọi thứ vẫn hoạt động hoàn hảo. Tôi đã có một máy chủ mới mà tôi muốn sử dụng vào 14.04 và tôi muốn hiểu điều gì đang xảy ra. Bất kỳ đề xuất?

Đây là những gì tôi đã thử cho đến nay:

sudo traceroute -p 22 -T <IP-address-here>

Traceroute hoạt động tốt, tôi nhận được phản hồi từ máy chủ trên cổng SSH 22.

initctl list
...
ssh start/running, process 23371
...

Có vẻ như ssh trên máy chủ 14.04 được thiết lập để bắt đầu khi khởi động (như mong đợi).

tom@Desktop:~$ ssh -vvv root@<IP-address-here>
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to <IP-address-here> [<IP-address-here>] port 22.
debug1: connect to address <IP-address-here> port 22: Connection refused
ssh: connect to host <IP-address-here> port 22: Connection refused

Chỉnh sửa: Đây là toàn bộ nhật ký hệ thống từ một máy mới được tạo . Tôi đã tạo nó, SSH'd in & ban hành reboot nowlệnh, sau đó nhận được lỗi từ chối kết nối sau khi chờ nó khởi động lại và thử SSH lần thứ hai. Khởi động lại cứng thông qua bảng điều khiển lưu trữ và bây giờ kết nối SSH hoạt động trở lại.

Câu trả lời nhanh:

SSH không phải là vấn đề. Lệnh bạn sử dụng để khởi động lại là vấn đề: không làm reboot now, làm reboothoặc shutdown -r nowkhởi động lại hệ thống của bạn.

Cú pháp lệnh ( kể từ ngày 13.04 ) là:

reboot [OPTION]...  [REBOOTCOMMAND]

Điều REBOOTCOMMANDchưa từng tồn tại trước đây. Vào ngày 12.04, bạn nowđã bị bỏ qua nhưng giờ nó đang được sử dụng ... Và nó phá vỡ mọi thứ.

Câu trả lời dài, với kết quả kiểm tra và giải thích của tôi:

Tôi gặp vấn đề tương tự với một số máy chủ chạy 14.04 VÀ trong VPS (được lưu trữ tại nhà cung cấp OVH của Pháp - chạy OpenVZ) VÀ khi thực hiện reboot nowbên trong máy chủ.

Giống như bạn, tôi đã ban hành lệnh reboot nowtừ bảng điều khiển (đăng nhập bằng SSH). Một vài giây sau khi tôi nhấn RETURN, phiên của tôi sẽ tự động bị ngắt kết nối. Giống như bạn, tôi chưa bao giờ có thể kết nối lại với máy chủ thông qua SSH sau khi ban hành lệnh này.

Vì vậy, tôi quyết định mở bảng điều khiển KVM do OVH cung cấp. (mô phỏng truy cập trực tiếp bằng bàn phím và màn hình trên máy chủ vật lý cho loại máy chủ ảo này).

Tôi đã có thể kết nối với máy của mình và tôi thấy rằng cô ấy đang vào Chế độ người dùng đơn, chờ tôi nhấn CTRL+ Dđể tiếp tục hoặc nhập mật khẩu gốc để chuyển sang chế độ bảo trì. Tôi nhấn tổ hợp phím để tiếp tục quá trình và sau đó có thể SSH vào hệ thống của tôi một lần nữa. Điều đáng ngạc nhiên của tôi là, sau khi chạy uptime, thời gian hoạt động không phải là 2 hay 3 phút mà là rất nhiều ngày: được reboot nowthực hiện bên trong VPS Ubuntu 14.04 không thực sự khởi động lại mà chỉ yêu cầu chuyển sang chế độ Người dùng đơn!

Từ điều này, tôi đã học được cách không bao giờ yêu cầu khởi động lại từ trong VPS của mình mà chỉ yêu cầu nó từ lệnh được cung cấp trên giao diện quản lý của hoster.

Do đó, không có vấn đề với cài đặt SSH của bạn. Vấn đề là khi bạn gõ reboot now. Trên thực tế, tôi cũng đã thử nó sau đó, nếu bạn đã gõ reboot(chỉ từ, không có tùy chọn), nó sẽ thực hiện những gì bạn định làm: khởi động lại máy chủ.

Sử dụng rebootvới một đối số (từ trang man) gọi lệnh shutdownvới các đối số đã cho. Và thực tế, nếu tôi thực thi shutdown now, tôi có hành vi tương tự: hệ thống không được khởi động lại, nó sẽ chuyển sang chế độ người dùng.

Lưu ý: có vẻ như đó là hành vi dự định khi thông báo xuất hiện trên màn hình sau khi thực thi lệnh này có nội dung như sau:

Hệ thống sẽ được đưa đến chế độ bảo trì

Chế độ bảo trì hoặc chế độ người dùng đơn, điều này thể hiện giống nhau, một runlevel có ghi chú nhiều hơn vỏ, không mạng, không xử lý mạng, ...

Điều này có thể gây nhầm lẫn, nhưng lưu ý rằng việc sử dụng chính xác shutdownlà, ví dụ: shutdown -h nowtạm dừng hệ thống ngay bây giờ hoặc shutdown -r nowkhởi động lại nó ngay bây giờ. Tôi không biết rằng shutdown nowsẽ chỉ đưa hệ thống vào chế độ người dùng. Tôi thường làm init Sđể đạt được điều này.

Tôi có thể bị trễ và điều đó có thể rõ ràng, nhưng điều làm việc với tôi là kiểm tra tệp cấu hình /etc/ssh/sshd_config: chạy daemon với /etc/init.d/ssh starthoặc bất kỳ sự kết hợp nào khác cho thấy dịch vụ đang chạy ngay cả khi nó không hoạt động, nhưng nếu tôi khởi chạy chương trình thực thi với đường dẫn tuyệt đối của nó (trong trường hợp của tôi /usr/sbin/sshd) Tôi thấy rằng có một "0B" được thêm vào cuối tệp cấu hình gây ra lỗi khi bắt đầu, loại bỏ nó đã giải quyết vấn đề.

Một nguyên nhân tiềm năng khác là ufwmất cấu hình quy tắc cổng SSH. Điều này đã xảy ra với tôi trong ít nhất một hoặc hai lần, trong đó sau khi áp dụng các bản cập nhật và khởi động lại, cấu hình tường lửa đã chặn tôi truy cập vào máy chủ. Sử dụng thiết bị bảng điều khiển VPS của nhà cung cấp dịch vụ lưu trữ của tôi cho phép tôi truy cập vào máy và chẩn đoán sự cố. Ví dụ dưới đây cho thấy vấn đề (tức là không có mục nào cho cổng 22):

user@host:~$ sudo ufw status verbose
[sudo] password for user:
Status: active
Logging: on (low)
    Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
80,443/tcp (Nginx Full)    ALLOW IN    Anywhere
25/tcp                     ALLOW IN    Anywhere
143                        ALLOW IN    Anywhere
110                        ALLOW IN    Anywhere
993/tcp (Dovecot Secure IMAP) ALLOW IN    Anywhere
995/tcp (Dovecot Secure POP3) ALLOW IN    Anywhere
25/tcp (Postfix)           ALLOW IN    Anywhere
465/tcp (Postfix SMTPS)    ALLOW IN    Anywhere
80,443/tcp (Nginx Full (v6)) ALLOW IN    Anywhere (v6)
25/tcp (v6)                ALLOW IN    Anywhere (v6)
143 (v6)                   ALLOW IN    Anywhere (v6)
110 (v6)                   ALLOW IN    Anywhere (v6)
993/tcp (Dovecot Secure IMAP (v6)) ALLOW IN    Anywhere (v6)
995/tcp (Dovecot Secure POP3 (v6)) ALLOW IN    Anywhere (v6)
25/tcp (Postfix (v6))      ALLOW IN    Anywhere (v6)
465/tcp (Postfix SMTPS (v6)) ALLOW IN    Anywhere (v6)

Kích hoạt lại cổng như sau thực hiện thủ thuật:

user@host:~$ sudo ufw allow ssh
Rule added
Rule added (v6)

Đối với hệ thống của tôi, vấn đề là tập lệnh init ssh /etc/init.d/sshlà người duy nhất kiểm tra sự hiện diện của phiên bản init mới nhất.

Vì vậy, /etc/init.d/sshkhông bắt đầu ssh,bởi vì nó tin rằng nó sẽ được bắt đầu bởi upstart.

Trong trường hợp của tôi, khởi động không bắt đầu vì cấu hình cụ thể của tôi:

Có một cấu hình chính xác /etc/init/ssh.conf, nhưng cũng có một /etc/init/ssh.overridetệp chứa manual, có nghĩa sshlà dự kiến ​​sẽ được bắt đầu bằng tay.

Tập tin này được tạo bởi get-remnux.shtập lệnh cài đặt.

Bắt đầu bằng tay, hoặc loại bỏ các /etc/init/ssh.overridetập tin giải quyết vấn đề.