Il sistema rifiuta SSH e si blocca all'avvio dopo l'installazione del sistema


12

Ho un problema che è riproducibile su macchine virtuali Ubuntu Linux (14.04 LTS) create in Azure.

Dopo aver installato il systemdpacchetto tramite script, il sistema rifiuta le nuove connessioni ssh, all'infinito.

Il sistema si sta avviando.

Connessione chiusa da xxx.xxx.xxx.xxx

La connessione ssh attiva viene comunque mantenuta. Non ci sono /etc/nologinfile presenti nel sistema.

L'unica opzione che vedo è un hard reset che risolve il problema. Ma come posso evitarlo?

Ecco lo script che sto usando:

#!/bin/bash

# Script input arguments
user=$1
server=$2

# Tell the shell to quote your variables to be eval-safe!

printf -v user_q '%q' "$user"
printf -v server_q '%q' "$server"
#

SECONDS=0
address="$user_q"@"$server_q"

function run {
    ssh "$address" /bin/bash "$@"
}

run << SSHCONNECTION
    # Enable autostartup

        # systemd is required for the autostartup
        sudo dpkg-query -W -f='${Status}' systemd 2>/dev/null | grep -c "ok installed" > /home/$user_q/systemd-check.txt
        systemdInstalled=\$(cat /home/$user_q/systemd-check.txt)

        if [[ \$systemdInstalled -eq 0 ]]; then
            echo "Systemd is not currently installed. Installing..."

            # install systemd
            sudo apt-get update
            sudo apt-get -y install systemd

        else
            echo "systemd is already installed. Skipping this step."
        fi

SSHCONNECTION

Il sistema si blocca o semplicemente non avvia il daemon di shell sicuro? La domanda afferma una; il corpo del post implica che potrebbe essere l'altro.
DopeGhoti,

@DopeGhoti Non ho modo di controllare cosa sta succedendo poiché non riesco a collegarmi alla macchina da remoto. Aggiornerò la domanda per renderla più chiara.
Alex

Risposte:


15

Ho il sospetto che esista un /etc/nologinfile (il cui contenuto sarebbe "Il sistema si sta avviando") che non viene rimosso dopo l'installazione di systemd.

[aggiornamento] Ciò che ti colpisce è un bug che è stato segnalato sul BTS di Ubuntu lo scorso dicembre. È dovuto a un /var/run/nologinfile (= /run/nologinpoiché /var/runè un collegamento simbolico a /run) che non viene rimosso al termine dell'installazione di systemd.

/etc/nologinè il file nologin standard. /var/run/nologinè un file alternativo che può essere utilizzato dal nologinmodulo PAM ( man pam_nologin).

Si noti che nessuno dei nologinfile influenza le connessioni da parte dell'utente root, solo agli utenti regolari è impedito l'accesso.


Ho riprodotto il problema, non è presente alcun file / etc / nologin. La sessione SSH attiva viene mantenuta, tuttavia quelle nuove vengono rifiutate fino al riavvio della macchina.
Alex

Ho anche controllato /etc/shadowe l'account non è bloccato
Alex

@Alex Risposta aggiornata.
Xhienne,

10

@xhienne mi ha dato la giusta direzione.

Dopo aver cercato nel file system ho trovato il file /run/nologin(suggerito da @xhienne / etc / nologin), rimuovendo il problema risolto.

La condizione esisteva in /usr/lib/tmpfiles.d/systemd.conf

Includerò questo passaggio nella mia sceneggiatura.

sudo rm /run/nologin

Sono contento che funzioni. Ho aggiornato la mia risposta.
Xhienne,

2
Note:  This answer is applicable whether or not systemd was recently installed or not.
       The issue was observed even after systemd had been installed a long time.

Il bug tracker della distribuzione Mageia sembra avere un problema correlato aperto: Bug 21080 - login ssh disabilitato da / run / nologin dopo un riavvio .

Dopo aver riscontrato questo problema abbastanza frequentemente, trovare il tracker ha aiutato a identificare una soluzione alternativa che potrebbe essere più appropriata della semplice rimozione del file / run / login .

Ecco alcuni dati relativi alle query per informazioni in quel tracker bug:

$ ls -l /run/nologin 
-rw-r--r-- 1 root root 42 Mar  6 10:11 /run/nologin
$ cat /run/nologin
"System is booting up. See pam_nologin(8)"
$ date
Tue Mar  6 11:10:38 CST 2018
$ uptime
11:15:10 up  1:04,  0 users,  load average: 0.07, 0.07, 0.08
$ systemctl status systemd-user-sessions.service
● systemd-user-sessions.service - Permit User Sessions
   Loaded: loaded (/usr/lib/systemd/system/systemd-user-sessions.service; static
   Active: inactive (dead)
     Docs: man:systemd-user-sessions.service(8)
$ systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After  systemd-user-sessions.service --no-pager
Requires=system.slice sysinit.target
Requisite=
Wants=
BindsTo=
PartOf=
Before=getty@tty1.service prefdm.service crond.service multi-user.target plymouth-quit-wait.service session-c2.scope display-manager-failure.service systemd-ask-password-wall.service session-c1.scope user@983.service shutdown.target user@1000.service user-983.slice user-1000.slice plymouth-quit.service
After=system.slice systemd-journald.socket remote-fs.target network.target systemd-journal-flush.service sysinit.target nss-user-lookup.target basic.target

Il tracker dei bug e le informazioni sopra sembrano mostrare che il problema è effettivamente dovuto a un errore nell'avvio del demone systemd-user-sessioni.service .

Questo è in effetti ciò che accade nel mio caso, quindi la seguente soluzione alternativa corregge temporaneamente la condizione di accesso vietata:

$ sudo systemctl start systemd-user-sessions.service

Dopo aver fatto ciò, il file / run / nologin non è più presente e si può SSH da un altro sistema. Si noti, tuttavia, che ciò non è affidabile in quanto a volte l'utente non ha accesso alla console del sistema interessato.


0

Ho avuto lo stesso identico problema, ma penso che diversi scenari possano crearlo.

Nel mio caso, per abilitare nuovamente l'accesso remoto ho dovuto richiedere a KVM l'accesso diretto al nostro server remoto e quindi:

# 1. Start SSH service
/etc/init.d/ssh start

# 2. Remove the nologin file
rm /run/nologin

Ma alla schermata di KVM ho potuto vedere che si è avviato in modalità di emergenza!

In precedenza, avevo apportato alcune modifiche al disco / alla partizione (aumentando gli inode) che generavano un nuovo UUID e avevo dimenticato di aggiungerlo al file / etc / fstab.

Dopo aver emesso il comando:

blkid

... e copiando e incollando il nuovo UUID sul file fstab, sono stato in grado di riavviare nuovamente il server senza problemi e l'accesso remoto SSH andava bene dopo.


0

In / etc / ssh / sshd_config impostare UsePAM su no

UsePAM no

Cosa farebbe questo e quali sarebbero le conseguenze?
Kusalananda

Questa risposta non sembra applicarsi a questa situazione, non spiega perché l'utente vede il testo "Il sistema si sta avviando" o spiega come l'installazione di systemd abbia generato la configurazione errata.
Jeff Schaller
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.