Einleitung
Es liegt ein Softwarekompatibilitätsproblem zwischen HXDP [3.5(x), 4.0(x)] und ESXi 6.7P04 (Build 17167734) und höher vor. Kunden sollten diese Softwarekombination vermeiden.
HINWEIS: Dieses Problem gilt für alle 6.7 ESXi-Versionen über 6.7P04.
Das Kompatibilitätsproblem wurde in HXDP 4.0(2e) behoben. Dieses Problem hat keine Auswirkungen auf HXDP 4.5(1a) und höher.
Anforderungen
ESXi 6.7P04 (Build 17167734) und höher
HXDP-Version - 3.5(x), 4.0(x)
Weitere Informationen
Mangel
Die zugehörige Bug-ID lautet CSCv88204
- ESXi OpenSSH-Interoperabilitätsproblem mit HXDP
Das Problem tritt in ESXi 6.7P04 auf, da VMware die openSSH-Bibliothek auf OpenSSH_8.3p1 aktualisiert. Diese neue Version von OpenSSH entfernt die Unterstützung für die Schlüsselaustauschmethode, die intern von HXDP verwendet wird, wenn die Kommunikation mit ESXi direkt über SSH erfolgt. Im Folgenden finden Sie einen Ausschnitt aus dem OpenSSH-Änderungsprotokoll, der die grundlegenden Änderungen in dieser Version beschreibt:
ssh(1), sshd(8): this release removes diffie-hellman-group14-sha1 from the default key exchange proposal for both the client and server.
Software-Beratung
Weitere Informationen finden Sie im Software Advisory - Cisco Software Advisory für ESXi 6.7 P04
Betroffene Gebiete
Einige funktionale Bereiche von HX sind betroffen, darunter:
- Neuerstellung des Clusters (schlägt möglicherweise fehl, Algorithmusaushandlung schlägt fehl)

- Cluster-Erweiterung (schlägt möglicherweise fehl, wenn Algorithm-Aushandlung fehlschlägt)

- Cluster-Neuregistrierung (die stcli-Cluster-Neuregistrierung schlägt möglicherweise fehl, wenn "Algorithmusaushandlung fehlgeschlagen" ist)

- Seite mit Systeminformationen in HX Connect
- Upgrades können fehlschlagen, wenn die SSH-Verbindung zum Host nicht hergestellt werden konnte oder während des Upgrades Fehler aufgetreten sind.
ESXi-Upgrades schlagen mit SSH-Ausnahme fehl.
2020-12-16-10:31:04.675 [] [vmware-upgrade-pool-9] FEHLER c.s.sysmgmt.stMgr.SshScpUtilImpl - Fehler beim Herstellen der SSH-Verbindung zum Host: Host ist nicht erreichbar oder befindet sich im Sperrmodus
com.jcraft.jsch.JSchAusnahme: Algorithmusaushandlung fehlgeschlagen


- Potenziell andere Bereiche
Problemumgehung
Die HXDP-Versionshinweise wurden aktualisiert, um speziell darauf hinzuweisen, dass diese Version von 6.7 für die Versionen 3.5(x) und 4.0(x) nicht unterstützt wird. Dieses Problem wurde im HXDP 4.0-Patch - 4.0(2e) und in allen Versionen 4.5(1a) und höher behoben.
- Verwenden Sie den in ESXi integrierten Rollback-Mechanismus, um ein Rollback auf eine kompatible ESXi-Version durchzuführen.
- Eine weitere mögliche Problemumgehung besteht darin, die entfernte Schlüsselaustauschmethode erneut zu aktivieren, indem sshd_config auf jedem ESXi-Host aktualisiert und der SSH-Dienst neu gestartet wird.Es wird empfohlen, diese Problemumgehung nur vorübergehend zu implementieren.
HINWEIS: Ziel sollte es sein, den Cluster auf eine feste HXDP-Version zu verschieben und diese Problemumgehung so schnell wie möglich zu entfernen. Cluster sollten langfristig nicht in diesem Zustand verbleiben, wenn diese zusätzliche Einstellung für den Schlüsselalgorithmus zu "sshd_config" hinzugefügt wird.
Schritte für Workarounds
Wenn Sie HXDP nicht auf eine feste Version aktualisieren können, verwenden Sie die folgenden Problemumgehungen:
Problemumgehung 1
- Verwenden Sie den in ESXi integrierten Rollback-Mechanismus, um ein Rollback auf eine kompatible ESXi-Version durchzuführen. Weitere Informationen finden Sie unter vmware KB - https://kb.vmware.com/s/article/1033604
Problemumgehung 2
Aktivieren Sie die entfernte Schlüsselaustauschmethode erneut, indem Sie sshd_config auf jedem ESXi-Host aktualisieren und den SSH-Dienst neu starten.
- Fügen Sie +diffie-hellman-group14-sha1 unter /etc/ssh/sshd_config auf jedem ESXi-Host zu den KexAlgorithms hinzu.
# echo "KexAlgorithms +diffie-hellman-group14-sha1" >> /etc/ssh/sshd_config
- Bestätigen Sie, dass KexAlgorithms +diffie-hellman-group14-sha1 in der Datei /etc/ssh/sshd_config angezeigt wird.

- ESXi SSH-Prozess neu starten
# /etc/init.d/SSH restart

- Starten Sie den zuvor fehlgeschlagenen Workflow erneut, oder setzen Sie ihn fort.