El sistema rechaza SSH y se atasca en el "arranque" después de la instalación del sistema

Tengo un problema que es reproducible en Linux Ubuntu VM (14.04 LTS) creado en Azure.

Después de instalar el systemdpaquete a través del script, el sistema rechaza las nuevas conexiones ssh, infinitamente.

El sistema se está iniciando.

Conexión cerrada por xxx.xxx.xxx.xxx

Sin embargo, la conexión ssh activa se mantiene. No hay ningún /etc/nologinarchivo presente en el sistema.

La única opción que veo es un restablecimiento completo que resuelve el problema. ¿Pero cómo lo evito?

Aquí está el script que estoy 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

Sospecho que hay un /etc/nologinarchivo (cuyo contenido sería "El sistema se está iniciando") que no se elimina después de la instalación del sistema.

[actualización] Lo que le afecta es un error que se informó en el BTS de Ubuntu en diciembre pasado. Se debe a un /var/run/nologinarchivo (= /run/nologinya que /var/runes un enlace simbólico a /run) que no se elimina al final de la instalación de systemd.

/etc/nologines el archivo estándar de nologin. /var/run/nologines un archivo alternativo que puede ser usado por el nologinmódulo PAM ( man pam_nologin).

Tenga en cuenta que ninguno de los nologinarchivos afecta las conexiones por usuario root, solo los usuarios normales no pueden iniciar sesión.

@xhienne me dio la dirección correcta.

Después de buscar a través del sistema de archivos, encontré el archivo /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 un problema relacionado abierto: Bug 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 el archivo / run / login .

Aquí hay algunos datos relacionados con las 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 se debe realmente a una falla al iniciar el daemon systemd-user-sessions.service .

De hecho, esto es lo que sucede en mi caso, por lo que la siguiente solución temporal corrige temporalmente la condición de inicio de sesión prohibido:

$ sudo systemctl start systemd-user-sessions.service

Después de hacer esto, el archivo / run / nologin ya no está presente y uno puede SSH desde otro sistema. Sin embargo, tenga en cuenta que esto no es confiable ya que a veces el usuario no tiene acceso a la consola del sistema afectado.

Tuve exactamente el mismo problema, pero creo que varios escenarios pueden crearlo.

En mi caso, para habilitar el acceso remoto nuevamente tuve que solicitar a KVM el acceso directo a nuestro servidor remoto y luego:

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

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

¡Pero en la pantalla KVM pude ver que arrancó en modo de emergencia!

Anteriormente, había estado haciendo algunos cambios en el disco / partición (aumentando los inodos) que generaron un nuevo UUID y olvidé agregarlo al archivo / etc / fstab.

Después de emitir el comando:

blkid

... y copiar y pegar el nuevo UUID en el archivo fstab, pude reiniciar el servidor nuevamente sin problemas y el acceso remoto SSH estuvo bien después de eso.

En / etc / ssh / sshd_config establezca UsePAM en no

UsePAM no