Dlaczego brakuje mi / var / run / sshd po każdym uruchomieniu?

14

Korzystam z kontenera Ubuntu 16.04 pod Proxmox 5.2-11. Po zastosowaniu najnowszej rundy łatek 1 nie mogę się zalogować na konsoli lub przez ssh.

I zamontowany pojemnik główny FS na hypervisor i dodawane pts/0do /etc/security/access.conf(możemy uruchomić pam_access) i które pozwoliły logowania administratora do konsoli. Mamy takie, root : lxc/tty0 lxc/tty1 lxc/tty2w access.confktórych myślałem, że są wystarczające, dlatego pts/0zastanawiam się, dlaczego tak potrzebowałem .

Zauważyłem, że ssh nie działa, więc spróbowałem uruchomić go ręcznie ( /usr/sbin/sshd -DDD -f /etc/ssh/sshd_config) i otrzymałem ten błąd:

Missing privilege separation directory: /var/run/sshd

Katalog utworzyłem ręcznie, uruchomiłem sshi mogłem w końcu się zalogować, ale po ponownym uruchomieniu problem nadal występuje. Katalog nie jest tworzony. Tylko użyteczne fragmenty journalctli jedyna interesująca część to coś o „niedozwolonej operacji”, ale bez dalszych informacji.

Nie znam się zbyt dobrze na 16.04, więc zastanawiam się, jak mogę dowiedzieć się więcej o tym problemie. Nie zgubiłem /var/log/sysloglub /var/log/messagestylko kern.logtak bardzo zgubiłem.

1

systemd-sysv 229-4ubuntu21.9
libpam-systemd 229-4ubuntu21.9
libsystemd0 229-4ubuntu21.9
systemd 229-4ubuntu21.9
udev 229-4ubuntu21.9
libudev1 229-4ubuntu21.9
iproute2 4.3.0-1ubuntu3.16.04.4
libsasl2-modules-db 2.1.26.dfsg1-14ubuntu0.1
libsasl2-2 2.1.26.dfsg1-14ubuntu0.1
ldap-utils 2.4.42dfsg-2ubuntu3.4
libldap-2.4-2 2.4.42dfsg-2ubuntu3.4
libsasl2-modules 2.1.26.dfsg1-14ubuntu0.1
libgs9-common 9.25dfsg1-0ubuntu0.16.04.3
ghostscript 9.25dfsg1-0ubuntu0.16.04.3
libgs9 9.25dfsg1-0ubuntu0.16.04.3

[2]

Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[474]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:48 host16 mysqld_safe[495]: Starting mysqld daemon with databases from /var/lib/mysql/mysql
Nov 27 10:13:48 host16 mysqld[500]: 181127 10:13:48 [Note] /usr/sbin/mysqld (mysqld 10.0.36-MariaDB-0ubuntu0.16.04.1) starting as process 499 ...
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:48 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: Failed to reset devices.list on /system.slice/ssh.service: Operation not permitted
Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[502]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:48 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: Failed to reset devices.list on /system.slice/ssh.service: Operation not permitted
Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[503]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:48 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: Failed to reset devices.list on /system.slice/ssh.service: Operation not permitted
Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[504]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:49 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Start request repeated too quickly.
Nov 27 10:13:49 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Failed with result 'start-limit-hit'.
Nov 27 10:13:49 host16 systemd[1]: Started /etc/rc.local Compatibility.
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/plymouth-quit.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Starting Terminate Plymouth Boot Screen...
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/plymouth-quit-wait.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Starting Hold until boot process finishes up...
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/rc-local.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Started Hold until boot process finishes up.
Nov 27 10:13:49 host16 systemd[1]: Started Container Getty on /dev/pts/1.
Nov 27 10:13:49 host16 systemd[1]: Started Container Getty on /dev/pts/0.
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/console-getty.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Started Console Getty.
Nov 27 10:13:49 host16 systemd[1]: Reached target Login Prompts.
Nov 27 10:13:49 host16 systemd[1]: Started Terminate Plymouth Boot Screen.
Nov 27 10:13:52 host16 nslcd[338]: accepting connections
Nov 27 10:13:52 host16 nslcd[275]:    ...done.
Nov 27 10:13:52 host16 systemd[1]: Started LSB: LDAP connection daemon.
Nov 27 10:13:52 host16 systemd[1]: Failed to reset devices.list on /system.slice/cron.service: Operation not permitted
Nov 27 10:13:52 host16 systemd[1]: Started Regular background program processing daemon.
Nov 27 10:13:52 host16 systemd[1]: Failed to reset devices.list on /system.slice/atd.service: Operation not permitted

