Das System lehnt SSH ab und bleibt nach der Installation von systemd beim Hochfahren hängen


11

Ich habe ein Problem, das auf Linux-Ubuntu-VMs (14.04 LTS) reproduzierbar ist, die in Azure erstellt wurden.

Nach der Installation des systemdPakets über ein Skript lehnt das System neue SSH-Verbindungen unendlich ab.

Das System startet.

Verbindung geschlossen durch xxx.xxx.xxx.xxx

Die aktive SSH-Verbindung bleibt jedoch erhalten. /etc/nologinIm System ist keine Datei vorhanden.

Die einzige Option, die ich sehe, ist ein Hard-Reset, der das Problem löst. Aber wie vermeide ich das?

Hier ist das Skript, das ich verwende:

#!/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

Hängt das System oder startet es einfach nicht den Secure Shell Daemon? Die Frage lautet eins; Der Körper des Beitrags impliziert, dass es durchaus der andere sein könnte.
DopeGhoti

@DopeGhoti Ich kann nicht überprüfen, was gerade passiert, da ich keine Remote-Verbindung zum Computer herstellen kann. Ich werde die Frage aktualisieren, um sie klarer zu machen.
Alex

Antworten:


14

Ich vermute, dass es eine /etc/nologinDatei gibt (deren Inhalt "System startet"), die nach der Installation von systemd nicht entfernt wird.

[Update] Was Sie betrifft, ist ein Fehler, der im vergangenen Dezember auf Ubuntus BTS gemeldet wurde . Dies liegt an einer /var/run/nologinDatei (= /run/nologinda /var/runist ein Symlink zu /run), die am Ende der systemd-Installation nicht entfernt wird.

/etc/nologinist die Standard-Nologin-Datei. /var/run/nologinist eine alternative Datei, die vom nologinPAM-Modul ( man pam_nologin) verwendet werden kann.

Beachten Sie, dass sich keine der nologinDateien auf Verbindungen nach Benutzer root auswirkt. Es wird verhindert, dass sich nur normale Benutzer anmelden.


Ich habe das Problem reproduziert, es ist keine / etc / nologin-Datei vorhanden. Die aktive SSH-Sitzung wird beibehalten, neue werden jedoch abgelehnt, bis ich den Computer neu starte.
Alex

Ich habe auch überprüft /etc/shadowund das Konto ist nicht gesperrt
Alex

@ Alex Antwort aktualisiert.
Xhienne

10

@xhienne gab mir die richtige Richtung.

Nachdem ich das Dateisystem durchsucht hatte, fand ich eine Datei /run/nologin(@xhienne schlug / etc / nologin vor), die das Problem löste.

Die Bedingung bestand in /usr/lib/tmpfiles.d/systemd.conf

Ich werde diesen Schritt in mein Skript aufnehmen.

sudo rm /run/nologin

Ich bin froh, dass es funktioniert. Ich habe meine Antwort aktualisiert.
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.

Der Mageia Distribution Bug Tracker scheint ein verwandtes Problem zu haben: Bug 21080 - SSH-Anmeldung durch / run / nologin nach einem Neustart deaktiviert .

Nachdem dieses Problem häufig aufgetreten ist, hat das Auffinden des Trackers dazu beigetragen, eine Problemumgehung zu finden, die geeigneter sein könnte, als einfach die Datei / run / login zu entfernen .

Hier sind einige Daten zu Fragen nach Informationen in diesem 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=
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

Der Bug-Tracker und die obigen Informationen scheinen zu zeigen, dass das Problem tatsächlich auf einen Fehler beim Starten des Dämons systemd-user- session.service zurückzuführen ist.

Dies ist in der Tat der Fall in meinem Fall. Die folgende Problemumgehung korrigiert vorübergehend die gesperrte Anmeldebedingung:

$ sudo systemctl start systemd-user-sessions.service

Danach ist die Datei / run / nologin nicht mehr vorhanden und man kann SSH von einem anderen System ausführen . Beachten Sie jedoch, dass dies nicht zuverlässig ist, da der Benutzer manchmal keinen Zugriff auf die Konsole des betroffenen Systems hat.


0

Ich hatte genau das gleiche Problem, aber ich denke, dass mehrere Szenarien es schaffen können.

In meinem Fall musste ich KVM um direkten Zugriff auf unseren Remote-Server bitten, um den Remotezugriff wieder zu aktivieren, und dann:

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

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

Aber auf dem KVM-Bildschirm konnte ich tatsächlich sehen, dass es in den Notfallmodus gestartet wurde!

Zuvor hatte ich einige Änderungen an der Festplatte / Partition vorgenommen (Erhöhung der Inodes), die eine neue UUID generierten, und vergessen, die Datei / etc / fstab hinzuzufügen.

Nach der Ausgabe des Befehls:

blkid

... und durch Kopieren der neuen UUID in die fstab-Datei konnte ich den Server ohne Probleme erneut starten und der Remote-SSH-Zugriff war danach in Ordnung.


0

Setzen Sie in der Datei / etc / ssh / sshd_config UsePAM auf no

UsePAM no

Was würde dies tun und was wären die Konsequenzen?
Kusalananda

Diese Antwort scheint nicht auf diese Situation zuzutreffen. Sie erklärt nicht, warum der Benutzer den Text "System bootet" sieht oder wie die Installation von systemd die fehlerhafte Konfiguration generiert hat.
Jeff Schaller
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.