12 votes

xpt avatar

Le transfert d'agent SSH ne fonctionne pas, même en utilisant `ssh -A'.

Demandé el 15 de Novembre, 2014
Quand la question a-t-elle été
10055 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Tout d'abord, j'ai vérifié tous les éléments suivants

mais aucun d'entre eux n'a aidé. Alors, voici ma question :

Je peux me connecter par ssh de A à B, ou de A à C, mais pas de A à B, puis de B à C. Lorsque je me connecte de A à B ou C, j'utilise toujours ssh -A pour forcer le transfert de l'agent SSH.
Mais pourquoi je ne peux toujours pas me connecter. A -> B -> C sans qu'on lui demande sa phrase de passe ?

UPDATE : Près de trois ans plus tard, le même problème me hante toujours, mais j'ai maintenant réduit un peu le problème :

Symptôme : je peux accéder au ssh A -> B o A -> C mais pas A -> B -> C o A -> C -> B .

Le problème est exactement décrit par le sujet -- Le transfert d'agent SSH ne fonctionne pas .

De

Dépannage des problèmes de SSH
https://confluence.atlassian.com/bitbucket/troubleshoot-ssh-issues-271943403.html

il est dit :

Pour dresser la liste de vos clés chargées, entrez ssh-add -l . Si vous ne voyez pas la clé SSH que vous voulez utiliser...

alors il y a un problème -- la clé SSH que vous voulez utiliser n'est PAS chargée.

C'est ce qui se passe quand je suis à A -> B o A -> C . C'est-à-dire, juste après que j'ai fait ssh -A dans un serveur intermédiaire. la clé SSH est perdue, non transmise et non chargée.

$ ssh-add -l
The agent has no identities.

C'est la raison pour laquelle je ne peux pas poursuivre le ssh sans la phrase de passe.

Il a SSH_AUTH_SOCK configuration variable et plusieurs ssh-agent dans le coin :

$ echo "$SSH_AUTH_SOCK"
/tmp/ssh-RtEuLOmFDBet/agent.3722

$ ps -e  | grep [s]sh-agent
 3723 ?        00:00:00 ssh-agent
 4613 ?        00:00:00 ssh-agent

Il ne semble pas être lié à mon propre environnement puisqu'ils sont identiques, ou à la /etc/ssh/sshd_config car j'ai comparé ceux des serveurs intermédiaires qui fonctionnent ou ne fonctionnent pas.

FIN DE LA MISE À JOUR.

Plus d'infos : les trois machines, sont configurées avec la configuration ssh standard d'Ubuntu. C'est-à-dire que le AllowAgentForwarding n'est pas dans /etc/ssh/sshd_config bien que je doute qu'il le fasse, parce que j'ai vu "Puisque le transfert d'agent est activé par défaut, il devrait être suffisant de supprimer toute ligne AllowAgentForwarding de sshd_config." de Configuration supplémentaire requise pour le transfert de ssh-agent ? .

Certains disent ssh-add fera l'affaire, mais lorsque je le fais sur B ou C, il me demande de Enter passphrase for mon .ssh/id_rsa . Certains disent de vérifier le SSH_AUTH_SOCK mais je l'ai sur B ou C (soit de A à B, soit de A à C) :

$ env | grep SSH_AUTH_SOCK
SSH_AUTH_SOCK=/tmp/ssh-RTScJ5PZh9Mh/agent.2083

Est-ce que le transfert d'agent ne fonctionne pas parce qu'il manque les éléments suivants AllowAgentForwarding option ? Alors dans laquelle (A, B ou C) dois-je le mettre ? Ne serait-ce pas ssh -A sera-t-il suffisant ? J'ai aussi le .ssh/id_rsa sur les deux B et C, c'est que la raison ssh-add demander la phrase d'authentification pour eux ?

EDIT :

Voici le journal de -Avvv de B à C :

OpenSSH_6.2p2 Ubuntu-6ubuntu0.1, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /home/myid/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to boxc.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/myid/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/myid/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024
debug1: identity file /home/myid/.ssh/id_rsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/myid/.ssh/id_dsa" as a RSA1 public key
debug1: identity file /home/myid/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: identity file /home/myid/.ssh/id_dsa-cert type -1
debug1: identity file /home/myid/.ssh/id_ecdsa type -1
debug1: identity file /home/myid/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2p2 Ubuntu-6
debug1: match: OpenSSH_6.2p2 Ubuntu-6 pat OpenSSH*
debug2: fd 3 setting O_NONBLOCK
debug3: put_host_port: boxc
debug3: load_hostkeys: loading entries for host "boxc" from file "/home/myid/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/myid/.ssh/known_hosts:15
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none
debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5-etm@openssh.com
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com zlib@openssh.com
debug2: mac_setup: found hmac-md5-etm@openssh.com
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com zlib@openssh.com
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA ed:26:20:93:4c:88:ef:17:70:e3:d4:7a:42:4c:8e:69
debug3: put_host_port: [192.168.2.122]:21
debug3: put_host_port: boxc
debug3: load_hostkeys: loading entries for host "boxc" from file "/home/myid/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/myid/.ssh/known_hosts:15
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries from file "/home/myid/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/myid/.ssh/known_hosts:16
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'boxc' is known and matches the RSA host key.
debug1: Found key in /home/myid/.ssh/known_hosts:15
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/myid/.ssh/id_rsa (0x7f7e....e760),
debug2: key: /home/myid/.ssh/id_dsa (0x7f7e....e7a0),
debug2: key: /home/myid/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myid/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug2: input_userauth_pk_ok: fp 22:32:...:1d:e3
debug3: sign_and_send_pubkey: RSA 22:32:...:1d:e3
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/home/myid/.ssh/id_rsa':

