SSH Server ngừng hoạt động sau khi khởi động lại, do thiếu / var / run / sshd


23

VPS của tôi đã không được khởi động lại trong khoảng 3 tháng. Nó được lưu trữ trên một máy chủ với loại ảo hóa OpenVZ và hệ điều hành là Ubuntu 16.04. Vì một số lý do, tôi đã khởi động lại VPS và sau đó, tôi không thể kết nối với máy chủ thông qua ssh, thông báo mà tôi nhận được là:

ssh: connect to host srvname.com port 22: Connection refused

Vì vậy, tôi đã mở một Bảng điều khiển nối tiếp trên VPS và bắt đầu điều tra ... Tôi đã thanh trừng và cài đặt lại nhưng openssh-serverkhông thành công. Tôi đã dành hai giờ để đọc các bài báo, câu hỏi và câu trả lời về các vấn đề tương tự trên Internet.

Cuối cùng tôi cũng hiểu rằng thư mục /var/run/sshdkhông được tạo trong quá trình khởi động hệ thống. Và một khi tôi tạo nó bằng tay, tôi có thể khởi động dịch vụ SSH mà không gặp vấn đề gì, nhưng trong lần khởi động lại tiếp theo, vấn đề vẫn còn. Vì vậy, câu hỏi của tôi là:

  • Điều gì có thể là nguyên nhân của vấn đề này? Tại sao /var/run/sshdkhông được tạo trong quá trình khởi động hệ thống?

  • Làm thế nào tôi có thể giải quyết vấn đề một cách thích hợp? Tôi tìm thấy một giải pháp tạm thời được đề cập ở cuối bài này.

  • Sự cố có thể liên quan đến máy chủ OpenVZ của VPS không? Tôi có nên yêu cầu nhà cung cấp dịch vụ lưu trữ để giải quyết nó?


Đầu ra của systemctl status ssh.service, sshd -Ddp 22journalctl -xelà:

# systemctl status ssh.service
 ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: failed (Result: start-limit-hit) since вт 2019-01-15 12:58:08 EET; 22s ago
  Process: 407 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255)

яну 15 12:58:07 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
яну 15 12:58:07 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 12:58:07 srvname systemd[1]: ssh.service: Failed with result 'exit-code'.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
яну 15 12:58:08 srvname systemd[1]: Stopped OpenBSD Secure Shell server.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Start request repeated too quickly.
яну 15 12:58:08 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 12:58:08 srvname systemd[1]: ssh.service: Failed with result 'start-limit-hit'.


# $(which sshd) -Ddp 22
debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: private host key #0: ssh-rsa SHA256:...
debug1: private host key #1: ssh-dss SHA256:...
debug1: private host key #2: ecdsa-sha2-nistp256 SHA256:...
debug1: private host key #3: ssh-ed25519 SHA256:...
Missing privilege separation directory: /var/run/sshd


# journalctl -xe
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has begun starting up.
яну 15 13:21:21 srvname sshd[1688]: Missing privilege separation directory: /var/run/sshd
яну 15 13:21:21 srvname systemd[1]: ssh.service: Control process exited, code=exited status=255
яну 15 13:21:21 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has failed.
-- 
-- The result is failed.
яну 15 13:21:21 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 13:21:21 srvname systemd[1]: ssh.service: Failed with result 'exit-code'.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
яну 15 13:21:22 srvname systemd[1]: Stopped OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has finished shutting down.
яну 15 13:21:22 srvname systemd[1]: Starting OpenBSD Secure Shell server...
-- Subject: Unit ssh.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has begun starting up.
яну 15 13:21:22 srvname sshd[1691]: Missing privilege separation directory: /var/run/sshd
яну 15 13:21:22 srvname systemd[1]: ssh.service: Control process exited, code=exited status=255
яну 15 13:21:22 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has failed.
-- 
-- The result is failed.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Failed with result 'exit-code'.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
яну 15 13:21:22 srvname systemd[1]: Stopped OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has finished shutting down.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Start request repeated too quickly.
яну 15 13:21:22 srvname systemd[1]: Failed to start OpenBSD Secure Shell server.
-- Subject: Unit ssh.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ssh.service has failed.
-- 
-- The result is failed.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Unit entered failed state.
яну 15 13:21:22 srvname systemd[1]: ssh.service: Failed with result 'start-limit-hit'.

