Не вдається ssh на сервер після оновлення Debian до Buster без попереднього входу з "надійної машини"

Я щойно модернізував свій сервер Debian з Stretch (стабільний) до Buster (тестування).

Якусь дивну річ я не можу вирішити:

$ ssh vlastimil@192.168.0.102 -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

Однак якщо я входжу як локальний користувач (я можу навіть вийти з нього, йому потрібен лише один логін), він дійсно працює.

Я зміг увійти як 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 chacha20-poly1305@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com
KexAlgorithms curve25519-sha256@libssh.org
FingerprintHash sha512
Match Address 192.168.0.*
    PermitRootLogin yes
Match all
    PermitRootLogin no

Завдяки Телок «s відповіді про Апаратної ГСЧ я зробив apt searchі знайшов пакет rng-tools5і встановив його:

sudo apt-get install rng-tools5

Це вирішило проблему в моєму Intel NUC.

Примітка редактора: Моя проблема щодо Dell PowerEdge T20 з процесором Xeon також була вирішена з цим.

Додаткові нотатки:

• Після встановлення пакета, будь ласка, перевірте, чи є випадкове джерело з:

  rngd -v
  

  У моєму випадку немає пристрою TPM, але процесор має rdrandможливість:

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

connection refusedприпускає, що sshdце не працює.

Це може бути лише питанням часу: коли на консолі з’явиться запит на вхід, це не гарантує, що всі системні служби ще завершили запуск.

sshdможе також затриматися в очікуванні /dev/[u]random, особливо якщо система розташована в мережевому сегменті з дуже невеликим мережевим трафіком. У цьому випадку система має дуже мало джерел справжньої випадковості і має труднощі зібрати достатньо справді випадкових біт для початкового висівання генератора випадкових чисел ядра. Вхід на системну консоль забезпечить деяку випадковість у вигляді найменших бітів часу переривання клавіатури. Якщо в системі є певна форма апаратного RNG, це дозволить усунути цю проблему.

Щоб встановити діагноз, просто введіть кілька рядків дурниць у підказку для входу в консоль без фактичного входу. Якщо sshdпісля цього нормально реагує, ядро, ймовірно, голодувало від випадковості та не змогло запустити RNG ядра, і це призвело sshdдо затримки запуску. .

Або це може бути якась systemdпомилка залежності, яка дозволяє sshdзапускатись лише тоді, коли спочатку починаються процеси, пов’язані з входом. Це було б однією з причин, чому Debian Buster все ще є testingрозповсюдженням: якщо це виявиться причиною, будь ласка, надішліть звіт про помилку.

Пакетне рішення вирішили проблему.

Нитка: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087