Pourquoi le transfert d'agent ssh ne fonctionne pas ?

Une autre raison possible est le partage de connexion : l'un d'entre eux peut être déjà connecté sur l'autre hôte sans que le transfert d'agent et le partage de connexion soient activés. La deuxième connexion avec ssh -A (ou l'équivalent spécifié dans le fichier de configuration) via la connexion partagée ignorera silencieusement l'élément -A drapeau. Ce n'est qu'après une déconnexion complète ou la désactivation du partage de connexion pour la deuxième connexion que le transfert d'agent fonctionnera.

Pour moi, c'était simplement que l'hôte auquel je me connectais ( b1 dans l'exemple de l'affiche d'origine) exécutait son propre système persistant. ssh-agent . Il n'y a pas de sortie de débogage que j'ai pu voir pour expliquer ce qui se passait, l'hôte utilise simplement et silencieusement son code d'accès existant. ssh-agent et aucune redirection ne se produit. Cela me semble logique rétrospectivement :p

La redirection est comme la redirection de port ssh : c'est une tunnellisation, pas une négociation client-serveur.

I supposé c'était la seconde - que le fait d'avoir un ssh-agent s'exécutant sur l'hôte serait nécessaire pour le transfert d'agent, donc je l'ai configuré au début, mais c'était une erreur.

Voir les exemples suivants :

D'abord, je me connecte à l'hôte par ssh ccam (un raspberry pi) sans Agent Forwarding et confirmez qu'il n'y a pas de socket agent ou de clés ajoutées :

Deuxièmement, j'édite .bashrc pour s'assurer que ssh-agent fonctionne sur l'hôte ( c'était mon erreur ). Vous pouvez voir que lorsque je me reconnecte en utilisant -A pour activer le transfert d'agent, le socket de l'agent existe, mais l'agent n'a pas d'identité (je réalise maintenant que c'est parce que cela montre le socket local de ssh-agent plutôt qu'un socket transféré) :

Enfin, je supprime le ssh-agent sur l'hôte raspberry-pi (non illustré) et reconnectez-vous. Vous pouvez voir que la clé est enfin disponible en inspectant à l'aide de ssh-add -L :

1. Vérifiez si votre ~/.ssh/id_rsa ~/.ssh/id_dsa ~/.ssh/id_ecdsa ont les permissions correctes. Ils doivent appartenir à votre utilisateur et être codés 600.

2. Vérifiez que vous avez la bonne clé publique sur pupeno/.ssh/authorized_keys sur b1, et vérifier si authorized_keys a un saut de ligne à la fin de la touche.

3. Vérifiez si vous avez ssh-agent qui fonctionne, essayez de charger les clés via ssh-add

4. Essayez l'authentification et le transfert basés sur GSSAPI avec ssh -K

J'ai eu un problème avec le serveur sshd qui rejetait la demande de transfert d'agent parce qu'il n'y avait plus d'espace dans /tmp. Ceci était dû au fait que sshd avait besoin de créer un socket dans /tmp. Le nettoyage du disque a résolu mon problème.

ssh -v disait à l'époque :

debug1: Remote: Agent forwarding disabled: mkdtemp() failed: No space left on device