web-dev-qa-db-fra.com

Pourquoi le transfert d'agent ssh ne fonctionne-t-il pas?

Dans mon propre ordinateur, exécutant MacOSX, je l'ai dans ~/.ssh/config

Host *
ForwardAgent yes
Host b1
ForwardAgent yes

b1 est une machine virtuelle exécutant Ubuntu 12.04. Je ssh comme ça:

ssh pupeno@b1

et je me connecte sans qu'on me demande un mot de passe car j'ai déjà copié ma clé publique. En raison du transfert, je devrais être capable de ssh vers pupeno @ b1 à partir de b1 et cela devrait fonctionner, sans me demander de mot de passe, mais ce n'est pas le cas. Il me demande un mot de passe.

Qu'est-ce que je rate?

C'est la sortie détaillée du deuxième ssh:

pupeno@b1:~$ ssh -v pupeno@b1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to b1 [127.0.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/pupeno/.ssh/id_rsa type -1
debug1: identity file /home/pupeno/.ssh/id_rsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_dsa type -1
debug1: identity file /home/pupeno/.ssh/id_dsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server Host key: ECDSA 35:c0:7f:24:43:06:df:a0:bc:a7:34:4b:da:ff:66:eb
debug1: Host 'b1' is known and matches the ECDSA Host key.
debug1: Found key in /home/pupeno/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pupeno/.ssh/id_rsa
debug1: Trying private key: /home/pupeno/.ssh/id_dsa
debug1: Trying private key: /home/pupeno/.ssh/id_ecdsa
debug1: Next authentication method: password
pupeno@b1's password:
ubuntusshmac-osxforwarding
60
pupeno

Il s'avère que ma clé n'était pas dans l'agent, et cela l'a corrigé:

OS X:

ssh-add -K

Linux/Unix:

ssh-add -k

Vous pouvez lister les clés chargées en utilisant:

ssh-add -l

ssh-add -L # for more detail
97
pupeno

  1. Vérifiez si votre ./ssh/id_rsa .ssh/id_dsa.ssh/id_ecdsa les fichiers ont les autorisations correctes qui devraient appartenir à votre utilisateur et être modulées en 600.

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

  3. Vérifiez si vous avez ssh-agent en cours d'exécution, essayez de charger les clés via ssh-add

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

8
Daniel Prata Almeida

J'ai eu un problème avec le serveur sshd rejetant la demande de transfert d'agent car il n'y avait plus d'espace dans/tmp. En effet, sshd doit 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
6
BartBiczBoży

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

6
W.Mann

Pour le bénéfice d'autres googleurs qui sont également arrivés à cette question:

Un espace vide incorrect dans un fichier ~/.ssh/config peut également provoquer des rayures sur la tête.

J'ai récemment aidé un de mes collègues qui avait ceci:

# incorrect
Host foobar ForwardAgent yes

au lieu de cela:

# correct
Host foobar
  ForwardAgent yes

J'ai également rencontré des cas où l'indentation manquante des directives dans la liste des hôtes a fait une différence dans la fonctionnalité, même si ce n'est pas censé le faire.

2
Dale Anderson

Ajoutez les lignes suivantes au fichier .ssh/config

  Host **Server_Address**
     ForwardAgent yes

Ajouter une clé à l'agent SSH

 ssh-add -K

Se connecter au serveur distant

ssh -v **username**@**Server_Address**

Exécutez un test de connexion sur GitHub

ssh -T [email protected]

Exécutez le test distant ls sur le référentiel git ciblé

git ls-remote --heads [email protected]:**account**/**repo**.git
0
Tahsin Turkoz