How to solve "sign_and_send_pubkey: signing failed: agent refused operation"?

Question

Configuring a new Digital Ocean droplet with SSH keys. When I run ssh-copy-id this is what I get:

ssh-copy-id user@012.345.67.89
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'user@012.345.67.89'"
and check to make sure that only the key(s) you wanted were added.

However, when I then attempt to ssh in, this happens:

ssh user@012.345.67.89
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password:

Upon entering the password, I am logged in just fine, but this of course defeats the purpose of creating the SSH key in the first place. I decided to take a look at the ssh-agent server-side and here's what I get:

user@012.345.67.89:~# eval `ssh-agent -s`
Agent pid 5715
user@012.345.67.89:~# ssh-add -l
The agent has no identities.

user/.ssh/authorized_keys does contain an ssh-rsa key entry, as well, but find -name "keynamehere" returns nothing.

score 487 · Accepted Answer · answered May 29 '17 at 21:55

487

Run ssh-add on the client machine, that will add the SSH key to the agent.

Confirm with ssh-add -l (again on the client) that it was indeed added.

answered May 29 '17 at 21:55

Oliver

11,857
2
36
42

18

geez, spent two hours trying to fix this and this is all it was! Fixed bitbucket and acquia ssh connections – Ronnie Aug 25 '17 at 04:17
49

It did not entirely fix it here as I use `gpg-agent` for SSH functionality. I already have a `enable-ssh-support` in `gpg-agent.conf` but still same error message. I have found on mailing list to run this: `gpg-connect-agent updatestartuptty /bye`: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835394 – Roland Oct 03 '17 at 10:42
5

I just had to kill the gpg-agent and then run it again. – Subin Dec 12 '17 at 17:35
4

