Serwer SSH przestaje działać po ponownym uruchomieniu, spowodowanym brakiem / var / run / sshd

23

Moje VPS nie zostało ponownie uruchomione przez około 3 miesiące. Jest hostowany na serwerze z typem wirtualizacji OpenVZ, a systemem operacyjnym jest Ubuntu 16.04. Z jakiegoś powodu zrestartowałem VPS, a potem nie mogłem połączyć się z serwerem przez ssh, wiadomość, którą otrzymałem to:

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

Otworzyłem więc konsolę szeregową na VPS i zacząłem badać ... Wyczyściłem i ponownie zainstalowałem openssh-serverbez powodzenia. Dwie godziny spędziłem na czytaniu artykułów, pytań i odpowiedzi na temat podobnych problemów w Internecie.

Wreszcie udało mi się zrozumieć, że katalog /var/run/sshdnie jest tworzony podczas uruchamiania systemu. Po utworzeniu go ręcznie mogę uruchomić usługę SSH bez problemu, ale przy następnym uruchomieniu problem nadal występuje. Więc moje pytania to:

  • Co może być przyczyną tego problemu? Dlaczego /var/run/sshdnie jest tworzony podczas uruchamiania systemu?

  • Jak mogę rozwiązać problem w odpowiedni sposób? Znalazłem rozwiązanie czasowe wspomniane na końcu tego postu.

  • Czy problem może być związany z hostem OpenVZ VPS? Czy powinienem poprosić dostawcę usług hostingowych o rozwiązanie tego problemu?


Wyjście systemctl status ssh.service, sshd -Ddp 22a journalctl -xeto:

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

Treść /usr/lib/tmpfiles.d/sshd.confi /etc/init/ssh.confjest:

# 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

Dodatkowe informacje o systemie:

# 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

Rozwiązanie czasowe: Odkryłem, że /var/runjest to symboliczny link do /run, nie wiem, dlaczego jest to potrzebne, ale kiedy zmodyfikowałem zawartość pliku /usr/lib/tmpfiles.d/sshd.confz:

d /var/run/sshd 0755 root root

do:

d /run/sshd 0755 root root

wszystko idzie dobrze po uruchomieniu systemu, usługa SSH jest uruchamiana normalnie i jestem w stanie zalogować się przez SSH.

pa4080
źródło
Ten problem może nagle pojawić się po ponownym uruchomieniu z powodu aktualizacji wersji, która została wykonana tuż przed ponownym uruchomieniem, jak opisano w tym powiązanym pytaniu . Lekcja: nie aktualizuj, chyba że jesteś pewien, że twoje jądro to obsługuje.
Śnieg

Odpowiedzi:

24

Odkryłem, że jest to błąd związany z bieżącą wersją systemd i starych jąder, które są używane przez niektóre programy VPS privdes, tak jak w moim przypadku. Ten błąd pojawia się od czasu do czasu, jak widać na Launchpad: Bug # 45234 , Bug # 1811580 ; lub w ServerFault: Dlaczego brakuje mi / var / run / sshd po każdym uruchomieniu?

Istnieje kilka obejść tego problemu, wszystkie one łączą się w alternatywny sposób tworzenia /var/run/sshdprzed uruchomieniem serwera SSH. Oto trzy możliwe rozwiązania.


Obejście 1: Zmodyfikuj /usr/lib/tmpfiles.d/sshd.confw następujący sposób:

d /run/sshd 0755 root root

Jak wspomniano w pytaniu, /var/runjest dowiązaniem symbolicznym /run, końcowy wynik jest identyczny: /var/run/sshdjest tworzony. Nie wiem dlaczego, ale to działa.


Obejście 2: Użyj zadania Cron, które utworzy /var/run/sshdi zrestartuje serwer SSH, w crontabtym celu możesz użyć katalogu głównego - wykonaj sudo crontab -ei dodaj następujący wpis:

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

Obecnie używam tego rozwiązania, więc jest ono również testowane.


Obejście 3: Użyj, /etc/rc.localaby zrobić to samo co powyżej, jak pokazano w tym komentarzu do raportu o błędzie # 45234.