Nội dung của /usr/lib/tmpfiles.d/sshd.conf/etc/init/ssh.conflà:

# cat /usr/lib/tmpfiles.d/sshd.conf 
d /var/run/sshd 0755 root root

# cat /etc/init/ssh.conf | sed '/^#/ d'

description "OpenSSH server"

start on runlevel [2345]
stop on runlevel [!2345]

respawn
respawn limit 10 5
umask 022

env SSH_SIGSTOP=1
expect stop

console none

pre-start script
    test -x /usr/sbin/sshd || { stop; exit 0; }
    test -e /etc/ssh/sshd_not_to_be_run && { stop; exit 0; }

    mkdir -p -m0755 /var/run/sshd
end script

exec /usr/sbin/sshd -D

Thông tin bổ sung về hệ thống:

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.5 LTS
Release:    16.04
Codename:   xenial

# uname -a
Linux srvname 2.6.32-042stab127.2 #1 SMP Thu Jan 4 16:41:44 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux

# apt show openssh-server | grep 'Version'
Version: 1:7.2p2-4ubuntu2.6

Giải pháp tạm thời: Tôi thấy đó /var/runlà một liên kết tượng trưng /run, tôi không biết tại sao điều này lại cần thiết, nhưng khi tôi sửa đổi nội dung của tệp /usr/lib/tmpfiles.d/sshd.conftừ:

d /var/run/sshd 0755 root root

đến:

d /run/sshd 0755 root root

mọi thứ đều ổn khi khởi động hệ thống, dịch vụ SSH được khởi động bình thường và tôi có thể đăng nhập thông qua SSH.


Vấn đề này có thể đột nhiên xuất hiện sau khi khởi động lại do nâng cấp phiên bản đã được thực hiện ngay trước lần khởi động lại đó, như được mô tả trong câu hỏi được liên kết này . Bài học: không nâng cấp trừ khi bạn chắc chắn rằng kernel của bạn có thể hỗ trợ nó.
Tuyết

Câu trả lời:


24

Tôi thấy đây là một lỗi với phiên bản hiện tại của systemd và kernel cũ được sử dụng bởi một số nhân viên VPS như trong trường hợp của tôi. Lỗi này xuất hiện theo thời gian, như chúng ta có thể thấy trên Launchpad: Bug # 45234 , Bug # 1811580 ; hoặc trên ServerFault: Tại sao tôi thiếu / var / run / sshd sau mỗi lần khởi động?

Có một vài cách giải quyết vấn đề này, tất cả đều kết hợp với cách khác để tạo /var/run/sshdtrước khi chạy máy chủ SSH. Dưới đây là ba giải pháp có thể.


Cách giải quyết 1: Sửa đổi /usr/lib/tmpfiles.d/sshd.conftheo cách sau:

d /run/sshd 0755 root root

Như đã đề cập trong câu hỏi, /var/runlà một liên kết tượng trưng cho /run, kết quả cuối cùng là giống hệt nhau: /var/run/sshdđược tạo ra. Tôi không biết tại sao, nhưng điều này hoạt động.


Giải pháp 2: Sử dụng công việc Cron sẽ tạo /var/run/sshdvà khởi động lại máy chủ SSH, bạn có thể sử dụng root crontabcho mục đích này - thực hiện sudo crontab -evà thêm mục sau:

@reboot mkdir -p -m0755 /var/run/sshd && systemctl restart ssh.service

Hiện tại tôi đang sử dụng giải pháp này, vì vậy nó cũng đã được thử nghiệm.


Giải pháp 3: Sử dụng /etc/rc.localđể làm tương tự như trên, như được thể hiện trong nhận xét này về báo cáo lỗi # 45234.


1
Cảm ơn, đã sửa lỗi ssh nhưng không phải là vấn đề rộng hơn của systemd bị hỏng. Hãy thử chạy systemd-tmpfiles - tạo và xem tất cả các lỗi
paulzag

1
Bạn nói đúng, @paulzag, nhưng trong trường hợp của tôi, tôi chắc chắn rằng vấn đề chung là hạt nhân cũ. Tôi quyết định bỏ qua những lỗi này systemd-tmpfiles --createcho thấy, bởi vì hiện tại không có bất kỳ trục trặc hợp lý nào trên máy chủ. Nói chung, Câu hỏi hiện tại là về cách vận hành dịch vụ SSH sau khi khởi động lại trong khi sự cố được khắc phục. Nếu bạn muốn bạn có thể nâng cấp giải pháp :)
pa4080

