DebianをBusterにアップグレードした後、以前に「信頼できるコンピュータ」にログインしていないと、サーバーにSSH経由で接続できません。

DebianをBusterにアップグレードした後、以前に「信頼できるコンピュータ」にログインしていないと、サーバーにSSH経由で接続できません。

DebianサーバーをStretch(安定)からBuster(テスト)にアップグレードしました。

解決できない奇妙なことが1つあります。

$ ssh [email protected] -p [censored] -o ConnectTimeout=5 -i /home/vlastimil/.ssh/id_rsa -vvv

結果:

OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "192.168.0.102" port [censored]
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.0.102 [192.168.0.102] port [censored].
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 192.168.0.102 port [censored]: Connection refused

ssh: connect to host 192.168.0.102 port [censored]: Connection refused


ただし、そのユーザーとしてローカルにログインすると(ログアウトすることも、1回のログインのみが必要です)、機能します。

rootとしてログインできます。ただし、公開鍵交換は1つのシステムでのみ実行できます。

また、そのコンピュータでrootとして一度だけログインすると、他のコンピュータからrootとしてログインできます。

この問題をデバッグする方法を詳しく説明できる人はいますか?


サーバー構成:

# grep -v '#' /etc/ssh/sshd_config

Port [censored]
Protocol 2
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
StrictModes yes
HostbasedAuthentication no
IgnoreRhosts yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
PrintLastLog no
Banner none
AcceptEnv LANG LC_*
Subsystem   sftp    /usr/lib/openssh/sftp-server
KeyRegenerationInterval 3600
ServerKeyBits 4096
Ciphers [email protected],[email protected]
MACs [email protected]
KexAlgorithms [email protected]
FingerprintHash sha512
Match Address 192.168.0.*
    PermitRootLogin yes
Match all
    PermitRootLogin no

答え1

ありがとう通信会社~の回答ハードウェアRNGに関して1つを作成し、パッケージを見つけてインストールしapt searchましrng-tools5た。

sudo apt-get install rng-tools5

これはIntel NUCの問題を解決しました。


編集者注:Xeon CPUを使用するDell PowerEdge T20で発生した問題も解決されました。

その他の注意:

  • パッケージをインストールしたら、任意のソースを確認してください。

    rngd -v
    

    私の場合、TPMデバイスはありませんが、CPUはrdrand次のことができます。

    Unable to open file: /dev/tpm0
    Available entropy sources:
        DRNG
    

答え2

connection refusedsshd実行されていないことを示します。

おそらく時間の問題でしょう。ログインプロンプトがコンソールに表示されると、すべてのシステムサービスの起動が完了したという保証はありません。

sshd/dev/[u]random特に、システムがネットワークトラフィックが少ないセグメントにある場合は、待機状態になる可能性があります。この場合、システムで使用できる実際のランダム性のソースはほとんどなく、最初にカーネルの乱数ジェネレータをシードするのに十分な実際のランダムビットを収集することは困難です。システムコンソールにログインすると、キーボード割り込み呼び出しタイミングで最も低いビット形式でランダム性が得られます。システムに何らかの形でハードウェアRNGがある場合は、それを有効にするとこの問題が解決される可能性があります。

診断するには、実際にはログインせず、コンソールログインプロンプトに不明な数行を入力するだけです。その後、応答が正常な場合、sshdカーネルにランダム性が不足し、カーネルRNGをシードできず、起動が遅れる可能性がsshdあります。

あるいは、ログイン関連のプロセスが初めて起動したときにのみ起動することを可能にするsystemd依存関係のバグの一種です。sshdこれがDebian Busterがまだディストリビューションである理由の1つですtesting。これが理由ならバグレポートを送ってください。

答え3

このパッケージはこの問題を解決しました。

糸: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087

関連情報