Description of problem: ssh-add is not adding my key to the ssh-agent Version-Release number of selected component (if applicable): openssh-clients-7.7p1-3.fc28.x86_64 How reproducible: ssh-add a key then try to use the forwardagent ssh feature Steps to Reproduce: 1. 2. 3. 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
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)
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.