Я использую контейнер Ubuntu 16.04 под Proxmox 5.2-11. После нанесения последнего раунда патчей1 Я не могу войти в систему с консоли или по ssh.
Я смонтировал корневую ФС контейнера на гипервизоре и добавил pts/0
к /etc/security/access.conf
(мы бегаем pam_access
) и это позволило пользователю root войти в консоль. У нас есть root : lxc/tty0 lxc/tty1 lxc/tty2
в access.conf
что, как я думал, было достаточно, зачем мне pts/0
сейчас вызывает недоумение.
Я заметил, что ssh не работает, поэтому попытался запустить его вручную (/usr/sbin/sshd -DDD -f /etc/ssh/sshd_config
) и получил эту ошибку:
Missing privilege separation directory: /var/run/sshd
Каталог создал вручную, запустил ssh
и, наконец, смог войти в систему, но после перезагрузки проблема не исчезла. Каталог не создается. Только полезные биты в journalctl
и единственная интересная часть - это что-то о «операция не разрешена», но никакой дополнительной информации.
Я не слишком знаком с 16.04, поэтому мне интересно, как я могу узнать больше о проблеме. У меня нет /var/log/syslog
или /var/log/messages
только kern.log
так потеряно.
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
Добавлено systemd-tmpfiles --create
вывод
Действительно странно .... Я проверил /tmp
и эти файлы не существуют
Вы сделали одну ошибку - пытались начать sshd
рукой.
Если вы вместо этого начнете sshd
официальными средствами он должен просто работать. В service
команда знает, как правильно запустить службу в вашем дистрибутиве, и это должно работать:
service ssh start
В случае сценариев инициализации sysv это все, что вам нужно сделать. Причина отсутствия каталога в том, что /var/run
символическая ссылка на /run
и /run
это tmpfs
точка крепления. Это означает, что при каждой загрузке /var/run
будет пустым. Когда вы используете service
командовать /etc/init.d/ssh
сценарий будет использоваться для запуска sshd
но перед этим скрипт создаст /var/run/sshd
если его не существует.
С участием systemd
все работает немного иначе. Будет файл с именем /usr/lib/tmpfiles.d/sshd.conf
с этим содержанием:
d /var/run/sshd 0755 root root
Во время загрузки это должно вызвать /var/run/sshd
каталог, который будет создан. Что вам нужно для проверки того, что файл существует и имеет правильное содержимое. Если /var/run/sshd
каталог все еще отсутствует, вы можете проверить, создается ли он при запуске systemd-tmpfiles --create
вручную.
Итак, / run (и / var / run, символически привязанный к нему) воссоздается при каждой перезагрузке. За исключением того, что systemd-tmpfiles не делает этого для некоторых файлов, включая (/ var) / run / sshd.
Видимо, это исправлено обновлением ядра OpenVZ. Но чтобы исправить это сейчас, вы редактируете /usr/lib/tmpfiles.d/sshd.conf
и удалить /var
с линии d /var/run/sshd 0755 root root
вместо этого читать:
d /run/sshd 0755 root root
И это все..!
И когда openssh-server будет обновлен, мы надеемся, что они исправят эту ошибку (или это действительно ошибка в systemd? Или openvz ??) - иначе вы можете столкнуться с той же проблемой.
По-видимому, это решается при запуске ядра OpenVZ 2.6.32-042stab134.7 или новее. Мне кажется странным, что в сценариях запуска systemd как-то невозможно исправить. Вероятно, уродливый хак вроде автоматического создания / run / sshd / после запуска и последующего запуска sshd подойдет.
Результат моего 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
В журнале изменений OpenVZ 2.6.32-042stab134.7 говорится следующее:
Запуск контейнеров Ubuntu с systemd 229-4ubuntu21.9 может привести к тому, что службы не смогут запуститься, потому что systemd-tmpfiles не смогла проверить путь из-за проблем с символической привязкой. (ПСБМ-90038)
Несмотря на то, что у меня было много проблем с systemd на протяжении многих лет, я должен признать, что эта проблема связана с Ansible синхронизировать директива.
По какой-то причине после настройки этого хоста нашими скриптами ansbile он оставил каталог / (а также / etc, / opt и другие), принадлежащим пользователю с правами администратора, а не root. После запуска chown
исправлять вещи, /var/run/sshd
теперь снова создается при загрузке.
Я действительно ценю все вводимые данные, но здесь нет ошибки, по крайней мере, в том смысле, что неправильное владение корневыми каталогами привело к неопределенному поведению системы.