Il server SSH smette di funzionare dopo il riavvio, a causa della mancanza / var / run / sshd

23

Il mio VPS non è stato riavviato per circa 3 mesi. È ospitato su un server con tipo di virtualizzazione OpenVZ e il sistema operativo è Ubuntu 16.04. Per qualche motivo, ho riavviato il VPS e, successivamente, non sono riuscito a connettermi al server tramite ssh, il messaggio che ho ricevuto è:

ssh: connect to host srvname.com port 22: Connection refused

Quindi ho aperto una console seriale sul VPS e ho iniziato a indagare ... Ho eliminato e reinstallato il file openssh-serversenza successo. Ho trascorso due ore a leggere articoli, domande e risposte su problemi simili su Internet.

Finalmente sono riuscito a capire che la directory /var/run/sshdnon è stata creata durante l'avvio del sistema. E una volta creato manualmente, posso avviare il servizio SSH senza alcun problema, ma al successivo riavvio il problema rimane. Quindi le mie domande sono:

  • Quale potrebbe essere la causa di questo problema? Perché /var/run/sshdnon viene creato durante l'avvio del sistema?

  • Come posso risolvere il problema in modo corretto? Ho trovato una soluzione temporale menzionata alla fine di questo post.

  • Il problema potrebbe essere correlato all'host OpenVZ del VPS? Devo chiedere al provider di hosting di risolverlo?

L'output di systemctl status ssh.service, sshd -Ddp 22ed journalctl -xeè:

# 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'.

Il contenuto di /usr/lib/tmpfiles.d/sshd.confed /etc/init/ssh.confè:

# 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

Ulteriori informazioni sul sistema:

# 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

La soluzione temporale: ho scoperto che /var/runè un collegamento simbolico a /run, non so perché sia ​​necessario, ma quando ho modificato il contenuto del file /usr/lib/tmpfiles.d/sshd.confda:

d /var/run/sshd 0755 root root

a:

d /run/sshd 0755 root root

tutto procede bene all'avvio del sistema, il servizio SSH viene avviato normalmente e sono in grado di accedere tramite SSH.

16.04  server  ssh  startup  openvz 
— pa4080
fonte
Questo problema può apparire all'improvviso dopo un riavvio a causa di un aggiornamento della versione che è stato fatto subito prima del riavvio, come descritto in questa domanda collegata . La lezione: non aggiornare se non sei sicuro che il tuo kernel possa supportarlo.
— Neve,

Risposte:

24

Ho scoperto che si tratta di un bug con l'attuale versione di systemd e kernel vecchi che vengono utilizzati da alcuni privdes VPS come nel mio caso. Questo bug appare di volta in volta, come possiamo vedere su Launchpad: Bug # 45234 , Bug # 1811580 ; o su ServerFault: perché mi manca / var / run / sshd dopo ogni avvio?

Esistono alcune soluzioni alternative a questo problema, che si incontrano tutte in un modo alternativo per creare /var/run/sshdprima di eseguire il server SSH. Ecco tre possibili soluzioni.

Soluzione 1: modificare /usr/lib/tmpfiles.d/sshd.confnel modo seguente:

d /run/sshd 0755 root root

Come è menzionato nella domanda, /var/runè un collegamento simbolico a /run, il risultato finale è identico: /var/run/sshdviene creato. Non so perché, ma funziona.

Soluzione 2: utilizzare il processo Cron che creerà /var/run/sshde riavvierà il server SSH, è possibile utilizzare i root crontabper questo scopo: eseguire sudo crontab -ee aggiungere la seguente voce:

@reboot mkdir -p -m0755 /var/run/sshd && systemctl restart ssh.service

Attualmente sto usando questa soluzione, quindi è anche testata.

Soluzione 3: utilizzare /etc/rc.localper fare lo stesso di quanto sopra, come mostrato in questo commento sulla segnalazione di bug # 45234.

