Page MenuHome GnuPG

ssh-add ignores keys already in private-keys-v1.d but not in sshcontrol
Closed, ResolvedPublic


I copy/paste the content of the following URL here to ease reading

I had several old ssh keys in my ~/.gnupg/sshcontrol so I removed all lines in
this file and rebooted my computer. Now, I can't add ssh keys to gpg agent anymore:

$ cat ~/.gnupg/gpg-agent.conf

$ gpg-connect-agent --verbose /bye
gpg-connect-agent: closing connection to agent

$ gpg-connect-agent updatestartuptty /bye

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

$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/cassou/.ssh/id_rsa:
Identity added: /home/cassou/.ssh/id_rsa (/home/cassou/.ssh/id_rsa)

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



Event Timeline

DamienCassou set Version to 2.1.11.
DamienCassou added a subscriber: DamienCassou.

The solution is to remove the key in private-keys-v1.d before running ssh-add.

werner added a subscriber: werner.

I would not consider this a bug. sshcontrol is used to enable certain keys for
use with ssh. Updating keys is useless if they are already available.

If you remove the keys from sshcontrol you disable them. I would suggest to put
a '!' in front of the keygrip instead of deleting the line in sshcontrol. This
allows to re-enable a key w/o problems.

justus claimed this task.
justus added a subscriber: justus.

I do consider it a bug, at least because we did not signal an error to ssh-add.
Fortunately, this was easy to fix.

Fixed in 270f7f7b.

This is apparently just re-reported on gnupg-users:

So i don't think it's fixed.

And fwiw, it seems like a clear bug to me if i use "ssh-add" and then it is not
added to the agent.

From the ssh-add's client's perspective, some keys are magically never added,
but others are. This kind of mystery behavior is confusing and frustrating. If
gpg-agent is going to handle the ssh-agent protocol, it should aim toward behave
as the user of the ssh-agent protocol expects, regardless of whether the user
knows that they're using gpg-agent or some other implementation.

John is using 2.1.14, but this bug was fixed in 2.1.15.