La connexion SSH ne fonctionne pas avec une clé sans mot de passe ?

Vous souffriez de l'échec suivant :

L'agent a reconnu ne pas avoir signé avec la clé.

Ceci est un message malheureusement non diagnostique. Il existe (au moins) deux catégories de problèmes auxquels il pourrait répondre :

La clé n'est pas chargée

Pour la plupart des problèmes, cela signifie que votre ssh-agent n'a pas de clés ssh chargées qui sont acceptées pour votre compte sur le serveur cible. Dans ce cas, comme indiqué par la réponse de @Networker à cette question, la solution est plutôt simple :ajoutez la clé :

ssh-add

Si la clé se trouve dans un emplacement autre que celui par défaut, vous devrez l'indiquer à ssh-add :

ssh-add /path/to/key

L'agent ne peut pas comprendre la clé

Il s'agissait du bogue GNOME 754028, résolu dans Seahorse 3.29.90 (stable 3.30 publié le 03/09/2018, inclus dans Ubuntu 18.10, Fedora 29 et probablement Red Hat/CentOS 9). Seahorse avant 3.29.90 (et donc GNOME Keyring) ne pouvait ni créer ni ajouter de nouveaux types de clés comme ed25519 et les clés générées avec ssh-keygen -o -a 100 (comme suggéré par le tutoriel Secure Secure Shell).

Diagnostic de ce problème :

• ssh myserver échoue avec "l'agent ssh a admis l'échec"
• SSH_AUTH_SOCK= ssh myserver fonctionne très bien
• Conclusion :gnome-keyring ne peut pas gérer les clés complexes

Comme je viens de trouver une solution de contournement viable pour ce bogue, et qu'elle ne semble être publiée nulle part (à l'exception du commentaire que je viens d'ajouter à un bogue Ubuntu), je vais la mettre ici.

Solution : Lancer un nouveau ssh-agent en utilisant le même socket que celui de gnome-keyring :

ssh-agent -a $SSH_AUTH_SOCK

Cela lance une nouvelle instance de ssh-agent (en écrasant l'instance la moins performante de GNOME), il n'y aura donc aucune clé (malgré ce que seahorse dit, puisque c'est lié à l'ancien agent). Vous devrez les ajouter via ssh-add comme indiqué dans le La clé n'est pas chargée ci-dessus.

Vous devrez l'exécuter à chaque connexion (ou l'ajouter manuellement à vos scripts de démarrage). Si vous souhaitez conserver l'ancien socket, exécutez mv $SSH_AUTH_SOCK $SSH_AUTH_SOCK.broken d'abord.

J'ai résolu le problème simplement en exécutant cette commande sur la machine locale (après avoir généré la clé) :

$ ssh-add