Dodano systemd-tmpfiles --createwyjście

Naprawdę dziwne ... Sprawdziłem /tmpi te pliki nie istnieją

— Błąd serwera
źródło

11

Jednym błędem, który popełniłeś, była próba rozpoczęcia sshdod ręki.

Jeśli zamiast tego zaczniesz sshdod oficjalnych środków, powinno to po prostu zadziałać. servicePolecenia wie, co jest poprawny sposób uruchomić usługę w dystrybucji jest i to powinno działać:

service ssh start

W przypadku skryptów inicjujących sysv to wszystko, co musisz zrobić. Powodem katalog brakuje jest to, że /var/runjest dowiązaniem do /runi /runjest to tmpfspunkt montowania. Oznacza to, że przy każdym uruchomieniu /var/runrozpocznie się pusty. Gdy użyjesz servicepolecenia, /etc/init.d/sshskrypt zostanie użyty do uruchomienia, sshdale zanim to zrobisz, skrypt utworzy się, /var/run/sshdjeśli nie istnieje.

Z systemdrzeczy działa trochę inaczej. Będzie plik /usr/lib/tmpfiles.d/sshd.confo tej treści:

d /var/run/sshd 0755 root root

Podczas uruchamiania powinno to spowodować utworzenie /var/run/sshdkatalogu. Czego potrzebujesz, aby sprawdzić, czy plik istnieje i ma poprawną zawartość. Jeśli /var/run/sshdnadal brakuje katalogu, możesz sprawdzić, czy zostanie utworzony podczas systemd-tmpfiles --createręcznego uruchamiania .

— kasperd
źródło

To dobry pomysł, ale zasadniczo robi to samo, co system próbował zrobić podczas rozruchu (i nie powiódł się w ten sam sposób). Naprawdę zastanawiam się, dlaczego katalog prywatny nie jest tworzony w normalny sposób. Czy wystąpił błąd dysku? Problem z pozwoleniem? zablokować plik? Gdzieś jeszcze szukać journalctl?

— Błąd serwera

@ServerFault W pewnych okolicznościach /etc/init.d/sshnie zostanie uruchomiony i systemctlzostanie użyty zamiast niego. A kiedy sshdjest uruchamiany przez systemctlkatalog, katalog nie jest tworzony. To pozostawia kilka otwartych pytań, które postaram się zagłębić jutro, takich jak to, co dokładnie się zmieniło i jak dokładnie ten katalog ma zostać utworzony, gdy systemctljest używany.

— kasperd

@ServerFault Podczas korzystania systemctlTo /etc/init/ssh.confktóry jest odpowiedzialny za tworzenie katalogu. Testowałem na w pełni aktualnym Ubuntu 16.04 i katalog jest tworzony podczas uruchamiania. Ale z jakiegoś powodu nie jest tworzony podczas używania service ssh start. Istnieje kilka ostatnich aktualizacji niektórych systemdpowiązanych pakietów, ale nie widzę żadnych dowodów na zachowanie dotyczące tworzenia tego katalogu, który się zmienił. A kiedy testuję, powstaje podczas rozruchu. Pytanie brzmi zatem, czy masz /etc/init/ssh.confodpowiednią zawartość.

— kasperd

@ServerFault Mogłem się mylić co do tego, /etc/init/ssh.confże /usr/lib/tmpfiles.d/sshd.confwydaje się, że jest używany przez systemd-tmpfiles --create. Czy systemd-tmpfiles --createtworzy brakujący /var/run/sshdkatalog?

— kasperd

Dodano zdjęcie do pytania z systemd-tmpfiles --createwyjścia. Systemd narzeka na „dowiązania symboliczne” (/tmp/.X11-unix) nawet nie istnieją, /tmp/więc nie mam pojęcia, skąd to bierze . Dziękuję za twoją pomoc, ale myślę, że idę dalej.

