ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

La liste entre crochets reflète les méthodes `Auth` que vous avez configurées. `[none]` seul signifie que le client ne disposait d’aucune méthode utilisable : en général, une slice `Auth` vide ou une clé qui n’a pas pu être chargée.

golang.org/x/crypto/ssh (Go) — ssh.Dial / ssh.NewClientConn

Ce que cela signifie

Le transport SSH a été établi (clé d’hôte acceptée), mais chaque méthode d’authentification essayée par le client a été rejetée, et le serveur n’a rien proposé d’autre que le client puisse utiliser. La liste entre crochets indique ce que le client Go a tenté : `none` est la tentative initiale que tout client SSH envoie, `publickey` signifie que vos clés ont été proposées puis refusées. C’est l’équivalent Go du « Permission denied (publickey) » d’OpenSSH.

Pourquoi cela se produit

• La clé ne figure pas dans le fichier authorized_keys du serveur

  fréquente

  Le programme utilise une autre clé que celle installée sur le serveur (un autre fichier, le secret d’un autre environnement), ou la clé a été ajoutée pour un autre utilisateur.

• Aucune méthode d’authentification utilisable n’a été configurée

  fréquente

  Une slice `Auth` vide, un signataire qui n’a pas pu être chargé et a été ignoré silencieusement, ou un `ssh.PublicKeysCallback` adossé à un agent SSH qui ne détient aucune clé.

• Clé RSA signant en ssh-rsa (SHA-1)

  occasionnelle

  Les serveurs OpenSSH 8.8 et versions ultérieures rejettent les signatures `ssh-rsa`. Les anciennes versions de x/crypto signent par défaut avec SHA-1 lorsque la clé est RSA ; les versions actuelles négocient `rsa-sha2-256/512`. Mettez à jour golang.org/x/crypto ou utilisez une clé Ed25519.

• Mauvais utilisateur distant

  occasionnelle

  La clé est autorisée pour `ubuntu`, mais le client se connecte en tant que `root` ou `deploy`. L’autorisation est propre à chaque utilisateur.

Comment corriger l’erreur

1. 1.

   Charger la clé explicitement et vérifier l’hôte

   Lisez la clé privée, arrêtez-vous sur une erreur explicite si l’analyse échoue, et utilisez `knownhosts` pour la clé d’hôte au lieu de `ssh.InsecureIgnoreHostKey()`.

   keyBytes, err := os.ReadFile(os.ExpandEnv("$HOME/.ssh/id_ed25519"))
   if err != nil {
   	return err
   }
   signer, err := ssh.ParsePrivateKey(keyBytes)
   if err != nil {
   	return err
   }
   hostKeys, err := knownhosts.New(os.ExpandEnv("$HOME/.ssh/known_hosts"))
   if err != nil {
   	return err
   }
   client, err := ssh.Dial("tcp", "server.example.com:22", &ssh.ClientConfig{
   	User:            "deploy",
   	Auth:            []ssh.AuthMethod{ssh.PublicKeys(signer)},
   	HostKeyCallback: hostKeys,
   })

2. 2.

   Comparer les empreintes et lire le journal du serveur

   sshd consigne la raison pour laquelle il a refusé une clé (mauvaises permissions sur `~/.ssh`, algorithme non accepté, utilisateur inconnu). Côté client, on n’apprend jamais la raison.

   ssh-keygen -lf ~/.ssh/id_ed25519.pub                 # fingerprint of the key the program uses
   ssh deploy@server.example.com 'ssh-keygen -lf ~/.ssh/authorized_keys'
   sudo journalctl -u ssh -n 20                         # sshd's reason (modes, algorithms, user)

← Parcourir toute la base de données des erreurs de signature