Sospecho que hay un /etc/nologin (cuyo contenido sería "El sistema se está iniciando") que no se elimina después de la instalación de systemd.
[actualización] Lo que le afecta es un error que se informó en BTS de Ubuntu en diciembre pasado. Se debe a un /var/run/nologin archivo (=/run/nologin desde /var/run es un enlace simbólico a /run ) que no se elimina al final de la instalación de systemd.
/etc/nologin es el archivo nologin estándar. /var/run/nologin es un archivo alternativo que puede ser utilizado por nologin Módulo PAM (man pam_nologin ).
Tenga en cuenta que ninguno de los nologin los archivos afectan a las conexiones del usuario raíz, solo los usuarios normales no pueden iniciar sesión.
@xhienne me dio la dirección correcta.
Después de buscar en el sistema de archivos, encontré /run/nologin (@xhienne sugirió /etc/nologin), eliminando lo que resolvió el problema.
La condición existía en /usr/lib/tmpfiles.d/systemd.conf
Incluiré este paso en mi guión.
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.
El rastreador de errores de distribución de Mageia parece tener abierto un problema relacionado:error 21080:inicio de sesión ssh deshabilitado por /run/nologin después de un reinicio.
Después de experimentar este problema con bastante frecuencia, encontrar el rastreador ayudó a identificar una solución alternativa que podría ser más apropiada que simplemente eliminar /run/login archivo.
Aquí hay algunos datos relacionados con consultas de información en ese rastreador de errores:
$ 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
El rastreador de errores y la información anterior parecen mostrar que el problema en realidad se debe a un error al iniciar el systemd-user-sessions.service demonio.
De hecho, esto es lo que sucede en mi caso, por lo que la siguiente solución corrige temporalmente la condición de inicio de sesión prohibido:
$ sudo systemctl start systemd-user-sessions.service
Después de hacer esto, el /run/nologin El archivo ya no está presente y uno puede usar SSH desde otro sistema. Tenga en cuenta, sin embargo, que esto no es confiable ya que a veces el usuario no tiene acceso a la consola del sistema afectado.