La tentative de connexion à un ESXi server entraîne l’erreur « Aucune méthode d’authentification prise en charge n’est disponible (serveur envoyé : clé publique) »

La tentative de connexion SSH à un serveur ESXi entraîne l’erreur « Aucune méthode d’authentification prise en charge disponible (serveur envoyé : clé publique) », comme suit :

Lorsque vous tentez de vous connecter à partir d’un autre serveur ESXi, le message d’erreur suivant s’affiche :

Le serveur refuse la session SSH car le paramètre « challengeresponseauthentication » du fichier sshd_config est défini sur « no » et que les serveurs ne sont pas correctement configurés pour l’authentification asymétrique (authentification par clé publique et privée RSA).
Par conséquent, la tentative de connexion au serveur à l’aide de Putty entraîne l’erreur « Aucune méthode d’authentification prise en charge n’est disponible (serveur envoyé : clé publique).

Un comportement similaire est observé lorsque l’utilisateur tente d’établir une connexion SSH à partir d’un autre hôte ESXi. Dans ce cas, l’utilisateur reçoit l’erreur « Load key '/.ssh/id_rsa' : error in libcrypto » mais n’est pas invité à saisir le mot de passe et la connexion échoue.

Si les serveurs ne sont pas correctement configurés pour l’authentification asymétrique, mais que le paramètre « ChallengeResponseAuthentication » est défini sur « yes », l’utilisateur reçoit un message d’erreur, mais est ensuite invité à saisir son mot de passe. Une fois le mot de passe saisi correctement, la connexion est établie avec succès.

Connectez-vous à la console du serveur cible à l’aide de l’interface DCUI, puis définissez le paramètre challengeresponseauthentication sur yes dans le fichier de configuration /etc/ssh/sshd_config.

Authentification ChallengeResponseAuthentication
Le paramètre ChallengeResponseAuthentication spécifie si l’authentification de défi-réponse est autorisée pour les connexions SSH. Lorsque cette option est activée, le serveur SSH exige que les clients répondent à un défi avant de les autoriser à s’authentifier. Il est activé par défaut dans certaines implémentations de serveur SSH, mais il peut être désactivé pour des raisons de sécurité sur certains systèmes, comme dans Red Hat, comme décrit dans l’article 336773 Red Hat.

ChallengeResponseAuthentication est un alias obsolète de KbdInteractiveAuthentication. Références : OpenSSH : Notes de mise à jour

Plus de détails :

• La combinaison de la définition de challengeresponseauthentication et de l’authentification par mot de passe produit une invite légèrement différente :

  ChallengeResponseAuthentication défini sur No et PasswordAuthentication défini sur Yes :
  

  challengeresponseauthentication défini sur no et passwordauthentication défini sur yes OU les deux définis sur yes :
  

Autres étapes de dépannage :

• Du côté client, utilisez l’option -v dans la commande ssh pour imprimer les messages de débogage sur la progression de ssh. Plusieurs options en -v augmentent le niveau de détail (la valeur maximale est de 3) :
  

  …
  

• Sur le serveur cible, augmentez le niveau de verbosité du paramètre LogLevel pour récupérer plus de détails sur la tentative de session SSH qui a échoué :

  Niveau
  de journalisation Donne le niveau de verbosité utilisé lors de la journalisation des messages de sshd(8). Les valeurs possibles sont les suivantes : QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2 et DEBUG3 La valeur par défaut est INFO. DEBUG et DEBUG1 sont équivalents. DEBUG2 et DEBUG3 spécifient chacun des niveaux supérieurs de sortie de débogage. La journalisation avec un niveau DEBUG viole la vie privée des utilisateurs et n’est pas recommandée.

• Passez en revue le fichier /var/run/log/auth.log dans le serveur cible pour plus de détails sur l’erreur.