システムがSSHを拒否し、systemdのインストール後に「ブートアップ」でスタックする


12

Azureで作成されたLinux Ubuntu VM(14.04 LTS)で再現可能な問題があります。

systemdスクリプトを使用してパッケージをインストールした後、システムは新しいssh接続を無限に拒否します。

システムが起動しています。

xxx.xxx.xxx.xxxによって接続が閉じられました

ただし、アクティブなSSH接続は維持されます。/etc/nologinシステムにファイルがありません。

私が目にする唯一のオプションは、問題を解決するハードリセットです。しかし、どうすればそれを回避できますか?

これが私が使用しているスクリプトです:

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

システムがハングしていますか、それとも単にセキュアシェルデーモンが起動していないのですか?質問は1つを述べています。投稿の本文は、他の投稿である可能性があることを示しています。
DopeGhoti 2017年

@DopeGhotiマシンにリモートで接続できないため、何が起こっているかを確認する方法がありません。質問をわかりやすくするために更新します。
Alex

回答:


15

私はそこにある疑いが/etc/nologinsystemdにインストールした後に除去されていません(その内容は「システムが起動中です。」だろう)、ファイルが。

[更新]あなたに影響するのは昨年12月にUbuntuのBTSで報告されたバグです。それが原因である/var/run/nologinファイル(= /run/nologinので/var/runへのシンボリックリンクである/run)にsystemdインストールの終了時に除去されません。

/etc/nologin標準のnologinファイルです。PAMモジュール()/var/run/nologinが使用できる代替ファイルです。nologinman pam_nologin

nologinrootユーザーによる接続に影響を与えるファイルはなく、通常のユーザーのみがログインできないようになっていることに注意してください。


問題を再現しましたが、/ etc / nologinファイルがありません。アクティブなSSHセッションは維持されますが、マシンを再起動するまで新しいセッションは拒否されます。
Alex

私もチェック/etc/shadowしましたが、アカウントはロックされていません
Alex

@Alex Answerが更新されました。
xhienne

10

@xhienneは正しい方向を教えてくれました。

私が見つけたファイルシステム/run/nologin(@xhienneは/ etc / nologinを推奨)を検索した後、削除して問題を解決しました。

状態は存在した /usr/lib/tmpfiles.d/systemd.conf

このステップをスクリプトに含めます。

sudo rm /run/nologin

うまくいきました。回答を更新しました。
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.

Mageiaディストリビューションのバグトラッカーでは、関連する問題が開いているようです。 バグ21080-再起動後に/ run / nologinによってsshログインが無効にされます

この問題が頻繁に発生した後、トラッカーを見つけることで、単に/ run / loginファイルを削除するよりも適切な回避策を特定できました。

そのバグトラッカーの情報のクエリに関連するいくつかのデータを次に示します。

$ 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

バグ追跡と上記の情報は、問題が実際にsystemd-user-sessions.serviceデーモンの起動に失敗したことが原因であることを示しているようです。

これが実際に私の場合に起こることなので、次の回避策は一時的に禁止されたログイン状態を修正します。

$ sudo systemctl start systemd-user-sessions.service

これを実行すると、/ run / nologinファイルは存在しなくなり、別のシステムからSSHで接続できるようになります。ただし、影響を受けるシステムのコンソールにユーザーがアクセスできない場合があるため、これは信頼性がないことに注意してください。


0

私はこれとまったく同じ問題を抱えていましたが、いくつかのシナリオがそれを引き起こす可能性があると思います。

私の場合、リモートアクセスを再度有効にするには、リモートサーバーへの直接アクセスをKVMに要求してから、

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

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

しかし、KVM画面では、緊急モードで起動したことが実際にわかりました。

以前は、新しいUUIDを生成するディスク/パーティションの変更(inodeの増加)を行っていましたが、/ etc / fstabファイルに追加するのを忘れていました。

コマンドを発行した後:

blkid

...そして、新しいUUIDをfstabファイルにコピーして貼り付けると、問題なくサーバーを再起動でき、その後、リモートSSHアクセスは問題ありませんでした。


0

/ etc / ssh / sshd_configでUsePAMをnoに設定します

UsePAM no

これは何をし、その結果はどうなりますか?
Kusalananda

この答えはこの状況には当てはまらないようです-ユーザーが「システムが起動中です」というテキストが表示される理由や、systemdのインストールによって壊れた構成がどのように生成されたかについては説明しません。
Jeff Schaller
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.