Perché mi manca / var / run / sshd dopo ogni avvio?

14

Sto eseguendo un contenitore Ubuntu 16.04 con Proxmox 5.2-11. Dopo aver applicato l'ultimo round di patch 1 non riesco ad accedere alla console o tramite ssh.

Ho montato il container root FS sull'hypervisor e l'ho aggiunto pts/0a /etc/security/access.conf(eseguiamo pam_access) e questo ha permesso l'accesso root alla console. Abbiamo root : lxc/tty0 lxc/tty1 lxc/tty2in access.confcui pensavo fosse sufficiente, quindi il motivo per cui avevo bisogno pts/0ora è sconcertante.

Ho notato che ssh non era in esecuzione, quindi ho provato a avviarlo manualmente ( /usr/sbin/sshd -DDD -f /etc/ssh/sshd_config) e ho ricevuto questo errore:

Missing privilege separation directory: /var/run/sshd

Ho creato la directory a mano, avviato sshe ho potuto finalmente accedere, ma dopo un riavvio il problema persiste. La directory non viene creata. Solo i bit utili journalctle l'unica parte interessante riguarda qualcosa "operazione non consentita" ma nessuna ulteriore informazione.

Non ho familiarità con il 16.04, quindi mi chiedo come posso scoprire di più sul problema. Io non ho /var/log/syslogo /var/log/messagessolo kern.logcosì gentile di Lost.

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

Aggiunto systemd-tmpfiles --createoutput

Davvero bizzarro .... Ho controllato /tmpe quei file non esistono inserisci qui la descrizione dell'immagine

linux  ssh  permissions  systemd  proxmox 
— Errore del server
fonte

Risposte:

11

Un errore che hai fatto è stato tentare di iniziare sshda mano.

Se invece inizi sshdcon mezzi ufficiali, dovrebbe funzionare. Il servicecomando conosce qual è il modo corretto di avviare un servizio sulla tua distribuzione e questo dovrebbe funzionare:

service ssh start

Nel caso di script init sysv, è tutto ciò che devi fare. Il motivo per cui manca la directory è che /var/runè un collegamento simbolico a /runed /runè un tmpfspunto di montaggio. Ciò significa che ad ogni avvio /var/runinizierà vuoto. Quando si utilizza il servicecomando, lo /etc/init.d/sshscript verrà utilizzato per l'avvio, sshdma prima di farlo lo script creerà /var/run/sshdse non esiste.

Con le systemdcose funziona un po 'diversamente. Ci sarà un file chiamato /usr/lib/tmpfiles.d/sshd.confcon questo contenuto:

d /var/run/sshd 0755 root root

Durante l'avvio ciò dovrebbe causare la /var/run/sshdcreazione della directory. Cosa è necessario per verificare che il file esista e abbia i contenuti corretti. Se la /var/run/sshddirectory non è ancora presente, è possibile verificare se viene creata quando si esegue systemd-tmpfiles --createmanualmente.

