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-server
bez 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/sshd
nie 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/sshd
nie 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 22
a journalctl -xe
to:
# 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.conf
i /etc/init/ssh.conf
jest:
# 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/run
jest to symboliczny link do /run
, nie wiem, dlaczego jest to potrzebne, ale kiedy zmodyfikowałem zawartość pliku /usr/lib/tmpfiles.d/sshd.conf
z:
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.
Odpowiedzi:
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/sshd
przed uruchomieniem serwera SSH. Oto trzy możliwe rozwiązania.Obejście 1: Zmodyfikuj
/usr/lib/tmpfiles.d/sshd.conf
w następujący sposób:Jak wspomniano w pytaniu,
/var/run
jest dowiązaniem symbolicznym/run
, końcowy wynik jest identyczny:/var/run/sshd
jest tworzony. Nie wiem dlaczego, ale to działa.Obejście 2: Użyj zadania Cron, które utworzy
/var/run/sshd
i zrestartuje serwer SSH, wcrontab
tym celu możesz użyć katalogu głównego - wykonajsudo crontab -e
i dodaj następujący wpis:Obecnie używam tego rozwiązania, więc jest ono również testowane.
Obejście 3: Użyj,
/etc/rc.local
aby zrobić to samo co powyżej, jak pokazano w tym komentarzu do raportu o błędzie # 45234.źródło
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 :)/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 nadsshd.conf
in/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./var/run
dowiązania symbolicznego, z którym masystemd-tmpfiles
problem, i dlaczego nie tworzony jest katalog PrivSep. Ostatnia wiadomość tego wątku rzuca na to trochę światła. To prawda, dotyczysystemd-tmpfiles-clean
, ale mam wrażenie, że to samo dotyczy tutaj.Czy możesz sprawdzić, czy twoje
/
uprawnienia (główny system plików) nie uległy zmianie? Muszą byćroot:root
jak dwie linie poniżej: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:
Jeśli folder główny (
/
) ma inne uprawnienia, zmień go za pomocą następującego polecenia:źródło
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/sshd
i ponowne uruchamianie ssh.service tymczasowo tymczasowo ssh-server. Edycjasshd.conf
nie 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 nasshd.conf
. Więc przywróciłem to do pierwotnego stanu, tjd /var/run/sshd 0755 root root
.źródło
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_config
pliku), 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.d
skryptach 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.źródło