J'ai comparé avec ma bonne session (A->C), et j'ai trouvé qu'il n'y avait aucune différence, à l'exception des 3 dernières lignes, qui commencent avec " key_parse_private_pem: PEM_read_PrivateKey failed ". La bonne session a plutôt :

debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
Authenticated to boxc

Tout le reste est identique.

Encore une fois, c'est mon environnement :

$ apt-cache policy openssh-server
openssh-server:
  Installed: 1:6.2p2-6ubuntu0.1
  Candidate: 1:6.2p2-6ubuntu0.4
  Version table:
     1:6.2p2-6ubuntu0.4 0
        500 http://archive.ubuntu.com/ubuntu/ saucy-updates/main amd64 Packages
     1:6.2p2-6ubuntu0.3 0
        500 http://security.ubuntu.com/ubuntu/ saucy-security/main amd64 Packages

% sshd -v
sshd: illegal option -- v
OpenSSH_6.2p2 Ubuntu-6ubuntu0.1, OpenSSL 1.0.1e 11 Feb 2013

Merci

Demandé el 15 de Novembre, 2014 par xpt

0 votes

Avatar de Hubro

Avez-vous essayé ssh -Avv (ou peut-être plus -v (je ne connais pas par cœur le niveau de verbosité maximum) et regardé le résultat ?

Commenté el 15 de Novembre, 2014 par Hubro

0 votes

Avatar de xpt

Oui, j'ai essayé, avec 4 V. Mais je ne sais pas quoi chercher en particulier, et je n'ai rien trouvé de suspect... Edit : Attendez, j'ai trouvé quelque chose...

Commenté el 15 de Novembre, 2014 par xpt

1 votes

Avatar de Hubro

Alors vous ssh-add votre clé sur A, ssh-add -l montre que la clé a été chargée, puis vous vous connectez à B en utilisant ssh -A . Est-ce que ssh-add -l affiche toujours la même clé ? Vous n'avez pas besoin (de la même clé dans) .ssh/id_rsa sur B. Je suppose que votre clé est cryptée avec le mot de passe qui fonctionne bien si vous le saisissez à l'invite que vous ne voulez pas voir ?

Commenté el 15 de Novembre, 2014 par Hubro
Afficher 1 autres commentaires

Réponses

Trop de publicités?

9voto

xpt avatar
xpt Points 7071

J'ai essayé de résoudre ce problème depuis presque sept ans et finalement, le problème est résolu : je lance keychain dans mon ~/.profile qui démarre sa propre ssh-agent même sur les machines B et C. C'est le source du problème, car keychain 's ssh-agent éclipser le sshd en a fourni un.

Le retirer ( keychain ) de mon ~/.profile a résolu le problème.

Mise à jour, une autre possibilité, ssh-agent etc. sont généralement lancés dans le cadre du démarrage de l'application de l GUI sur le système local. Par exemple, dans un autre cas, l'appel est caché dans le système local. /etc/X11/xdm/sys.xsession !

Je confirme que mon Agent SSH Forwarding fonctionne en faisant, dans la MachineA,

ssh -t MachineB ssh MachineC

tandis que ssh MachineB puis, en son sein ssh MachineC a échoué.

Je vais le commencer ( ssh-agent de keychain etc) manuellement uniquement à partir de la machine A à partir de maintenant.

Répondu el 12 de Juillet, 2018 par xpt (7071 Points )

0voto

Vincent Yin avatar
Vincent Yin Points 101

Encore une autre cause : Si l'empreinte digitale de l'hôte cible ne correspond pas à votre ~/.ssh/known_hosts SSH désactive automatiquement le transfert d'agent.

La solution est la suivante :

$ ssh -A -o UserKnownHostsFile=/dev/null  my-target-host

Après s'être connecté en SSH à l'hôte distant/intermédiaire, faites ceci pour vérifier que le transfert d'agent est en vigueur :

remote-host$  echo $SSH_AUTH_SOCK
/tmp/ssh-AyHL6WclXl/agent.107234     <== Means Agent Forwarding is in effect.
Répondu el 1 de Septembre, 2020 par Vincent Yin (101 Points )

0 votes

Avatar de xpt

Si l'empreinte de l'hôte cible ne correspond pas à votre ~/.ssh/known_hosts, ssh vous le dira clairement, et même comment supprimer l'entrée en conflit, n'est-ce pas ? C'est un cas très différent du problème discuté ici.

Commenté el 3 de Septembre, 2020 par xpt

0 votes

Avatar de Vincent Yin

Depuis que la correspondance d'empreintes digitales est si fréquente, les gens (moi y compris) se sont habitués à ce message d'avertissement. À une occasion (il ne s'agissait pas exactement de la même configuration), j'ai ignoré ce message (comme toujours) tout en cherchant toutes les idées sur Internet pour déboguer mon problème. Aucune des solutions populaires/liste de contrôle que j'ai trouvées sur Internet ne mentionnait que know_hosts peut être un problème. J'ai donc pensé que je pourrais proposer une autre idée.

Commenté el 4 de Septembre, 2020 par Vincent Yin

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X