Por que estou ausente / var / run / sshd após cada inicialização?

14

Estou executando um contêiner Ubuntu 16.04 no Proxmox 5.2-11. Depois de aplicar a última rodada de patches 1, não consigo fazer login no console ou no ssh.

Montei o FS raiz do contêiner no hipervisor e adicionei pts/0a /etc/security/access.conf(nós executamos pam_access) e isso permitiu o login raiz no console. Temos root : lxc/tty0 lxc/tty1 lxc/tty2em access.confque eu pensei que era suficiente para por que eu precisava pts/0agora é intrigante.

Notei que o ssh não estava funcionando, tentei iniciá-lo manualmente ( /usr/sbin/sshd -DDD -f /etc/ssh/sshd_config) e recebi este erro:

Missing privilege separation directory: /var/run/sshd

Criei o diretório manualmente, iniciei sshe consegui finalmente fazer o login, mas após uma reinicialização, o problema persiste. O diretório não está sendo criado. Somente bits úteis journalctle a única parte interessante são algo sobre "operação não permitida", mas nenhuma informação adicional.

Eu não estou muito familiarizado com o 16.04, então me pergunto como descobrir mais sobre o problema. Eu não tenho /var/log/syslogou /var/log/messagesapenas estou kern.logperdido.

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

systemd-tmpfiles --createSaída adicionada

Realmente bizarro .... eu verifiquei /tmpe esses arquivos não existem

— Falha no servidor
fonte

11

Um erro que você cometeu foi tentar começar sshdà mão.

Se você começar sshdpor meios oficiais, deve funcionar. O servicecomando sabe qual é a maneira correta de iniciar um serviço em sua distribuição e isso deve funcionar:

service ssh start

No caso de scripts sysv init, é tudo o que você precisa fazer. A razão pela qual o diretório está ausente é que /var/runé um link simbólico para /rune /runé um tmpfsponto de montagem. Isso significa que em cada inicialização /var/runcomeçará vazio. Quando você usa o servicecomando, o /etc/init.d/sshscript será usado para iniciar, sshdmas antes disso, o script será criado /var/run/sshdse ele não existir.

Com as systemdcoisas funcionam um pouco diferente. Haverá um arquivo chamado /usr/lib/tmpfiles.d/sshd.confcom este conteúdo:

d /var/run/sshd 0755 root root

Durante a inicialização, isso deve causar a /var/run/sshdcriação do diretório. O que você precisa para verificar se o arquivo existe e tem o conteúdo correto. Se o /var/run/sshddiretório ainda estiver ausente, você poderá verificar se ele é criado quando você executa systemd-tmpfiles --createmanualmente.

— Kasperd
fonte

Essa é uma boa ideia, mas está essencialmente fazendo a mesma coisa que o sistema tentou fazer na inicialização (e falhou da mesma maneira). O que realmente estou pensando é por que o diretório privsep não está sendo criado normalmente. Existe um erro no disco? Um problema de permissão? bloquear arquivo? Em algum outro lugar para procurar além journalctl?

— Falha no servidor

@ServerFault Sob certas circunstâncias /etc/init.d/ssh, não será executado e systemctlserá usado. E quando sshdé iniciado através systemctldo diretório não é criado. Isso deixa algumas questões em aberto que tentarei analisar amanhã, como exatamente o que mudou e como exatamente esse diretório deve ser criado quando systemctlfor usado.

— kasperd

@ServerFault Ao usá- systemctllo, /etc/init/ssh.confé responsável pela criação do diretório. Eu testei em um Ubuntu 16.04 totalmente atualizado e o diretório foi criado durante a inicialização. Mas, por algum motivo, ele não é criado ao usar service ssh start. Existem algumas atualizações recentes de alguns systemdpacotes relacionados, mas não vejo nenhuma evidência de comportamento quanto à criação desse diretório alterado. E quando eu testo, ele é criado durante a inicialização. Portanto, a questão é se você /etc/init/ssh.confpossui o conteúdo correto.

— kasperd

@ServerFault Eu posso ter me enganado sobre o fato de /etc/init/ssh.confque também /usr/lib/tmpfiles.d/sshd.confparece ser usado por systemd-tmpfiles --create. Cria systemd-tmpfiles --createo /var/run/sshddiretório ausente ?

— kasperd

Adicionada foto para questionar a partir da systemd-tmpfiles --createsaída. O sistema "symlinks" está reclamando (/tmp/.X11-unix) nem existe, /tmp/então eu não tenho idéia de onde ele está tirando isso. Obrigado por toda a sua ajuda, mas acho que vou seguir em frente.

— Falha no servidor

10

Assim, / run (e / var / run com o link simbólico) são recriados a cada reinicialização. Exceto que systemd-tmpfiles não está fazendo isso em alguns arquivos, incluindo (/ var) / run / sshd.

Aparentemente, isso é corrigido por uma atualização do kernel do OpenVZ. Mas para corrigi-lo agora, edite /usr/lib/tmpfiles.d/sshd.confe remova /varda linha d /var/run/sshd 0755 root rootpara ler:d /run/sshd 0755 root root

E é isso..!

E quando o openssh-server for atualizado, esperamos que eles tenham corrigido esse bug (ou é realmente um bug no systemd? Ou openvz ??) - caso contrário, você poderá encontrar o mesmo problema.

— pepa65
fonte

1

+1 para a correção enquanto aguarda uma atualização do Kernel. No meu caso, ele precisava se tornar: "d / run / sshd 0755 root root"

— paulzag

1

@paulzag Isso funcionou para mim também. Gostaria de saber se @ pepa65 quis dizer d /run/sshd 0755 root root, já que as instruções dizem apenas para remover a /varparte (mesmo que o código que eles dão na resposta tenha ambos /vare /runremovido).

— Stephen Schrauger 07/02/19

4

Aparentemente, isso é resolvido ao executar um kernel OpenVZ 2.6.32-042stab134.7 ou mais recente. Acho estranho que não seja possível corrigir os scripts de inicialização do systemd de alguma forma. Provavelmente, um truque feio, como criar automaticamente / executar / sshd / após a inicialização e iniciar o sshd, funcionaria.

A saída do meu 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

O changelog do OpenVZ 2.6.32-042stab134.7 diz o seguinte:

A execução de contêineres Ubuntu com systemd 229-4ubuntu21.9 pode resultar na falha da inicialização dos serviços, porque o systemd-tmpfiles não pôde validar o caminho devido a problemas de ligação de link. (PSBM-90038)

— pepa65
fonte

2

Por tantos problemas que tive com o systemd ao longo dos anos, devo admitir que esse problema decorre da diretiva de sincronização Ansible .

Por alguma razão, depois de provisionar este host com nossos scripts ansbile, ele deixou o diretório / (assim como o / etc, / opt e outros) de propriedade de um usuário administrador, e não o root. Depois de executar chownpara corrigir as coisas, /var/run/sshdagora é criado na inicialização novamente.

Eu realmente aprecio toda a entrada, mas não há nenhum erro aqui, pelo menos no sentido de que aplicar propriedade inadequada a diretórios raiz causou um comportamento indefinido do sistema.

— Falha no servidor
fonte

Este! Obrigado pela dica, Ansible também foi a culpada no nosso caso!

— Beenish Khan