Je soupçonne qu'il y a un /etc/nologin fichier (dont le contenu serait "Le système démarre.") qui n'est pas supprimé après l'installation de systemd.
[mise à jour] Ce qui vous affecte, c'est un bogue qui a été signalé sur le BTS d'Ubuntu en décembre dernier. C'est dû à un /var/run/nologin fichier (=/run/nologin depuis /var/run est un lien symbolique vers /run ) qui n'est pas supprimé à la fin de l'installation de systemd.
/etc/nologin est le fichier nologin standard. /var/run/nologin est un fichier alternatif qui peut être utilisé par le nologin Module PAM (man pam_nologin ).
Notez qu'aucun des nologin affectent les connexions par utilisateur root, seuls les utilisateurs réguliers ne peuvent pas se connecter.
@xhienne m'a donné la bonne direction.
Après avoir cherché dans le système de fichiers, j'ai trouvé /run/nologin (@xhienne a suggéré /etc/nologin), en supprimant ce qui a résolu le problème.
La condition existait dans /usr/lib/tmpfiles.d/systemd.conf
J'inclurai cette étape dans mon 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.
Le bug tracker de la distribution Mageia semble avoir un problème connexe ouvert :Bug 21080 - connexion ssh désactivée par /run/nologin après un redémarrage .
Après avoir rencontré ce problème assez fréquemment, trouver le tracker a permis d'identifier une solution de contournement qui pourrait être plus appropriée que de simplement supprimer le /run/login fichier.
Voici quelques données relatives aux requêtes d'informations dans ce 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
Le bug tracker et les informations ci-dessus semblent montrer que le problème est en fait dû à un échec de démarrage de systemd-user-sessions.service démon.
C'est en fait ce qui se passe dans mon cas, donc la solution de contournement suivante corrige temporairement la condition de connexion interdite :
$ sudo systemctl start systemd-user-sessions.service
Après cela, le /run/nologin le fichier n'est plus présent, et on peut SSH à partir d'un autre système. Notez cependant que ce n'est pas fiable car parfois l'utilisateur n'a pas accès à la console du système concerné.