pa4080
źródło
1
Dzięki, to naprawia ssh, ale nie szersze problemy z przerwaniem systemd. Spróbuj uruchomić systemd-tmpfiles --create i zobacz wszystkie błędy
paulzag
1
Masz rację, @paulzag, ale w moim przypadku jestem pewien, że ogólnym problemem jest stare jądro. Postanowiłem zignorować te wyświetlane błędy systemd-tmpfiles --create, ponieważ w tej chwili nie ma żadnych sensownych awarii na serwerze. aktualne pytanie dotyczy tego, jak uruchomić usługę SSH po ponownym uruchomieniu komputera, gdy problem jest włączony. Jeśli chcesz, możesz głosować za rozwiązaniem :)
pa4080
„Obejście 1” zadziałało dla mnie ... Dzięki ... Zagłosowano ...
Biswadeep Sarkar
2
Bardziej właściwe byłoby zamiast tego zastąpić /usr/lib/tmpfiles.d/sshd.conf , niż modyfikować go bezpośrednio, ponieważ plik ten jest zarządzany przez menedżera pakietów. Aby to zrobić, po prostu dokonaj zmiany /etc/tmpfiles.d/sshd.conf; to będą mieć pierwszeństwo nad sshd.confin /usr/lib. Zobacz tę sekcję w tmpfiles.d (5) . Świetna odpowiedź bez względu na to, że będąc na OpenVZ VPS jest dokładnie taka sytuacja, w jakiej się z tym spotkałem.
ZeroKnight
1
Co do dlaczego Obejście 1 działa; unikasz używania /var/rundowiązania symbolicznego, z którym ma systemd-tmpfilesproblem, i dlaczego nie tworzony jest katalog PrivSep. Ostatnia wiadomość tego wątku rzuca na to trochę światła. To prawda, dotyczy systemd-tmpfiles-clean, ale mam wrażenie, że to samo dotyczy tutaj.
ZeroKnight
1

Czy możesz sprawdzić, czy twoje /uprawnienia (główny system plików) nie uległy zmianie? Muszą być root:rootjak dwie linie poniżej:

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

Jeśli właścicielem jest inny użytkownik (a nie root), uniemożliwi to tworzenie wszystkich plików tymczasowych przez systemd podczas uruchamiania systemu. Możesz również sprawdzić za pomocą polecenia:

systemd-tmpfiles --create

Jeśli folder główny ( /) ma inne uprawnienia, zmień go za pomocą następującego polecenia:

chown root: /
Stefan
źródło
0

Dziękujemy wszystkim za pomocne informacje. Problem z serwerem ssh na moim Xenial Lubuntu był rzeczywiście związany z własnością „/”, jak sugerują Melebius i Stefan.
Ręczne tworzenie /var/run/sshdi ponowne uruchamianie ssh.service tymczasowo tymczasowo ssh-server. Edycja sshd.confnie pomogła w tym systemie. Następnie po ostatniej sugestii sprawdziłem własność folderu głównego za pomocą:

' ls -alF /' i na pewno przypadkowo zmieniono go na lokalnego użytkownika / grupę. Wystawianie z terminala: sudo chown root:root /naprawiłem mój system, niezależnie od edycji na sshd.conf. Więc przywróciłem to do pierwotnego stanu, tj d /var/run/sshd 0755 root root.

Michał
źródło
0

Mam ten problem na moim komputerze, gdy uruchamiam wiele wystąpień sshd na jednym komputerze (18.04.02 LTS, OpenSSH 7.6p1).

Problem polega na tym, że w sshd nie ma przełączników (tj. Wiersza poleceń lub sshd_configpliku), które służą do zmiany lokalizacji „katalogu rozdzielania uprawnień”. Katalog powinien znajdować się w /var/empty, zgodnie z kodem źródłowym OpenSSH 7.6p1.

Pakiet Ubuntu odwzorował to na /run/sshd.

Występuje problem „bezpieczeństwa wątków” w init.dskryptach podczas uruchamiania, gdy oba skrypty serwisowe próbują utworzyć katalog. Poprosiłem zarówno Ubuntu, jak i OpenSSH, aby rozwiązały problem zapisanych w sshd nazw ścieżek „katalogu separacji uprawnień”. Gdybym mógł przesyłać pliki, mam ustalone na podstawie kodu źródłowego OpenSSH 8.0p1.

Luke A Perkins
źródło