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

Die Liste in eckigen Klammern spiegelt die Methoden in `Auth` wider, die du konfiguriert hast. `[none]` allein bedeutet, dass der Client überhaupt keine nutzbare Methode hatte – typischerweise ein leerer Slice `Auth` oder ein Schlüssel, der sich nicht laden ließ.

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

Was der Fehler bedeutet

Der SSH-Transport wurde aufgebaut (Host-Schlüssel akzeptiert), aber jede Authentifizierungsmethode, die der Client versucht hat, wurde abgelehnt, und der Server hat nichts weiter angeboten, was der Client tun könnte. Die Liste in eckigen Klammern zeigt, was der Go-Client versucht hat: `none` ist die erste Probeanfrage, die jeder SSH-Client sendet, `publickey` bedeutet, dass deine Schlüssel angeboten und abgelehnt wurden. Das ist das Go-Gegenstück zu „Permission denied (publickey)“ von OpenSSH.

Warum der Fehler auftritt

• Der Schlüssel steht nicht in authorized_keys auf dem Server

  häufig

  Das Programm verwendet einen anderen Schlüssel als den auf dem Server installierten (eine andere Datei, das Secret einer anderen Umgebung), oder der Schlüssel wurde für einen anderen Benutzer hinzugefügt.

• Keine nutzbare Authentifizierungsmethode konfiguriert

  häufig

  Ein leerer Slice `Auth`, ein Signierer, der sich nicht laden ließ und stillschweigend übersprungen wurde, oder ein `ssh.PublicKeysCallback`, hinter dem ein SSH-Agent ohne Schlüssel steht.

• RSA-Schlüssel signiert mit ssh-rsa (SHA-1)

  gelegentlich

  Server ab OpenSSH 8.8 lehnen Signaturen vom Typ `ssh-rsa` ab. Alte Versionen von x/crypto signieren mit RSA-Schlüsseln standardmäßig über SHA-1; aktuelle Versionen handeln `rsa-sha2-256/512` aus. Aktualisiere golang.org/x/crypto oder verwende einen Ed25519-Schlüssel.

• Falscher Remote-Benutzer

  gelegentlich

  Der Schlüssel ist für `ubuntu` autorisiert, aber der Client meldet sich als `root` oder `deploy` an. Die Autorisierung gilt pro Benutzer.

So behebst du den Fehler

1. 1.

   Schlüssel explizit laden und Host prüfen

   Lies den privaten Schlüssel ein, brich mit einem deutlichen Fehler ab, wenn das Parsen fehlschlägt, und verwende für den Host-Schlüssel `knownhosts` statt `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.

   Fingerabdrücke vergleichen und Server-Log lesen

   sshd protokolliert, warum es einen Schlüssel abgelehnt hat (falsche Berechtigungen für `~/.ssh`, nicht akzeptierter Algorithmus, unbekannter Benutzer). Die Client-Seite erfährt den Grund nie.

   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)

← Gesamte Signaturfehler-Datenbank durchsuchen