GNOME Bugzilla – Bug 794361
Better diagnostics when calling ssh-add fails
Last modified: 2018-03-19 11:05:31 UTC
Git fails for me on Fedora 28 with "sign_and_send_pubkey: signing failed: agent refused operation" error and the following appears in the journal output: gnome-keyring-daemon[1918]: couldn't read from client: invalid packet size 0 gnome-keyring-daemon[1918]: the /usr/bin/ssh-add command failed: Child process exited with code 1 gnome-keyring-daemon[1918]: couldn't read from client: invalid packet size 0 It happens with gnome-keyring-3.27.92 and downgrading to Fedora 27 version fixes the issue. This is probably caused by fixes Bug 775981.
Is gcr >= 3.27.92 installed on your system? In particular, $libexec/gcr-ssh-askpasss command.
I couldn't reproduce it with: git clone ssh://dueno@git.gnome.org/git/gnome-keyring.git on Fedora-28-20180314.n.2 nightly Workstation live image, which has: gnome-keyring-3.27.92-1.fc28.x86_64 gcr-3.27.92-1.fc28.x86_64
I've enabled testing repos in the meantime, but still the same situation :-( $ sudo dnf distrosync Last metadata expiration check: 2:43:40 ago on Thu 15 Mar 2018 14:23:03 CET. Dependencies resolved. Nothing to do. Complete! $ rpm -q gcr gnome-keyring gcr-3.28.0-1.fc28.x86_64 gnome-keyring-3.28.0.1-1.fc28.x86_64 $ ls /usr/libexec/gcr-ssh-askpass /usr/libexec/gcr-ssh-askpass $ git clone ssh://oholy@git.gnome.org/git/gnome-keyring.git Cloning into 'gnome-keyring'... sign_and_send_pubkey: signing failed: agent refused operation oholy@git.gnome.org: Permission denied (publickey,gssapi-keyex,gssapi-with-mic). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Is there something else what I can provide?
I have no clue off hand, but would like to make sure the following: - Does this only happens with git, not with the normal ssh command? - When it fails, do you see a prompt on the screen? - Do you have any configuration in ~/.ssh/config that might affect the connection to the server? Also, given that calling ssh-add is failing, maybe you could capture the stdout/stderr of it with a wrapper script?
It happens also with ssh command: $ ssh oholy@master.gnome.org sign_and_send_pubkey: signing failed: agent refused operation oholy@master.gnome.org: Permission denied (publickey,gssapi-keyex,gssapi-with-mic). I don't see any prompt... ~/.ssh/config is empty.
But wrapper script discovered the following: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for '/home/oholy/.ssh/id_gnome' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. And "chmod 400 /home/oholy/.ssh/*" fixed the issue, so sorry for the noise... but anyway, can't you propagate stderr into journal to be obvious what is wrong?
Just a note that I tried ssh-add without parameters before but it succeeded because it added a different key with correct permissions, that's why I am asking to propagate stderr... or the parameters of ssh-add.
Thank you for checking and the suggestion; yes, I agree.
Created attachment 369779 [details] [review] ssh-agent: Keep stderr open when spawning ssh-add for diagnostics
Created attachment 369781 [details] [review] ssh-agent: Keep stderr open when spawning ssh-add for diagnostics
Created attachment 369859 [details] [review] ssh-agent: Propagate stderr to journal when spawning ssh-add ssh-add fails in certain occasions, such as when the file permissions of private key is not unsafe. To help diagnostics, propagate the stderr output from the command to journal. As the ssh commands send error message with trailing CR for each line, we need to scrub it so as not to confuse journald.
Attachment 369859 [details] pushed as 153ae24 - ssh-agent: Propagate stderr to journal when spawning ssh-add
Thanks!