由于缺少/ var / run / sshd,SSH服务器在重启后停止工作


23

我的VPS大约3个月没有重启。它托管在具有OpenVZ虚拟化类型的服务器上,操作系统为Ubuntu 16.04。由于某种原因,我重新启动了VPS,然后,我无法通过ssh连接到服务器,收到的消息是:

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

因此,我在VPS上打开了一个串行控制台,并开始调查...我已清除并重新安装openssh-server,但没有成功。我花了两个小时阅读有关互联网上类似问题的文章,问题和答案。

最终,我设法了解该目录/var/run/sshd不是在系统启动期间创建的。而且,一旦我手动创建它,我就可以启动SSH服务,而不会出现任何问题,但是在下次重新启动时,问题仍然存在。所以我的问题是:

  • 可能是此问题的原因?为什么/var/run/sshd在系统启动期间未创建?

  • 如何以适当的方式解决问题?我找到了本文结尾处提到的临时解决方案。

  • 问题可能与VPS的OpenVZ主机有关吗?我应该请托管服务提供商解决吗?


的输出systemctl status ssh.servicesshd -Ddp 22并且journalctl -xe是:

# 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'.

的内容/usr/lib/tmpfiles.d/sshd.conf/etc/init/ssh.conf为:

# 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

有关系统的其他信息:

# 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

临时解决方案: 我发现这/var/run是的符号链接/run,不知道为什么需要这样做,但是当我/usr/lib/tmpfiles.d/sshd.conf从以下位置修改文件内容时:

d /var/run/sshd 0755 root root

至:

d /run/sshd 0755 root root

系统启动时一切正常,SSH服务正常启动,我能够通过SSH登录。


如此链接的问题所述,由于版本升级是在重新启动之前完成的,因此重新启动后可能会突然出现此问题。这个教训:除非您确定内核可以支持,否则请不要升级。
下雪

Answers:


24

我发现这是某些VPS privdes使用的systemd和旧内核的当前版本的错误,就我而言。正如我们在启动板上看到的那样,该错误有时会出现:错误#45234,错误#1811580 ; 还是在ServerFault上:为什么每次启动后都缺少/ var / run / sshd?

此问题的解决方法很少,它们全都以其他方式共同创建,/var/run/sshd然后再运行SSH服务器。这是三种可能的解决方案。


解决方法1:/usr/lib/tmpfiles.d/sshd.conf通过以下方式进行修改:

d /run/sshd 0755 root root

正如问题中提到的,/var/run是的符号链接/run,最终结果是相同的:/var/run/sshd创建。我不知道为什么,但是这可行。


解决方法2:使用Cron作业将创建/var/run/sshd并重新启动SSH服务器,您可以crontab为此使用根目录-执行sudo crontab -e并添加以下条目:

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

目前,我正在使用此解决方案,因此也已对其进行了测试。


解决方法3:/etc/rc.local做与上述相同,因为它是在此评论中所示的错误报告#45234。


1
谢谢,它可以解决ssh问题,但不能解决更广泛的systemd问题。尝试运行systemd-tmpfiles --create并查看所有错误
paulzag

1
您是对的,@ paulzag,但是对于我而言,我可以确定一般问题是旧内核。我决定忽略systemd-tmpfiles --create显示的这些错误,因为当前服务器上没有任何明显的故障。通常,当前的问题是有关在解决问题后如何在重启后使SSH服务正常运行。如果您希望可以
投票

“解决方法1”对我有用...谢谢...投票最多...
有用

2
相反,改写 /usr/lib/tmpfiles.d/sshd.conf而不是直接修改它会更合适,因为该文件由程序包管理器管理。为此,只需在中进行更改即可/etc/tmpfiles.d/sshd.conf;这将优先于sshd.confin /usr/lib。请参阅tmpfiles.d(5)中的本节。伟大的答案不管,正对一个OpenVZ的VPS正是我在遇到这个情况。
ZeroKnight

1
至于为什么 解决方法1工程; 您避免使用/var/run符号链接,这是systemd-tmpfiles有问题的原因,以及为什么未创建PrivSep目录。此线程的倒数第4条消息对此有所启发。当然,这是关于的systemd-tmpfiles-clean,但是我觉得这里同样适用。
ZeroKnight

1

您能否检查您的/(根文件系统)权限是否未更改?必须root:root像下面的两行:

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

如果所有者是其他用户(而不是root用户),则将阻止systemd在系统启动期间创建所有临时文件。您也可以使用以下命令进行检查:

systemd-tmpfiles --create

如果是根文件夹(/)具有不同的权限,请使用以下命令进行更改:

chown root: /

0

感谢大家提供有用的信息。正如Melebius和Stefan所建议的那样,我的Xenial Lubuntu上的ssh-server的问题确实与所有权“ /”有关。临时
手动创建/var/run/sshd并重新启动ssh.service临时ssh-server。sshd.conf在此系统中编辑并没有帮助。然后按照最后一个建议,我使用以下命令检查了根文件夹的所有权:

ls -alF /,当然,它已被意外更改为本地用户/组。从终端发出:' sudo chown root:root /'修复了我的系统,无论对的编辑如何sshd.conf。因此,我将其恢复为原始状态d /var/run/sshd 0755 root root


0

当我在一台计算机(18.04.02 LTS,OpenSSH 7.6p1)上运行多个sshd实例时,我的计算机上出现此问题。

问题是在sshd中(即命令行或sshd_config文件)中没有提供用于更改“特权分离目录”位置的开关。/var/empty根据OpenSSH 7.6p1源代码,该目录应位于中。

Ubuntu软件包已将此映射到/run/sshd

init.d当两个服务脚本都尝试创建目录时,启动时脚本中存在“线程安全”问题。我已经要求Ubuntu和OpenSSH都解决sshd中硬编码的“特权分离目录”路径名的问题。如果可以上传文件,则可以根据8.0p1 OpenSSH源代码进行修复。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.