— pa4080
fonte
1
Grazie, questo risolve ssh ma non i problemi più ampi di systemd che viene rotto. Prova a eseguire systemd-tmpfiles --create e vedi tutti gli errori
— paulzag il
1
Hai ragione, @paulzag, ma nel mio caso sono sicuro che il problema generale è il vecchio kernel. Ho deciso di ignorare questi errori che systemd-tmpfiles --createmostrano, perché al momento non ci sono malfunzionamenti sensati sul server. In generale, il la domanda attuale è su come rendere operativo il servizio SSH dopo il riavvio mentre il problema è
— risolto
"Workaround 1" ha funzionato per me ... Grazie ... Up Voted ...
— Biswadeep Sarkar
2
Sarebbe più appropriato invece eseguire l'override /usr/lib/tmpfiles.d/sshd.conf anziché modificarlo direttamente, poiché quel file è gestito dal gestore pacchetti. Per fare ciò, è sufficiente apportare il cambiamento in /etc/tmpfiles.d/sshd.conf; questo avrà la precedenza su sshd.confin /usr/lib. Vedi questa sezione in tmpfiles.d (5) . Ottima risposta a prescindere, essere su un VPS OpenVZ è esattamente la situazione in cui mi sono
— imbattuto
1
Sul motivo per cui Workaround 1 funziona; stai evitando di utilizzare il /var/runcollegamento simbolico, che è ciò che systemd-tmpfilessta avendo un problema e perché la directory PrivSep non viene creata. Il quarto messaggio di questo thread fa luce su questo. Concesso, riguardasystemd-tmpfiles-clean , ma ho la sensazione che la stessa cosa si applichi qui.
— ZeroKnight
1

Potresti verificare se le tue /autorizzazioni (filesystem di root) non sono cambiate? Devono essere root:rootcome le due righe seguenti:

drwxr-xr-x  25 root root      4096 дек 21 06:45 ..
drwxr-xr-x  25 root root      4096 дек 21 06:45 .

Se il proprietario è un altro utente (e non root) ciò impedirà la creazione di tutti i file temporanei da systemd durante l'avvio del sistema. Puoi verificare anche con il comando:

systemd-tmpfiles --create

Se la cartella principale ( /) ha autorizzazioni diverse, modificarla con il comando seguente:

chown root: /
— Stefan
fonte
0

Grazie a tutti per informazioni utili. Il problema con ssh-server sul mio Xenial Lubuntu era in effetti correlato alla proprietà di '/' come suggerito da Melebius e Stefan.
Creazione /var/run/sshde riavvio manuale di ssh.service temporaneamente temporaneamente ssh-server. La modifica di sshd.confnon ha aiutato in questo sistema. Quindi, seguendo l'ultimo suggerimento, ho verificato la proprietà della cartella principale con:

' ls -alF /' e abbastanza sicuro, è stato accidentalmente cambiato in un utente / gruppo locale. Emissione dal terminale: ' sudo chown root:root /' risolto il mio sistema, indipendentemente dalla modifica a sshd.conf. Così l'ho riportato al suo stato originale, cioè d /var/run/sshd 0755 root root.

— Michael
fonte
0

Sto riscontrando questo problema sul mio computer quando eseguo più istanze di sshd su un singolo computer (18.04.02 LTS, OpenSSH 7.6p1).

Il problema è che non ci sono switch in sshd (cioè riga di comando o sshd_configfile) predisposti per cambiare la posizione della "directory di separazione dei privilegi". La directory dovrebbe essere nel /var/empty, secondo il codice sorgente OpenSSH 7.6p1.

Il pacchetto Ubuntu ha rimappato questo a /run/sshd.

C'è un problema di "sicurezza dei thread" negli init.dscript all'avvio quando entrambi gli script di servizio tentano di creare la directory. Ho chiesto sia a Ubuntu che a OpenSSH di affrontare il problema dei nomi di percorso "directory di separazione dei privilegi" codificati in sshd. Se potessi caricare i file, ho il fisso basato sul codice sorgente OpenSSH 8.0p1.

— Luke A Perkins
fonte
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.