☰

Warum generiert das RHEL8-System SSH-Hostschlüssel nicht automatisch, wenn sie fehlen?

tag-icon • tag-icon ssh ssh-keys cloud-init rhel8
Warum generiert das RHEL8-System SSH-Hostschlüssel nicht automatisch, wenn sie fehlen?

Unter RHEL 8 und früheren Versionen ist es üblich, dass die SSH-Hostschlüssel /etc/sshautomatisch vom sshdDienst generiert werden, wenn sie fehlen. Normalerweise sollte Folgendes vorhanden sein:

/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub

Ein Neustart des Knotens oder sogar ein Neustart systemctl restart sshdsollte ausreichen.

Aber ab der Nebenversion RHEL 8.7 funktioniert das möglicherweise nicht mehr und die sshdAbstürze melden fehlende Hostschlüssel im Journalprotokoll. Warum? Wie kann ich das lösen?

Antwort1

Der sshdDienst ruft standardmäßig auf sshd-keygen.target, der die Verfügbarkeit von Hostschlüsseln im /etc/sshVerzeichnis überprüft und diese generiert, wenn sie fehlen.

Diese bekannte Funktionalität kann jedoch durch die neue Version von blockiert werden cloud-init. Ab cloud-init-22.1-5.el8.noarchgibt es eine neue Datei:

/etc/systemd/system/[email protected]/disable-sshd-keygen-if-cloud-init-active.conf

mit Inhalt:

# In some cloud-init enabled images the sshd-keygen template service may race
# with cloud-init during boot causing issues with host key generation.  This
# drop-in config adds a condition to [email protected] if it exists and
# prevents the sshd-keygen units from running *if* cloud-init is going to run.
#
[Unit]
ConditionPathExists=!/run/systemd/generator.early/multi-user.target.wants/cloud-init.target

Wenn Sie das verwenden, cloud-inithaben Sie jetzt zwei Optionen:

  1. Hostschlüssel manuell generieren mit ssh-keygen -A(sieheWie ändere ich einen SSH-Hostschlüssel?für weitere Details und Optionen.
  2. Kommentieren Sie die Bedingung

Setzen Sie einfach das #Zeichen vorConditionPathExists...

[Unit]
#ConditionPathExists=!/run/systemd/generator.early/multi-user.target.wants/cloud-init.target

Laden Sie anschließend die systemd-Konfiguration mit neu systemctl daemon-reload. Das gewohnte Verhalten sollte nun wieder funktionieren.

Antwort2

Wenn Sie Cloud-Init verwenden, können Sie das Problem beheben, indem Sie das Modul „ssh“ in der Cloud-Init-Konfigurationsdatei im Abschnitt „cloud_init_modules“ hinzufügen. SieheCloud-Init-Dokumente

Dadurch wird beim ersten Start ein SSH-Hostschlüssel generiert.

Sie können dies testen, wenn bei Ihnen ein Problem auftritt:

cloud-init config file: /etc/cloud/cloud.cfg
Check if you have 'ssh' module in "cloud_init_modules" section
Run this command to verify cloud-init action. NOTE: This will REBOOT your instance and run the cloud-init action from the scratch.
# cloud-init clean --reboot

Überprüfen Sie den SSH-Hostschlüssel im Verzeichnis /etc/ssh/ und den SSHD-Dienststatus.

Antwort3

Versuchen Sie, SSH-Schlüsseltypen explizit in cloud.cfg festzulegen

resize_rootfs_tmp: /dev
ssh_deletekeys:   1
ssh_genkeytypes: ['rsa', 'ecdsa', 'ed25519']

verwandte Informationen