Der Anmeldeversuch bei einem ESXi-Server führt zum Fehler "Keine unterstützten Authentifizierungsmethoden verfügbar (Server gesendet: öffentlicher Schlüssel)"

Der SSH-Anmeldeversuch bei einem ESXi-Server führt zu dem Fehler "Keine unterstützten Authentifizierungsmethoden verfügbar (Server gesendet: öffentlicher Schlüssel)" wie folgt:

Beim Versuch, sich von einem anderen ESXi-Server anzumelden, wird der folgende Fehler angezeigt:

Der Server lehnt die SSH-Sitzung ab, da der Parameter "challengeresponseauthentication" in der sshd_config Datei auf "no" festgelegt ist und die Server nicht ordnungsgemäß für die asymmetrische Authentifizierung (öffentliche RSA-Authentifizierung und Authentifizierung mit privatem Schlüssel) konfiguriert sind.
Infolgedessen führt der Versuch, mit PuTTY eine Verbindung zum Server herzustellen, zu dem Fehler "Keine unterstützten Authentifizierungsmethoden verfügbar (Server gesendet: publickey).

Ein ähnliches Verhalten wird beobachtet, wenn der Nutzer versucht, eine SSH-Verbindung von einem anderen ESXi-Host herzustellen. In diesem Fall erhält der Benutzer die Fehlermeldung "Ladeschlüssel '/.ssh/id_rsa': Fehler in libcrypto", wird aber nicht aufgefordert, das Passwort einzugeben, und die Verbindung schlägt fehl.

Wenn die Server nicht ordnungsgemäß für die asymmetrische Authentifizierung konfiguriert sind, der Parameter "ChallengeResponseAuthentication" jedoch auf "yes" festgelegt ist, erhält der Benutzer eine Fehlermeldung, wird dann jedoch aufgefordert, sein Kennwort einzugeben. Nach der korrekten Eingabe des Kennworts wird die Verbindung erfolgreich hergestellt.

Stellen Sie über die DCUI eine Verbindung zur Zielserverkonsole her und ändern Sie dann challengeresponseauthenticationin der Konfigurationsdatei /etc/ssh/sshd_config in yes.

ChallengeResponse-Authentifizierung
Die Einstellung ChallengeResponseAuthentication gibt an, ob die Challenge-Response-Authentifizierung für SSH-Verbindungen zulässig ist. Wenn diese Option aktiviert ist, erfordert der SSH-Server, dass Clients auf eine Abfrage reagieren, bevor sie sich authentifizieren können. Sie ist in einigen SSH-Serverimplementierungen standardmäßig aktiviert, kann aber aus Sicherheitsgründen auf einigen Systemen deaktiviert sein, z. B. in Red Hat, wie im Red Hat-Artikel 336773 beschrieben.

ChallengeResponseAuthentication ist ein veralteter Alias für KbdInteractiveAuthentication. Referenz: OpenSSH: Versionshinweise

Weitere Details:

• Die Kombination aus dem Festlegen von challengeresponseauthentication und passwordauthentication erzeugt eine etwas andere Eingabeaufforderung:

  ChallengeResponseAuthentication auf Nein und PasswordAuthentication auf Ja festgelegt:
  

  challengeresponseauthentication wird auf no und passwordauthentication auf yes festgelegt oder beide sind auf yes festgelegt:
  

Weitere Schritte zur Fehlerbehebung:

• Verwenden Sie clientseitig die Option -v im SSH-Befehl, um Debugging-Meldungen zum SSH-Fortschritt auszugeben. Mehrere -v-Optionen erhöhen die Ausführlichkeit (das Maximum ist 3):
  

  …
  

• Erhöhen Sie auf dem Zielserver die Ausführlichkeit der Einstellung LogLevel , um weitere Details zum fehlgeschlagenen SSH-Sitzungsversuch abzurufen:

  Log-Level
  Gibt den Ausführlichkeitsgrad an, der verwendet wird, wenn Nachrichten von sshd(8) protokolliert werden. Mögliche Werte sind: LEISE, SCHWERWIEGEND, FEHLER, INFO, AUSFÜHRLICH, DEBUGGEN, DEBUG1, DEBUG2 und DEBUG3 Der Standardwert ist INFO. DEBUG und DEBUG1 sind äquivalent. DEBUG2 und DEBUG3 geben jeweils höhere Ebenen der Debuggingausgabe an. Die Protokollierung mit einer DEBUG-Ebene verletzt die Privatsphäre der Benutzer und wird nicht empfohlen.

• Überprüfen Sie die /var/run/log/auth.log auf dem Zielserver, um weitere Details zum Fehler zu erhalten.