— kasperd
fonte
Questa è una buona idea, ma essenzialmente sta facendo la stessa cosa che il sistema ha provato a fare all'avvio (e non è riuscito allo stesso modo). Quello che mi chiedo davvero è perché la directory privsep non viene creata con mezzi normali. C'è un errore del disco? Un problema di autorizzazione? file di blocco? Altrove altro da guardare oltre journalctl?
— Errore del server il
@ServerFault In determinate circostanze /etc/init.d/sshnon verrà eseguito e systemctlverrà invece utilizzato. E quando sshdviene avviato attraverso systemctlla directory non viene creata. Ciò lascia alcune domande aperte che cercherò di approfondire domani come cosa è esattamente cambiato e come dovrebbe essere creata quella directory quando systemctlviene usata.
— Kasperd,
@ServerFault In caso di utilizzo systemctldi essa la /etc/init/ssh.confquale è responsabile della creazione della directory. Ho provato su Ubuntu 16.04 completamente aggiornato e la directory viene creata durante l'avvio. Ma per qualche motivo non viene creato durante l'utilizzo service ssh start. Ci sono alcuni aggiornamenti recenti di alcuni systemdpacchetti correlati, ma non vedo alcuna prova del comportamento riguardo alla creazione di quella directory che sia cambiata. E quando provo viene creato durante l'avvio. Quindi la domanda è se hai /etc/init/ssh.confi contenuti corretti.
— Kasperd,
@ServerFault Potrei essermi sbagliato su /etc/init/ssh.confc'è anche quello /usr/lib/tmpfiles.d/sshd.confche sembra essere utilizzato da systemd-tmpfiles --create. Non systemd-tmpfiles --createcreare la mancante /var/run/sshddirectory?
— Kasperd,
Aggiunta foto alla domanda systemd-tmpfiles --createdall'output. I "symlink" di cui si sta lamentando systemd (/tmp/.X11-unix) non esistono nemmeno, /tmp/quindi non ho idea da dove lo ottenga. Grazie per tutto il tuo aiuto, ma penso che andrò avanti.
— Errore del server,
10

Quindi / run (e / var / run collegati ad esso) viene ricreato ad ogni riavvio. Tranne che systemd-tmpfiles non lo fa per alcuni file tra cui (/ var) / run / sshd.

Apparentemente, questo è risolto da un aggiornamento del kernel OpenVZ. Ma per risolverlo ora, modifica /usr/lib/tmpfiles.d/sshd.confe rimuovi /vardalla riga d /var/run/sshd 0755 root rootper leggere invece: d /run/sshd 0755 root root

E questo è tutto ..!

E quando openssh-server viene aggiornato, speriamo che abbiano corretto questo bug (o è davvero un bug in systemd? O openvz ??) - altrimenti potresti incorrere nello stesso problema.

— pepa65
fonte
1
+1 per la correzione in attesa di un aggiornamento del kernel. Nel mio caso doveva diventare: "d / run / sshd 0755 root root"
— paulzag
1
@paulzag Ha funzionato anche per me. Mi chiedo se @ pepa65 intendesse dire d /run/sshd 0755 root root, poiché le loro indicazioni dicono di rimuovere solo la /varparte (anche se il codice che danno nella risposta ha entrambi /vare /runrimosso).
— Stephen Schrauger,
4

Apparentemente questo viene risolto quando si esegue un kernel OpenVZ 2.6.32-042stab134.7 o più recente. Trovo strano che non ci sia alcuna correzione possibile negli script di avvio di systemd in qualche modo. Probabilmente un brutto hack come la creazione automatica / run / sshd / dopo l'avvio e quindi l'avvio di sshd funzionerebbe.

L'output del mio 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

Il log delle modifiche di OpenVZ 2.6.32-042stab134.7 dice questo:

L'esecuzione di contenitori Ubuntu con systemd 229-4ubuntu21.9 potrebbe causare l'avvio dei servizi perché systemd-tmpfiles non è stato in grado di convalidare il percorso a causa di problemi di collegamento simbolico. (PSBM-90038)

— pepa65
fonte
2

Per tutti i problemi che ho avuto con systemd nel corso degli anni, devo ammettere che questo problema deriva invece dalla direttiva di sincronizzazione di Ansible .

Per qualche motivo, dopo aver eseguito il provisioning di questo host con i nostri script ansbile, ha lasciato la directory / (così come / etc, / opt e altri) di proprietà di un utente amministratore e non root. Dopo l'esecuzione chownper correggere le cose, /var/run/sshdviene ora creato nuovamente all'avvio.

Apprezzo davvero tutto l'input, ma qui non c'è nessun bug, almeno nel senso che l'applicazione di proprietà inadeguate alle directory root ha causato un comportamento indefinito del sistema.

— Errore del server
fonte
Questo! Grazie per la punta, Ansible è stato il colpevole anche nel nostro caso!
— Beenish Khan,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.