"Workaround 1" đã làm việc cho tôi ... Cảm ơn ... Đã bỏ phiếu ...
Biswadeep Sarkar

2
Thay vào đó sẽ /usr/lib/tmpfiles.d/sshd.conf đúng hơn là ghi đè thay vì sửa đổi trực tiếp, vì tệp đó được quản lý bởi gói. Để làm như vậy, chỉ cần thực hiện thay đổi trong /etc/tmpfiles.d/sshd.conf; điều này sẽ được ưu tiên hơn sshd.conftrong /usr/lib. Xem phần này trong tmpfiles.d (5) . Câu trả lời tuyệt vời bất kể, trên VPS OpenVZ chính xác là tình huống tôi gặp phải điều này.
ZeroKnight

1
Về lý do tại sao Workaround 1 hoạt động; bạn đang tránh sử dụng /var/runsymlink, đây là systemd-tmpfilesvấn đề đang xảy ra và tại sao thư mục PrivSep không được tạo. Thông điệp cuối cùng thứ 4 của chủ đề này làm sáng tỏ điều này. Cấp, nó liên quan systemd-tmpfiles-clean, nhưng tôi có cảm giác điều tương tự áp dụng ở đây.
ZeroKnight

1

Bạn có thể kiểm tra xem các quyền /(hệ thống tập tin gốc) của bạn không bị thay đổi không? Phải root:rootgiống như hai dòng dưới đây:

drwxr-xr-x  25 root root      4096 дек 21 06:45 ..
drwxr-xr-x  25 root root      4096 дек 21 06:45 .

Nếu chủ sở hữu là một người dùng khác (và không phải root), điều này sẽ ngăn việc tạo tất cả các tệp tạm thời bằng systemd trong khi khởi động hệ thống. Bạn cũng có thể kiểm tra bằng lệnh:

systemd-tmpfiles --create

Nếu thư mục gốc ( /) có quyền khác, vui lòng thay đổi nó bằng lệnh sau:

chown root: /

0

Cảm ơn mọi người vì thông tin hữu ích. Vấn đề với ssh-server trên Xenial Lubfox của tôi thực sự liên quan đến quyền sở hữu '/' theo đề xuất của Melebius & Stefan. Tạm thời
tạo /var/run/sshdvà khởi động lại ssh.service tạm thời ssh-server. Chỉnh sửa sshd.confkhông giúp được gì trong hệ thống này. Sau đó làm theo gợi ý cuối cùng, tôi đã kiểm tra quyền sở hữu thư mục gốc bằng:

' ls -alF /' Và chắc chắn, nó đã vô tình được thay đổi thành người dùng / nhóm người địa phương. Phát hành từ thiết bị đầu cuối: ' sudo chown root:root /' đã sửa hệ thống của tôi, bất kể chỉnh sửa thành sshd.conf. Vì vậy, tôi đã khôi phục nó về trạng thái ban đầu của nó, tức là d /var/run/sshd 0755 root root.


0

Tôi gặp vấn đề này trên máy của mình khi tôi đang chạy nhiều phiên bản sshd trên một máy (18.04.02 LTS, OpenSSH 7.6p1).

Vấn đề là không có công tắc nào trong sshd (tức là dòng lệnh hoặc sshd_configtệp) được cung cấp để thay đổi vị trí của "thư mục phân tách đặc quyền". Thư mục phải ở trong /var/empty, theo mã nguồn OpenSSH 7.6p1.

Gói Ubuntu đã ánh xạ lại điều này /run/sshd.

Có một vấn đề "an toàn luồng" trong các init.dtập lệnh khi khởi động khi cả hai tập lệnh dịch vụ cố gắng tạo thư mục. Tôi đã yêu cầu cả Ubuntu và OpenSSH giải quyết vấn đề về tên đường dẫn "thư mục phân tách đặc quyền" được mã hóa cứng trong sshd. Nếu tôi có thể tải lên các tệp, tôi đã sửa lỗi dựa trên mã nguồn OpenSSH 8.0p1.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.