Сервер SSH припиняє роботу після перезавантаження, викликаний відсутнім / var / run / sshd


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не створюється під час запуску системи?

  • Як я можу вирішити проблему належним чином? Я знайшов тимчасове рішення, яке згадується в кінці цієї публікації.

  • Чи може ця проблема пов’язана з хостом OpenVZ VPS? Чи потрібно просити хостинг-провайдера вирішити його?


Вихід systemctl status ssh.service, sshd -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.


Ця проблема може раптом з’явитися після перезавантаження через оновлення версії, яке було зроблено безпосередньо перед перезавантаженням, як описано в цьому пов'язаному питанні . Урок: не оновлюйте, якщо ви впевнені, що ваше ядро ​​може його підтримувати.
Сніг

Відповіді:


24

Я виявив, що це помилка з поточною версією системних та старих ядер, які використовуються деякими VPS privdes, як це є в моєму випадку. Ця помилка з’являється час від часу, як ми бачимо на Launchpad: помилка № 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-сервер, ви можете використовувати root crontabдля цього - виконати sudo crontab -eта додати наступний запис:

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

В даний час я використовую це рішення, тому він також перевірений.


Обхід 3: Використовуйте /etc/rc.localтак само, як описано вище, як це показано в цьому коментарі до звіту про помилку # 45234.


1
Дякую, це виправляє ssh, але не більш широкі проблеми системного злому. Спробуйте запустити systemd-tmpfiles - створити та побачити всі помилки
Паульзаг

1
Ви маєте рацію, @paulzag, але в моєму випадку я впевнений, що загальною проблемою є старе ядро. Я вирішив проігнорувати ці помилки, що systemd-tmpfiles --createпоказує, оскільки на даний момент немає жодних розумних несправностей на сервері. Загалом, Поточне запитання - про те, як активувати службу SSH після перезавантаження, поки проблема вирішена. Якщо ви хочете, ви можете підтримати рішення :)
pa4080

"Обхід 1" працював на мене ... Дякую ... Проголосували ...
Biswadeep Sarkar

2
Правильніше було б замість цього замінити, /usr/lib/tmpfiles.d/sshd.conf а не змінити його безпосередньо, оскільки цим файлом керує менеджер пакунків. Для цього просто внесіть зміни /etc/tmpfiles.d/sshd.conf; це буде мати перевагу над sshd.confв /usr/lib. Дивіться цей розділ у tmpfiles.d (5) . Чудова відповідь, незважаючи на те, що я перебуваю на OpenVZ VPS - це саме та ситуація, з якою я стикався.
ZeroKnight

1
Щодо того, як працює обхід 1 ; Ви уникаєте використання /var/runсимвольного посилання, systemd-tmpfilesз чим виникають проблеми, і чому не створюється режим PrivSep. Четверте останнє повідомлення цієї теми проливає на це деяке світло. Зрозуміло, це стосується systemd-tmpfiles-clean, але я маю відчуття, що те саме стосується і тут.
ZeroKnight

2

Чи можете ви перевірити, чи /не змінено ваші дозволи (коренева файлова система)? Повинні бути root:rootяк два рядки нижче:

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

Якщо власником є ​​інший користувач (а не root), це запобіжить створенню всіх тимчасових файлів системою під час запуску системи. Ви також можете перевірити команду:

systemd-tmpfiles --create

Якщо коренева папка ( /) має інший дозвіл, будь ласка, змініть її наступною командою:

chown root: /

1

Дякуємо всім за корисну інформацію. Проблема з ssh-сервером на моєму Xenial Lubuntu справді була пов'язана з власністю на '/', як запропонували Melebius & Stefan.
Створення /var/run/sshdта перезапуск ssh.service вручну тимчасово ssh-сервер тимчасово. Редагування sshd.confне допомогло в цій системі. Потім, виконуючи останню пропозицію, я перевірив право власності на кореневу папку за допомогою:

' ls -alF /' і, безумовно, це було випадково змінено на місцевого користувача / групу. Видача з терміналу: " sudo chown root:root /" виправлено мою систему, незалежно від редагування в sshd.conf. Таким чином я відновив , що в його первісний стан, тобто d /var/run/sshd 0755 root root.


0

У мене є ця проблема на моїй машині, коли я запускаю кілька екземплярів sshd на одній машині (18.04.02 LTS, OpenSSH 7.6p1).

Проблема полягає в тому, що в sshd (тобто командному рядку або sshd_configфайлі), передбачених для зміни місця розташування "каталогу розділення привілеїв" , немає комутаторів . Каталог повинен бути у /var/emptyвихідному коді OpenSSH 7.6p1.

Пакет Ubuntu перезавантажив це /run/sshd.

У init.dскриптах під час завантаження виникає проблема "безпеки безпеки потоку", коли обидва сервісних скрипта намагаються створити каталог. Я попросив і Ubuntu, і OpenSSH вирішити проблему жорстко закодованих імен шляхів "каталог поділу привілеїв" у sshd. Якщо я міг би завантажувати файли, у мене є фіксований на основі вихідного коду OpenSSH 8.0p1.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.