web-dev-qa-db-ja.com

Debianをバスターにアップグレードした後、「信頼されたマシン」からの以前のログインなしではサーバーに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台のマシンからのみ。

さらに、必要なその1つのマシンからのrootログインは1つだけであり、他のマシンから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
debiansshsshd
6
LinuxSecurityFreak

telcoM のおかげで answer ハードウェアRNGについて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
7
jelloir

connection refusedは、sshdが実行されていないことを示しています。

時間の問題かもしれません。ログインプロンプトがコンソールに表示されても、すべてのシステムサービスが起動を完了していることは保証されません。

sshdも/dev/[u]randomで待機している可能性があり、特にシステムがネットワークトラフィックが非常に少ないネットワークセグメントに配置されている場合はなおさらです。この場合、システムには利用可能な真のランダム性のソースがほとんどなく、カーネルの乱数ジェネレータを最初にシードするのに十分な真のランダムビットを収集することが困難です。システムコンソールにログオンすると、キーボードの割り込み呼び出し時間の最下位ビットという形でランダム性が提供されます。システムに何らかの形式のハードウェアRNGがある場合、有効にするとこの問題が解決する可能性があります。

診断するには、実際にログインせずに、コンソールのログインプロンプトに数行のナンセンスを入力するだけです。その後、sshdが正常に応答する場合、カーネルはランダム性に乏しく、カーネルRNGをシードできません。 sshdの起動を遅らせます。

または、ログイン関連のプロセスが最初に開始されたときにのみsystemdの起動を許可する、ある種のsshd依存関係のバグである可能性があります。それがDebian Busterがtestingディストリビューションである理由の1つです。これが原因であることが判明した場合は、バグレポートを送信してください。

7
telcoM

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

スレッド： https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087

2
igi