System odmawia SSH i utknął podczas uruchamiania po instalacji systemowej

Mam problem, który jest odtwarzalny na maszynach wirtualnych z systemem Linux Ubuntu (14.04 LTS) utworzonych na platformie Azure.

Po zainstalowaniu systemdpakietu przez skrypt system nieskończenie odmawia nowych połączeń ssh.

System się uruchamia.

Połączenie zamknięte przez xxx.xxx.xxx.xxx

Aktywne połączenie ssh jest jednak utrzymywane. W /etc/nologinsystemie nie ma pliku.

Jedyną dostępną opcją jest twardy reset, który rozwiązuje problem. Ale jak tego uniknąć?

Oto skrypt, którego używam:

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

Podejrzewam, że istnieje /etc/nologinplik (którego treść to „System uruchamia się.”), Który nie jest usuwany po instalacji systemd.

[aktualizacja] Co dotyczy ciebie, to błąd, który został zgłoszony na BTS Ubuntu w grudniu zeszłego roku. Jest to spowodowane /var/run/nologinplikiem (= /run/nologinponieważ /var/runjest dowiązaniem symbolicznym /run), który nie jest usuwany na końcu instalacji systemowej.

/etc/nologinto standardowy plik nologin. /var/run/nologinto alternatywny plik, który może być używany przez nologinmoduł PAM ( man pam_nologin).

Pamiętaj, że żaden z nologinplików nie wpływa na połączenia przez użytkownika root, tylko zwykli użytkownicy nie mogą się zalogować.

@xhienne dał mi właściwy kierunek.

Po przeszukaniu systemu plików znalazłem /run/nologin(@xhienne sugerowany / etc / nologin) plik, który usunął problem.

Warunek istniał w /usr/lib/tmpfiles.d/systemd.conf

Dołączę ten krok do skryptu.

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.

Wygląda na to, że w narzędziu do śledzenia błędów dystrybucji Mageia jest otwarty powiązany problem: Błąd 21080 - logowanie ssh wyłączone przez / run / nologin po restarcie .

Po dość częstym występowaniu tego problemu znalezienie modułu śledzącego pomogło zidentyfikować obejście, które może być bardziej odpowiednie niż zwykłe usunięcie pliku / run / login .

Oto niektóre dane związane z zapytaniami o informacje w tym narzędziu do śledzenia błędów:

$ 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

Śledzenie błędów i powyższe informacje wydają się wskazywać, że problem jest spowodowany niepowodzeniem uruchomienia demona systemd-user-session.service .

Tak właśnie dzieje się w moim przypadku, więc następujące obejście tymczasowo koryguje zakazany warunek logowania:

$ sudo systemctl start systemd-user-sessions.service

Po wykonaniu tego, plik / run / nologin nie jest już obecny i można SSH z innego systemu. Należy jednak pamiętać, że nie jest to wiarygodne, ponieważ czasami użytkownik nie ma dostępu do konsoli systemu, którego dotyczy problem.

Miałem dokładnie ten sam problem, ale myślę, że można go stworzyć w kilku scenariuszach.

W moim przypadku, aby ponownie włączyć dostęp zdalny, musiałem poprosić KVM o bezpośredni dostęp do naszego zdalnego serwera, a następnie:

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

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

Ale na ekranie KVM widziałem, że uruchomił się w trybie awaryjnym!

Wcześniej dokonywałem pewnych zmian dysku / partycji (zwiększenie i-węzłów), które wygenerowały nowy UUID i zapomniałem dodać go do pliku / etc / fstab.

Po wydaniu polecenia:

blkid

... i skopiuj wklejając nowy UUID do pliku fstab, mogłem ponownie uruchomić serwer bez żadnych problemów, a potem zdalny dostęp SSH był w porządku.

W / etc / ssh / sshd_config ustaw UsePAM na no

UsePAM no