[Bug 684] ssh cannot access keys stored in agent

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=684





------- Additional Comments From mdelan at computer.org  2003-09-20 23:17 -------
Actually, it's $HOME that isn't expanding, not ~:
debug2: key: /home/mdelan/.ssh/id_rsa (65630)
debug2: key: $HOME/.ssh/identity (0)
debug2: key: $HOME/.ssh/id_rsa (0)
debug2: key: $HOME/.ssh/id_dsa (0)
debug2: key: /home/mdelan/.ssh/identity (0)
debug2: key: /home/mdelan/.ssh/id_dsa (0)

The real problem is that if the same key is loaded 
more than once through IdentityFile statements, either
because different listed files contain the same key, 
or the same file has been listed more than once (e.g.
global and user ssh_config files contain the same
IdentityFile statements), and that key also exists
in the agent, then we end up with multiple copies of
that key in the authctx list - one tagged as being an
agent key, the other(s) not.

userauth_pubkey() does offer the public key for the
copy in the agent first, but due to the way it manipulates
the authctx list, when input_userauth_pk_ok() goes to do
the private key side of the exchange, it finds one of
the non-agent copies first and uses that - hence the
passphrase prompt.

The patch in attachment #440 is a fairly quick hack to
eliminate duplicate keys obtained from IdentityFiles
during the setup phase of pubkey_prepare(), prior to
the routine that orders the identities.

Just checking for extra duplicates of agent keys in the
next loop down might be a slicker solution, but at
the moment, I can't quite figure out how to manipulate
the TAILQ_* macros correctly to do that.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.