Bug 1568895 - ssh-add not working
Summary: ssh-add not working
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-keyring
Version: 28
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-04-18 11:51 UTC by marianne@tuxette.fr
Modified: 2019-05-28 20:44 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-05-28 20:44:12 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 795699 0 None None None 2018-04-30 16:13:23 UTC

Description marianne@tuxette.fr 2018-04-18 11:51:11 UTC
Description of problem:
ssh-add is not adding my key to the ssh-agent

Version-Release number of selected component (if applicable):

How reproducible:
ssh-add a key then try to use the forwardagent ssh feature

Steps to Reproduce:

Actual results:
$ ssh-add 
Identity added: /home/mlombard/.ssh/id_rsa (/home/mlombard/.ssh/id_rsa)
$ ssh-add -l 
error fetching identities: invalid format

Expected results:
Working ssh-add

Additional info:
I'm not sure on how getting useful trace but if you give me some hints, I should be able to provides them
This is a new laptop, installed last week in f28 beta, up-to-date

Comment 1 Jakub Jelen 2018-04-18 12:31:43 UTC
Can you check with starting only a ssh-agent in debug mode and try only with it?

In first terminal:

  $ ssh-agent -D

In second terminal:
paste the SSH_AUTH_SOCK environment variable, try to add the key and use it/list it:

  $ ssh-add 
  $ ssh-add -l

Attach the debug log from the first terminal.

The ssh-agent should be proxied through the gnome-keyring in default installations so there might still be some issues with that. If the above exercise will work, the issue is in gnome-keyring.

Comment 2 marianne@tuxette.fr 2018-04-18 17:10:37 UTC

With the above instruction it's working. 

 mlombard  ~  SSH_AUTH_SOCK=/tmp/ssh-9x0EIwn6GWGU/agent.2877; export SSH_AUTH_SOCK;

 mlombard  ~  ssh-add                                                              
Identity added: /home/mlombard/.ssh/id_rsa (/home/mlombard/.ssh/id_rsa)
 mlombard  ~  ssh-add -l                                                           
4096 SHA256:cDu+8P/2jFByjeIPPeZhIJBKpp7cddU+jqHZU0l6sEE /home/mlombard/.ssh/id_rsa (RSA)

Comment 3 marianne@tuxette.fr 2018-04-18 17:10:49 UTC

With the above instruction it's working. 

 mlombard  ~  SSH_AUTH_SOCK=/tmp/ssh-9x0EIwn6GWGU/agent.2877; export SSH_AUTH_SOCK;

 mlombard  ~  ssh-add                                                              
Identity added: /home/mlombard/.ssh/id_rsa (/home/mlombard/.ssh/id_rsa)
 mlombard  ~  ssh-add -l                                                           
4096 SHA256:cDu+8P/2jFByjeIPPeZhIJBKpp7cddU+jqHZU0l6sEE /home/mlombard/.ssh/id_rsa (RSA)

Comment 4 Jakub Jelen 2018-04-19 07:20:50 UTC
So this is most probably a problem of gnome-keyring proxy. Daiki will be able to point you to some more debugging steps. Just verify that your environment variable is really the gnome-keying one:


Comment 5 Daiki Ueno 2018-04-19 08:14:27 UTC
gnome-keyring looks for all public keys from ~/.ssh and behaves as if they are loaded to the ssh-agent.  I'm guessing that you have some file named "*.pub" in your ~/.ssh directory, whose content is not compatible to OpenSSH.

Would you be able to check:
- Does ssh-add -l work, *before* adding the key?
- If you backup ~/.ssh and recreate an empty ~/.ssh directory, does it work?

Comment 6 Daiki Ueno 2018-04-20 08:02:18 UTC
I forgot to mention that you could test those without re-login or rebooting by killing the internal ssh-agent process:

$ pkill ssh-agent

Then gnome-keyring will clear the current state and restart ssh-agent automatically:

$ ssh-add -l

Comment 7 marianne@tuxette.fr 2018-04-27 11:07:00 UTC
By listing the .pub file in my .ssh directory,I found the issue. I have an identity.pub file. It's an old ssh 1 compatible key I was using for some legacy stuff at work. If I rename it to identity.pub-old, everything work fine again.

Comment 8 Jakub Jelen 2018-04-27 12:28:01 UTC
Thank you for the update. I am glad that it was resolved.

Daiki, do you think that we in gnome keyring, you will be able to filter out old rsa public keys to avoid these issues if somebody has old keys in their home directories?

You can generate the identity SSH-1 identity files for example on RHEL7 using ssh-keygen:

  $ ssh-keygen -t rsa1 -f rsa1
  $ cat rsa1.pub
  2048 65537 217[...]261300266088801 comment

It does not work in current Fedora, because support for SSH1 was already removed.

Comment 9 Daiki Ueno 2018-04-27 14:52:36 UTC
Yes, we should fix this in gnome-keyring; I am a bit surprised that the current check doesn't work in this case:
Maybe it should check that the key blob is followed by a whitespace or EOL.

Comment 10 Michael Katzmann 2018-05-02 19:21:04 UTC
This bug is a little more insidious than it seems...

gnome-keyring now breaks (for ssh) if there is one bad public key in a key pair. That is to say if one public key of a key pair is badly formatted, then no ssh key can be used from the gnome-keyring (even if all the others are good) !!

Comment 11 Ben Cotton 2019-05-02 21:32:37 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 12 Ben Cotton 2019-05-28 20:44:12 UTC
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.