Bug 1568895

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.

Hi, 

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)

Hi, 

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)

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:

$ echo $SSH_AUTH_SOCK
/run/user/1000/keyring/ssh

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?

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

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.

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.

Yes, we should fix this in gnome-keyring; I am a bit surprised that the current check doesn't work in this case:
https://git.gnome.org/browse/gnome-keyring/tree/daemon/ssh-agent/gkd-ssh-agent-util.c#n160
Maybe it should check that the key blob is followed by a whitespace or EOL.

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) !!

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.

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
bug.

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