Il tentativo di accesso a un server ESXi genera l'errore "No supported authentication methods available (server sent: publickey)"
Summary: Questo articolo fornisce una guida dettagliata sulla risoluzione dei problemi SSH dal punto di vista di ESXi. Tuttavia, i concetti e le soluzioni discussi qui sono applicabili anche ad altri sistemi operativi basati su Linux, rendendo queste informazioni preziose per una gamma più ampia di ambienti. ...
Symptoms
Il tentativo di accesso SSH a un server ESXi genera l'errore "No supported authentication methods available (server inviato: publickey)" come indicato di seguito:
Quando si tenta di accedere da un ESXi server diverso, viene visualizzato il seguente errore:
Cause
Il server rifiuta la sessione SSH perché il parametro "challengeresponseauthentication" nel file sshd_config è impostato su "no" e i server non sono configurati correttamente per l'autenticazione asimmetrica (autenticazione con chiave pubblica e privata RSA).
Di conseguenza, il tentativo di connettersi al server utilizzando Putty genera l'errore "Nessun metodo di autenticazione supportato disponibile (server inviato: chiave pubblica).
Un comportamento simile viene osservato quando l'utente tenta di stabilire una connessione SSH da un altro host ESXi. In questo caso, l'utente riceve l'errore "Load key '/.ssh/id_rsa': error in libcrypto" ma non gli viene richiesto di inserire la password e la connessione non riesce.
Se i server non sono configurati correttamente per l'autenticazione asimmetrica, ma il parametro "ChallengeResponseAuthentication" è impostato su "yes", l'utente riceve un messaggio di errore, ma poi gli viene richiesto di immettere la password. Dopo aver inserito correttamente la password, la connessione viene stabilita correttamente.
Resolution
Connettersi alla console del server di destinazione utilizzando DCUI, quindi modificare challengeresponseauthentication in yes nel file di configurazione /etc/ssh/sshd_config.
ChallengeResponseAuthentication
L'impostazione ChallengeResponseAuthentication specifica se l'autenticazione challenge-response è consentita per le connessioni SSH. Quando questa opzione è abilitata, il server SSH richiede che i client rispondano a una richiesta prima di consentire loro di eseguire l'autenticazione. È abilitata per impostazione predefinita in alcune implementazioni di server SSH, ma potrebbe essere disabilitata per motivi di sicurezza su alcuni sistemi, come in Red Hat, come descritto nell'articolo 336773 di Red Hat.
ChallengeResponseAuthentication è un alias deprecato per KbdInteractiveAuthentication. Riferimento: OpenSSH: Note di rilascio
Additional Information
Maggiori dettagli:
-
La combinazione di impostazione challengeresponseauthentication e passwordauthentication produce un prompt leggermente diverso:
ChallengeResponseAuthentication impostato su No e PasswordAuthentication impostato su Yes:

challengeresponseauthentication impostato su no e passwordauthentication impostato su yes OPPURE entrambi impostati su yes:

Altri passaggi per la risoluzione dei problemi:
-
Dal lato client, utilizzare l'opzione -v nel comando ssh per stampare i messaggi di debug sull'avanzamento di ssh. Più opzioni -v aumentano il livello di dettaglio (il valore massimo è 3):

…

-
Nel server di destinazione, aumentare il livello di dettaglio dell'impostazione LogLevel
per recuperare ulteriori dettagli sul tentativo di sessione SSH non riuscito:
LogLevel
Fornisce il livello di dettaglio usato quando si registrano i messaggi da sshd(8).The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2 e DEBUG3 L'impostazione predefinita è INFO. DEBUG e DEBUG1 sono equivalenti. DEBUG2 e DEBUG3 specificano ciascuno livelli più elevati di output di debug. La registrazione con un livello DEBUG viola la privacy degli utenti e non è consigliata.
- Esaminare /var/run/log/auth.log nel server di destinazione per ulteriori dettagli sull'errore.