— Błąd serwera

11

Tak więc / run (i / var / run dowiązane do niego) jest odtwarzany przy każdym ponownym uruchomieniu. Tyle że systemd-tmpfiles nie robi tego w przypadku niektórych plików, w tym (/ var) / run / sshd.

Najwyraźniej jest to naprawione przez aktualizację jądra OpenVZ. Ale aby to naprawić, teraz edytujesz /usr/lib/tmpfiles.d/sshd.confi usuwasz /varz wiersza, d /var/run/sshd 0755 root rootaby zamiast tego przeczytać:d /run/sshd 0755 root root

I to wszystko..!

A kiedy serwer openssh zostanie zaktualizowany, mamy nadzieję, że naprawią ten błąd (czy to naprawdę błąd w systemie? Lub openvz?) - w przeciwnym razie możesz napotkać ten sam problem.

— pepa65
źródło

1

+1 za poprawkę podczas oczekiwania na aktualizację jądra. W moim przypadku musiało to być: „root / d / run / sshd 0755 root”

— paulzag

1

@paulzag To też działało dla mnie. Zastanawiam się, czy @ pepa65 chciał powiedzieć d /run/sshd 0755 root root, ponieważ ich instrukcje mówią, aby usunąć tylko /varczęść (nawet jeśli kod podany w odpowiedzi ma zarówno /vari /runusunięty).

— Stephen Schrauger,

4

Najwyraźniej problem został rozwiązany po uruchomieniu jądra OpenVZ 2.6.32-042stab134.7 lub nowszego. Wydaje mi się dziwne, że nie ma możliwości naprawy skryptu systemd start. Prawdopodobnie działałby brzydki hack, taki jak automatyczne tworzenie / run / sshd / po uruchomieniu, a następnie uruchomieniu sshd.

Wyjście mojego systemd-tmpfiles --create:

[/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
fchownat() of /run/named failed: Invalid argument
Failed to openat(/dev/simfs): Operation not permitted
Failed to validate path /var/run/screen: Too many levels of symbolic links
Failed to validate path /var/run/sshd: Too many levels of symbolic links
Failed to validate path /var/run/sudo: Too many levels of symbolic links
Failed to validate path /var/run/sudo/ts: Too many levels of symbolic links
fchownat() of /run/systemd/netif failed: Invalid argument
fchownat() of /run/systemd/netif/links failed: Invalid argument
fchownat() of /run/systemd/netif/leases failed: Invalid argument
fchownat() of /run/log/journal failed: Invalid argument
fchownat() of /run/log/journal/e9e1d08bc42c48999865b96c250f40cc failed: Invalid argument
fchownat() of /run/log/journal/e9e1d08bc42c48999865b96c250f40cc/system.journal failed: Invalid argument

Dziennik zmian OpenVZ 2.6.32-042stab134.7 mówi:

Uruchamianie kontenerów Ubuntu z systememd 229-4ubuntu21.9 może spowodować, że usługi nie zostaną uruchomione, ponieważ systemd-tmpfiles nie może zweryfikować ścieżki z powodu problemów z łączeniem. (PSBM-90038)

— pepa65
źródło

2

Mimo tylu problemów, jakie miałem z systemd przez lata, muszę przyznać, że ten problem wynika z dyrektywy Ansible synchronize .

Z jakiegoś powodu, po wyposażeniu tego hosta w nasze skrypty ansbile, opuścił on katalog / (/ etc /, opt / i inne) będący własnością administratora, a nie root. Po uruchomieniu, chownaby poprawić rzeczy, /var/run/sshdjest teraz tworzony ponownie podczas uruchamiania.

Naprawdę doceniam wszystkie dane wejściowe, ale nie ma tutaj błędu, przynajmniej w tym sensie, że zastosowanie niewłaściwej własności do katalogów głównych spowodowało niezdefiniowane zachowanie systemu.

— Błąd serwera
źródło

To! Dzięki za wskazówkę, Ansible był również winowajcą w naszym przypadku!

— Beenish Khan,