Sospetto che ci sia un /etc/nologin file (il cui contenuto sarebbe "Il sistema si sta avviando.") che non viene rimosso dopo l'installazione di systemd.
[aggiornamento] Ciò che ti riguarda è un bug che è stato segnalato su BTS di Ubuntu lo scorso dicembre. È dovuto a un /var/run/nologin file (=/run/nologin dal /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 usato dal nologin Modulo PAM (man pam_nologin ).
Nota che nessuno dei nologin i file influiscono sulle connessioni dell'utente root, solo agli utenti normali è impedito l'accesso.
@xhienne mi ha dato la giusta direzione.
Dopo aver cercato nel file system ho trovato /run/nologin (@xhienne ha suggerito il file /etc/nologin), rimuovendolo ha risolto il problema.
La condizione esisteva in /usr/lib/tmpfiles.d/systemd.conf
Includerò questo passaggio nel mio script.
sudo rm /run/nologin
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 di /run/login file.
Ecco alcuni dati relativi alle richieste di informazioni in quel bug tracker:
$ 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=
[email protected] 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 [email protected] shutdown.target [email protected] 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 bug tracker e le informazioni di cui sopra sembrano mostrare che il problema è in realtà dovuto a un errore nell'avvio del systemd-user-sessions.service demone.
Questo è infatti ciò che accade nel mio caso, quindi la seguente soluzione corregge temporaneamente la condizione di accesso vietato:
$ sudo systemctl start systemd-user-sessions.service
Dopo aver fatto ciò, il file /run/nologin file non è più presente e, si può SSH da un altro sistema. Si noti, tuttavia, che questo non è affidabile in quanto a volte l'utente non ha accesso alla console del sistema interessato.