sign_and_send_pubkey: signing failed for RSA key; from agent: agent refused operation

https://unix.stackexchange.com/questions/626143/sign-and-send-pubkey-signing-failed-for-rsa-key-from-agent-agent-refused-oper

Asked 4 years, 11 months ago Modified 3 years, 8 months ago Viewed 40k times 20

I have a new machine running debian sid on which I generated a new ssh key-pair. I wanted to find a convenient way to copy this new key-pair to various other machines using my old Ubuntu machine and its key-pair. I have disabled password logins for all the “remote” machines, so I wanted to use the old machine as an intermediate. While researching this, I found the exact situation given as an example in the manual page for ssh-copy-id. I followed the example to access a pi zero running pihole, but got the error in the post title.

To sum up my steps from that example, where debian is the machine with the new key-pair, sarp.lan is the machine with the old key-pair and pihole is the “remote” machine, I did: enter image description here

However, running ssh -v pihole, I do see the output

debug1: Server accepts key: /home/sarp/.ssh/id_rsa RSA SHA256:V74Y4EhlszaIzco6oxOtl86ALj/U8rhXO2XUpEftZLU agent I read through various posts on this topic, but none of the solutions worked for me. Here are some details/things I have tried:

Permissions are correct for .ssh/enter image description here I am not running gnome-keyring-daemon: echo $SSH_AUTH_SOCK returns /tmp/ssh-a8Ol5O0XY9Fv/agent.1326, and I don’t see the keyring daemon running through ps aux. ssh-add -l correctly displays the two keys as can be see in the first picture (one from the old machine, the other from the new machine) I just copied the .ssh/config from the old machine, so the hostname/username/etc. should be fine. Let me know if I should provide additional useful info, and apologies if it is something very obvious, but what am I missing here?

sshssh-agentgnome-keyringssh-keygen Share Improve this question Follow asked Dec 25, 2020 at 23:52 firedrillsergeant’s user avatar firedrillsergeant 46233 gold badges77 silver badges1414 bronze badges Add a comment 3 Answers Sorted by:

Highest score (default) 29

Make sure the permissions of the key directory and keys are correct on the client. The ~/.ssh directory should only have execute, read and write permissions for the user. If not then change them:

User can execute, read and write

chmod 700 ~/.ssh

For the private keys and also the id_rsa, user can read and write

chmod 600 ~/.ssh/id_rsa

For the public keys, user can read and write, others can read

chmod 644 ~/.ssh/*.pub

Share Improve this answer Follow answered Jan 23, 2021 at 12:43 Parrotruper’s user avatar Parrotruper 41133 silver badges22 bronze badges Thank you for the answer. I think the permissions in the picture should be alright tho? – firedrillsergeant CommentedFeb 4, 2021 at 20:07 In my case, permissions caused the very same error message and the answer solved the issue. – sgrubsmyon CommentedMay 25, 2021 at 20:49 Add a comment 7

When the issue is not access rights below ~/.ssh (as your detailed listing indicates), another option might be that the authentication agent is somehow hanging.

Since the authentication daemon should automatically spawn if gone, you can simply try killing it, e.g. with killall ssh-agent.

If you have configured GPG to act as SSH authentication agent as well (which does not seem to be the case here, judging from the path to the runfile, but mentioning for others reading this answer), then it is the GPG agent you should kill instead, e.g. with gpgconf –kill gpg-agent.

Share Improve this answer Follow answered Mar 13, 2022 at 8:55 Jonas’s user avatar Jonas 17111 silver badge22 bronze badges Thank you, I feel like other folks missed the fact that access rights was not the issue. – firedrillsergeant CommentedMar 13, 2022 at 23:36 2 I am happy that it seems I understood you. If you think not only that but also that my answer is correct, then please mark it as such. I certainly hope that you have solved your concrete problem by now so it might be impossible to know for sure what exactly would be the correct answer, so might just be an educated guess… – Jonas CommentedMar 14, 2022 at 19:09 Yeah, for that exact reason of not even remembering what the issue was, I won’t mark it as solved, but thank you regardless. – firedrillsergeant CommentedMar 16, 2022 at 0:39 @Jonas - thank you this solved my issue and (for me) should be the accepted answer. I was modifying the accepted algorithms on SSH/SFTP Server Side and then when reconnecting from client got the following Errors (“Fedora Linux 41 (Workstation Edition)”): … sign_and_send_pubkey: signing failed for RSA “…/.ssh/id_rsa” from agent: agent refused operation … input_userauth_pk_ok: type mismatch for decoded key (received 2, expected 0) (Fedora) … – becke-ch CommentedOct 27 at 7:39 Add a comment 2

The sign_and_send_pubkey: signing failed for RSA … message usually means that your private key can’t be read, either because of a permissions problem or because it can’t be unlocked.

In my case, I was running ssh in a shell that had DISPLAY misconfigured, so attempting to unlock my ssh private key triggered a graphical unlock dialogue that I never saw. Fixing DISPLAY or explicitly unlocking my private key with ssh-add fixed my particular case.