When you generate a new SSH key, `ssh-add` must be invoked for the `ssh-agent` to become aware of the new private key (per https://linux.die.net/man/1/ssh-agent). – alex Feb 11 '18 at 17:40
Excelent! i've recreated my SSH key and this started to happen. After `ssh-add` it worked! Thanks. – hbobenicio Feb 22 '18 at 12:06
how, how, how, bhoyz -- this is thee one :V – mlvljr Oct 18 '18 at 22:20
Excellent. Solved for me during a sys upgrade/restore. Just didn't work immediately for permissions too lose (from backup). I had: Permissions 0755 for '/home/diegone/.ssh/id_rsa' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. Chmod file and solved – Diego1974 Feb 21 '20 at 10:44
4

I had to correct the permissions of the private key, then do ssh-add. WARNING: UNPROTECTED PRIVATE KEY FILE! Permissions 0640 for '/home//.ssh/id_rsa' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. $ chmod 600 /home//.ssh/id_rsa $ ssh-add then work succefuly. Thank You. – Ziprasidone Nov 04 '20 at 17:20
1

I also had to kill gpg-agent as @Subin suggested in order to get `gpg-connect-agent updatestartuptty /bye` to work again as expected. You can safely terminate gpg-agent easily using `gpgconf --kill gpg-agent` without having to go manually searching for the correct process id. – Cory Gross Aug 19 '21 at 01:52
When run the first command, ssh notify me a permission problem in my id_rsa file and it was being ignored. I fix this and then It work. Thank you. – Tuxman Jan 12 '23 at 23:38

score 236 · Answer 2 · answered Jun 09 '18 at 10:22

236

After upgrading Fedora 26 to 28 I faced same issue. And following logs were missing

/var/log/secure
/var/log/messages

ISSUE:

antop@localmachine  ~  ssh root@ocp1.example.com
sign_and_send_pubkey: signing failed: agent refused operation
root@ocp1.example.com's password:

error message is not pointing actual issue. Issue resolved by

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*

answered Jun 09 '18 at 10:22

Anto

3,128
1
20
20

4

My `.ssh/` didn't have the required permissions because I had created it myself manually. – Brent Bradburn Jun 09 '18 at 22:45
2

Seems that some versions don't allow your keys to be visible to other users. Thanks! – alan ocallaghan Jun 19 '18 at 21:13
if .ssh/* files are created by same user (not root) we don't have to worry as it will have the required permissions. – Anto Oct 29 '18 at 12:25
4

I must appreciate you. I encountered this problem just now. Using your method solved it. – Land Jun 25 '20 at 12:51
3

THANK YOU. It Worked. You Beauty :) @Anto – Imran Rafiq Rather Jan 09 '22 at 09:50
I moved my .ssh dir from an OS to a fresh linux install and I could not push with git. Using this solution worked for me. – loquace Jun 27 '22 at 12:17
I can confirm; I moved the ssh directory from WSL to a fresh PopOS install. Changing the permissions using the mentioned solution worked for me. – Lennert Antson Aug 09 '22 at 08:28
Holly shit thank you. Lame that even with -vv ssh doesn't complain about perms..... seriously... – Pierre Aug 28 '23 at 15:44

score 187 · Answer 3 · edited Nov 05 '18 at 06:45

187

I was having the same problem in Linux Ubuntu 18. After the update from Ubuntu 17.10, every git command would show that message.

The way to solve it is to make sure that you have the correct permission on the id_rsa and id_rsa.pub.

Check the current chmod number by using stat --format '%a' <file>. It should be 600 for id_rsa and 644 for id_rsa.pub.

To change the permission on the files use

chmod 600 id_rsa
chmod 644 id_rsa.pub

That solved my issue with the update.

edited Nov 05 '18 at 06:45

Jithin

2,594
1
22
42

answered Jul 27 '18 at 19:03

Fernando Munoz

4,541
2
18
16

6

I faced this problem after migrating Ubuntu from 16.04 LTS to 18.04 LTS, this solution worked for me. – Munish Chandel Aug 11 '18 at 02:15
2

Same here, after updating Ubuntu to 18.04 I faced this problem. This solution fix it. – Cartucho Sep 18 '18 at 19:32
When does `id_rsa.pub` is used in the client authentication process? – Dimitri Kopriwa Sep 26 '18 at 17:09
If you have many keys, you should use something like this inside `~/.ssh`: `chmod 600 id_*` – lifeisfoo Oct 10 '18 at 16:00
Check the key first $ ssh-add -l if everything okay then update those permissions. – sitthykun Dec 10 '20 at 06:34
Solved my issue. Thx :) – Mark Sep 09 '21 at 16:18
I used multiple computers, so to keep things simple, I have uploaded my ssh keys to my cloud drive. If i need to switch computer, i just need to download the ssh key, apply this and voila, thanks – Ron Michael Apr 07 '22 at 08:44

score 59 · Answer 4 · edited Jan 06 '20 at 12:57

59

Run the below command to resolve this issue.

It worked for me.

chmod 600 ~/.ssh/id_rsa

edited Jan 06 '20 at 12:57

Taazar

1,545
18
27

answered Jan 06 '20 at 10:54

krishna

599
4
2

score 35 · Answer 5 · answered Sep 23 '21 at 06:40

35

I once had a problem just like yours, and this is how I solved it through the following steps.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
ssh-copy-id user@ip
ssh-agent -s
ssh-add

answered Sep 23 '21 at 06:40

Dean

459
4
4

12

just the chmod 600 of my key files where sufficient. what a stupid error message is that then from the SSH communication!!! – U.V. Oct 06 '21 at 22:14
1

**OMG.** I'm flabbergasted that OpenSSH just ambiguously reports `"agent refused operation"` for insecure keyfile permissions. `` – Cecil Curry Dec 02 '21 at 06:41
Yup. This is what fixed it for me too. I came back to working on my servers like 5 months later and it seems the changes in OpenSSH need more strict file perms. Kudos to @Dean for figuring this one out! Upvoting! – m8a Nov 03 '22 at 10:19
Trying `ssh-add -vvv ~/.ssh/keys/` first is also a good way to check for correct rights upfront, because this command actually tells you what is wrong (for example “Permissions 0644 for '.ssh/' are too open.”). – pixelbrackets Jan 25 '23 at 12:37

score 21 · Answer 6 · answered Jul 19 '19 at 16:19

I had the error when using gpg-agent as my ssh-agent and using a gpg subkey as my ssh key https://wiki.archlinux.org/index.php/GnuPG#gpg-agent.

I suspect that the problem was caused by having an invalid pin entry tty for gpg caused by my sleep+lock command used in my sway config

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock'"

or just the sleep/suspend

Reset the pin entry tty to fix the problem

gpg-connect-agent updatestartuptty /bye > /dev/null

and the fix for my sway sleep+lock command:

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock; gpg-connect-agent updatestartuptty /bye > /dev/null'"

Thank you. I had this problem a few days ago, I use gpg as you and have commented `gpg-connect-agent updaterstartuptty /bye > /dev/null` on my ~/.zshrc, uncommenting this line solved my problem. — J.Adler, Jul 25 '19 at 15:21
You legend. How the hell did you find a fix for this? it's so obscure! — RichieHH, Dec 02 '20 at 19:51

linjiejun · Answer 7 · 2022-09-15T06:24:31.513

14

eval "$(ssh-agent -s)"
To first start the ssh agent

ssh-add
To then add the ssh key

edited Sep 15 '22 at 06:24

answered Feb 28 '22 at 03:54

linjiejun

1,468
15
22

This is work for me! – linjiejun Mar 26 '22 at 07:42

score 8 · Answer 8 · answered Jun 13 '18 at 12:55

To this error:

# git pull
sign_and_send_pubkey: signing failed: agent refused operation
git@github.com: Permission denied (publickey).    
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

Verify or add again the public key in Github account > profile > ssh.

I solved like this:

# chmod 400 ~/.ssh/id_rsa

# ls  ~/.ssh/id_rsa -ls  
4 -r--------. 1 reinaldo reinaldo 1679 Jul 26  2017 /home/reinaldo/.ssh/id_rsa

# git pull                                 
remote: Counting objects: 35, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 35 (delta 9), reused 34 (delta 9), pack-reused 0
Unpacking objects: 100% (35/35), done.

Thank you.

score 5 · Answer 9 · answered Dec 11 '18 at 10:46

There could be various reason for getting the SSH error:

sign_and_send_pubkey: signing failed: agent refused operation

Some of them could be related to the issues highlighted by the other answers (see this thread answers), some of them could be hidden and thus would require a closer investigation.

In my case I've got the following error message:

sign_and_send_pubkey: signing failed: agent refused operation

user@website.domain.com: Permission denied (publickey,gssapi-keyex,gssapi-with-mic)

The only way to find the real problem was to invoke the -v verbose option which resulted in printing a lot of debugging info:

debug1: Connecting to website.domain.com [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com-cert type -1

Please note that the line saying key_load_public: No such file or directory is referring the next line and not the previous line.

So what SSH really says is that it could not find the public key file named id_rsa.website.domain.com-cert and that seemed to be the problem in my case since my public key file did not contain the -cert suffix.

Long story short: the fix in my case was just to make sure that the public key file was named as expected. I could never suspected that without debugging the connection.

The bottom line is USE THE SSH VERBOSE MODE (-v option) to figure out what is wrong, there could be various reasons, none that could be found on this/another thread.

score 5 · Answer 10 · answered Nov 16 '20 at 19:16

5

First ssh-add then ssh user@ip

this worked for me

answered Nov 16 '20 at 19:16

Mohit Rakhade

351
4
8

score 2 · Answer 11 · answered Dec 10 '19 at 14:03

In my case the problem was that GNOME keyring was holding an invalid passphrase for the ssh key to be used. After spending indecent amount of time troubleshooting this issue I ran seahorse and found the entry to hold empty string. I can only guess that it was caused by mistyping the passphrase at first use some time earlier, and then probably cancelling the requester or so in order to fall back to command line. Updating the entry with correct passphrase immediately solved the problem. Deleting that entry (from "login" keyring) and reentering passphrase at that first prompt (and checking the appropriate checkbox) solves this too. Now agent gets the correct passphrase from the unlocked at login keyring named "login" and neither asks for passphrase nor "refuses operation" anymore. Of course YMMV.

score 2 · Answer 12 · answered Aug 23 '22 at 09:35

Beware of how you name your ssh key files

If you have more than one key pair, you may be using ssh-keygen with the -f <key name> to name the output files. In my case, I was naming my keys like username@organization and username@organization.pub, which helps to keep multiple key pairs organized.

The problem is that the ssh agent doesn't like the @ character.

In my case this was causing the sign_and_send_pubkey: signing failed: agent refused operation error, and was preventing the session keyring to interact with the ssh agent.

Renaming my key files to username_at_organization fixed the problem.

score 1 · Answer 13 · answered Aug 24 '18 at 03:36

1

Yes. Run ssh-add on the client machine. Then repeat command ssh-copy-id userserver@012.345.67.89

answered Aug 24 '18 at 03:36

Kairat Koibagarov

1,385
15
9

score 1 · Answer 14 · answered Jul 02 '19 at 07:51

I got a sign_and_send_pubkey: signing failed: agent refused operation error as well. But in my case the problem was a wrong pinentry path.

In my ${HOME}/.gnupg/gpg-agent.conf the pinentry-program property was pointing to an old pinentry path. Correcting the path there and restarting the gpg-agent fixed it for me.

I discovered it by following the logs with journalctl -f. There where log lines like the following containing the wrong path:

Jul 02 08:37:50 my-host gpg-agent[12677]: ssh sign request failed: No pinentry <GPG Agent>
Jul 02 08:37:57 my-host gpg-agent[12677]: can't connect to the PIN entry module '/usr/local/bin/pinentry': IPC connect call failed

score 1 · Answer 15 · answered May 24 '22 at 14:46

According to Github security blog RSA keys with SHA-1 are no longer accepted.

Use the following command to create new SSH key with ECDSAencryption and add it to Github.

ssh-keygen -t ecdsa -b 521 -C "your_email@example.com"

original answer with details can be found here

score 0 · Answer 16 · answered Feb 22 '18 at 08:42

This should be rather a SuperUser question.

Right I have the exact same error inside MacOSX SourceTree, however, inside a iTerm2 terminal, things work just dandy.

However, the problem seemed to be that I've got two ssh-agents running ;(

The first being /usr/bin/ssh-agent (aka MacOSX's) and then also the HomeBrew installed /usr/local/bin/ssh-agent running.

Firing up a terminal from SourceTree, allowed me to see the differences in SSH_AUTH_SOCK, using lsof I found the two different ssh-agents and then I was able to load the keys (using ssh-add) into the system's default ssh-agent (ie. /usr/bin/ssh-agent), SourceTree was working again.

score 0 · Answer 17 · answered Mar 01 '19 at 10:11

0

For me the problem was a wrong copy/paste of the public key into Gitlab. The copy generated an extra return. Make sure what you paste is a one-line key.

answered Mar 01 '19 at 10:11

daniel sp

937
1
11
29

score 0 · Answer 18 · answered Dec 09 '19 at 09:40

I need to share, as I spent too much time looking for a solution

Here was the solution : https://unix.stackexchange.com/a/351742/215375

I was using this command :

ssh-keygen -o -t rsa -b 4096 -C "email@example.com"

gnome-keyring does not support the generated key.

Removing the -o argument solved the problem.

score 0 · Answer 19 · answered Jan 21 '20 at 15:10

What worked here : on the client

1) ssh-add

2) ssh-copy-id user@server

The keys has been created some time ago with plain "ssh-keygen -t rsa" I sw the error message because I copied across my ssh public key from client to server (with ssh-id-copy) without running ssh-add first, since I erroneously assumed I'd added them some time earlier.

score 0 · Answer 20 · answered Apr 15 '20 at 16:14

0

quick note for those recently upgrading to "modern" ssh version [OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 Sep 2019] - supplied with fedora 31, seems not to be anymore accepting old DSA SHA256 keys (mine are dated 2006!) - created a new rsa key, public added to authorized, private on client, and everything works perfectly.

thanks for previous suggestions, especially the ssh -v has been very useful

answered Apr 15 '20 at 16:14

hastalapasta

1

You should definitely get rid of DSA keys or RSA keys <2048 bits. There are ways to allow OpenSSH to use these older keys, but IMO the ONLY time you should enable a legacy protocol is when connecting to hardware that simply can't be updated to use a newer encryption method (and that hardware probably needs replaced TBH). I have a "smart" network connected PDU (power delivery unit), and it only supports some insecure ciphers, so I have a specific exception in my ssh_config for that host, but I also put it onto a separate VLAN that doesn't talk to the internet because it is a security risk. – dragon788 Aug 28 '20 at 13:16

score 0 · Answer 21 · answered Nov 10 '20 at 18:49

As others have mentioned, there can be multiple reasons for this error.

If you are using SSH with Smart Card (PIV), and adding the card to ssh-agent with
ssh-add -s /usr/lib64/pkcs11/opensc-pkcs11.so
you may get the error
sign_and_send_pubkey: signing failed: agent refused operation
from ssh if the PIV authentication has expired, or if you have removed and reinserted the PIV card.

In that case, if you try to do another ssh-add -s you will still get an error:
Could not add card "/usr/lib64/opensc-pkcs11.so": agent refused operation

According to RedHat Bug 1609055 - pkcs11 support in agent is clunky, you instead need to do

ssh-add -e /usr/lib64/opensc-pkcs11.so
ssh-add -s /usr/lib64/opensc-pkcs11.so

score 0 · Answer 22 · answered May 02 '22 at 13:02

Another reason for this is OpenSSH v9.0's new default of NTRU primes + x25519 key exchange, in combination with gpg-agent (at least, as at v2.2.32).

To work-around, disable the new key exchange algortihm (and thus it's security benefit) thus:

ssh -o 'KexAlgorithm -sntrup761x25519-sha512@openssh.com' [...]

(or the same in SSH config.)

cf. https://unix.stackexchange.com/questions/701131/use-ntrux25519-key-exchange-with-gpg-agent

score 0 · Answer 23 · answered Aug 01 '22 at 09:53

0

This could cause by 1Passsword not support ssh-rsa key exchange. They support newer rsa-sha-512 and rsa-sha-256 with security considerations.

https://1password.community/discussion/comment/632712/#Comment_632712

answered Aug 01 '22 at 09:53

zmx

611
6
6

score 0 · Answer 24 · answered Jan 14 '23 at 01:43

Just to toss another cause into the ring...

My env was configured to use a Gemalto card...but I had an old keypair named id_rsa_gemalto_old(.pub) in my ~/.ssh/ and that -- having gemalto in the name -- was enough for git fetch to result in sign_and_send_pubkey: signing failed: agent refused operation.

(Ubuntu 18.04.6)

score 0 · Answer 25 · answered Jun 23 '23 at 21:50

0

If you changed the crypto policy to allow SHA1 after the agent was loaded (with something like update-crypto-policies --set LEGACY) and the remote host uses SHA1, then the agent needs to be reloaded:

kill $SSH_AGENT_PID
eval $(ssh-agent)
ssh-add

answered Jun 23 '23 at 21:50

KJ7LNW

1,437
5
11

How to solve "sign_and_send_pubkey: signing failed: agent refused operation"?

25 Answers25

Linked

Related