Ubuntu 16.04 ssh: sign_and_send_pubkey: signing failed: agent refused operation

Question

I just upgraded my Ubuntu System from 15.10 to 16.04 by completely wiping the Ubuntu 15 partition from my system.

After installing Ubuntu 16.04 I recreated my ssh keys as I forgot to back them up, but whenever I attempt to use ssh I get sign_and_send_pubkey: signing failed: agent refused operation this is slightly annoying as it lets me through to my ssh server, but git refuses to push code using ssh.

I have already pushed the keys to the server by using ssh-copy-id.

The Server I am connecting to is a Ubuntu 16.04 Server upgraded through the do-release-upgrade command. Any help will be greatly appreciated.

Answer 1

Looks like an ssh-agent is running already but it can not find any keys attached. To solve this add the private key identities to the authentication agent like so:

ssh-add

Then you can ssh into your server.

in addition, you can see the list of fingerprints of all identities currently added by:

ssh-add -l

Answer 2

Simple Solution

I had the same problem on Ubuntu 18.04. That's all about client-side private key permissions.

$ ssh root@192.168.1.1
sign_and_send_pubkey: signing failed: agent refused operation

The file permissions were too open (0644).

The following command solved it:

chmod 600 ~/.ssh/id_rsa

Answer 3

I had the same problem (same symptoms)

sam@xxxxx:~/.ssh$ ssh centos@123.123.123.123
sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

... but the solution was different.

The problem was coming from the use of GNOME-KEYRING. The post referring to the solution may be read here.

In short:

1. Detect the problem by adding SSH_AUTH_SOCK=0 in front of the ssh command. sam@xxxxx:~/.ssh$ SSH_AUTH_SOCK=0 ssh centos@123.123.123.123
2. In case it succeed to connect. Open the application StartUp Application (by using the search function of the Desktop for example) and disable the use of gnome-keyring.
3. Reboot

The page provide other details in case of similar problem with different solution.

Answer 4

I was getting the sign_and_send_pubkey: signing failed: agent refused operation when logging into several servers and read VonC's answer on Stack Overflow for more information about related bugs. The solution for me was to remove gnome-keyring, delete identities from ssh-agent, and reboot.

sudo apt-get autoremove gnome-keyring
ssh-add -D

Then all my keys started to work perfectly.

Temporary solution without uninstalling keyring

If you want to keep the gnome-keyring on the local computer and you have the agent refused operation error, use:

eval `ssh-agent -s`
ssh-add

or use SSH_AUTH_SOCK=0 ssh your-server.

Permanent solution without uninstalling keyring

If you can, gnome-keyring is compatible with 4096 bit RSA key, so just generate a new key with:

ssh-keygen -t rsa -f ~/.ssh/your-key-name -b 4096 -v -C root

Upload public key to the server:

ssh-copy-id -i ~/.ssh/your-key-name.pub root@12.34.56.78

Add ssh key to the agent:

ssh-add ~/.ssh/your-key-name

This should work without any additional hacks and gnome-keyring can remain installed.

(The -C [username] is optional, but required by providers like Google Cloud.)

Answer 5

After upgrading to Ubuntu 18.04 I got the same error sign_and_send_pubkey: signing failed: agent refused operation. Turns out it was caused by the permissions of the ssh key being too open. The following command fixed the problem for me chmod 600 .ssh/id_rsa

Answer 6

On my system (also Ubuntu 16.04, trying to connect to github), I had a file id_ed25519 in my .ssh folder which made ssh-add failing:

$ ssh-add
Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
Could not add identity "~/.ssh/id_ed25519": communication with agent failed

After removing the files ~/.ssh/id_ed25519* (didn't need them anymore, it was from an earlier test) everything went fine again.

Answer 7

I have a fresh install of Ubuntu16.04 and I experienced similar problems. When I tried to clone my repository from Github after I had copied my public key to github (as per the instructions on github.com) and after carrying out the following check (recommended on github.com):

ssh -T git@github.com

I was greeted by the following:

sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).

To fix it quickly, without removing anything or changing my startup configuration I just typed the following in the terminal:

killall gnome-keyring-daemon

Then the clone worked. I then started the stopped daemon again by typing:

gnome-keyring-daemon

Later, to change things in a more permanent manner, I followed the advice here

Answer 8

Happened to me because my private key had a passphrase. Had to run ssh-add and then it asked for the passphrase and added correctly. However, it now does not ask for my passphrase when ssh'ing to a machine.

Answer 9

After upgrading Fedora 26 to 28 I faced same issue. And no log files

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

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/*

Answer 10

gpg-connect-agent updatestartuptty /bye, then try again.

Answer 11

It's late 2018, and this bug, or variations of it, still plague Xubuntu 16.04, and more than likely other flavors of Xenial. I would not be surprised if it exists in 18.04 as well! It's been around in some form since 2009, and Karmic Koala. Has affected Redhat, Debian and Ubuntu. Don't take my word for it, see the public bugtrackers:

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/470456

And at that bug, you also find listings for the other 3:

References:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523322

https://bugzilla.redhat.com/show_bug.cgi?id=508286

https://bugzilla.gnome.org/show_bug.cgi?id=576700

In my case, the most obvious symptom was inability to use ssh keys with passphrases. It may affect ones without as well, since the malfunction prevents ssh keys from loading at all! And I had no permissions problems, it was all gnome-keyring. My keys (yes it refused several, for different SSH servers!) permissions were all 600 (rw for owner, nothing for group or other) as stated in many answers about that. So nothing I could change there.

In Xubuntu, there is a way to disable startup items. Usually also possible in Unity/Gnome/KDE, but I don't have those installed, so can't give specific steps. Not sure of other desktops. Rather than disable SSH agent, GPG agent and other items from Gnome that cause this, and other related bugs, I turned off all Gnome startup items. May be overkill or not an option for some, but SSH is back to working flawlessly on the next reboot!

1. Open the Whisker Main Menu -> Settings -> Session and Startup.
2. Click the Advanced tab, last one on the right.
3. Uncheck (turn off) Launch Gnome Services on startup.
4. Close and reboot. Logging out may do it too, but reboot should for sure.

Screenshot of GUI described above:

So, since I gave my fix above, I do hope someone will fix it.

Ubuntu has provably failed to squash it for good, since there are lots of tickets for several releases which claim it is fixed, and more that say "regression", it's back.

Debian probably wants to punt (wash their hands of it) because it's not them, upstream is Gnome.

Redhat probably has a fix only available to paying customers. Because, historically, Redhat is the single biggest employer of paid Gnome developers, which is generous at first glance. Until you realize that means they have financial incentive never to put fixes like this into the free versions, to keep selling Redhat subscriptions.

Gnome is probably the ones who can fix it upstream easiest, and then the others can test and package, without writing a line of code themselves. But the tickets I read say the package has languished for years without an official maintainer! And the two people who voluntarily do so now (thank you) are almost as busy designing a replacement. Why not fix a flat tire even if it takes a year (it's been a decade!) instead of reinventing the wheel first?!

Answer 12

Adding comment as I had the same issue with ed25519 keys. The issue is indeed gnome-keyring. To fix this I did the following:

• Unchecked ssh-key-agent (gnome-keyring) in "startup applications"
• Killed off the ssh-agent and gnome agent: (killall ssh-agent ; killall gnome-keyring-daemon)
• Re-started the daemon: (eval ssh-agent -s)
• Add your key: $ ssh-add id_ed25519 Enter passphrase for id_ed25519: Identity added: id_ed25519
• Profit!!

Answer 13

ssh-add

works for me. But be sure

ssh-agent

is running.

Answer 14

In my case the issue was caused by GNOME Keyring. To disable gnome-keyring's SSH capabilities without outright removing it (which breaks a lot of things), follow these instructions:

cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart
echo Hidden=true >> ~/.config/autostart/gnome-keyring-ssh.desktop

and restart the session. Now you can run ssh-agent without gnome-keyring interfering.

Answer 15

My problem was that during update from Debian Stretch to Debian Buster I was forced to move to systemd (due to losing access to shutdown/reboot buttons in XFCE), and it stopped working with same error.

Finally found Debian bug #851440 with solution: apt-get install dbus-user-session. Apparently it is needed if you want to use gpg-agent (used for OpenPGP smartcard, for example) and pinentry-gnome3 under systemd (it wasn't needed under sysvinit, and system upgrade didn't install it)

Answer 16

If adding SSH_AUTH_SOCK=0 before ssh command helps, then it is gnome keyring fault. Except provided solutions and problems, issue may be related with passphrase. If you have passphrase for key then gnome keyring asks it when you login for first time and if you enter empty by fault or unexpectedly close window, gnome assumes it as empty passphrase and remembers it forever. Nothing helps to be prompted again for passphrase. To solve open ssh keyring app and go to Login section under Passwords category. Find record corresponding for problematic key and enter to Properties and enter correct passphrase.

Answer 17

There is another cause of this which is not in any answer yet: the PEM format for the key file stopped being the default for ssh-keygen before Ubuntu moved to a gnome-keyring-daemon that supports the new RFC4716 format.

If you generate a new key, or add/remove a passphrase from your key, it may break. The key is using ssh-keygen -m PEM before whatever other operation you need to run. For example, you can convert back to the old format by using ssh-keygen -m PEM -p and entering the old passphrase as the new passphrase (which would be empty for no passphrase).

Answer 18

If you're a KeepassXC user you might be interested in that GitHub post

There Lgmrszd answered:

Can confirm this bug. It happens if "Require user confirmation.." checkbox enabled, after disabling it and restarting keepassxc it works fine.

I hope that can resolve that special case for some of you.

Answer 19

I tried a couple of things, among others ssh-add, resetting SSH (deleting .ssh/ on the server, and such, but no luck. So it turned out I just had to sleep over it for one night. It helped! Why? I guess the ssh-agent running on the server had something in its cache which was refreshed later that night with the now proper values. Anyhow, it now works like a charm. To wrap up, it did this (Ubuntu 16.04 on localhost, 14.04 on server).

# on local host:
$ ssh-keygen
# (yes, overwrite the default file, and let the passphrase be empty)
$ ssh-copy-id ***.***.*.**
# (insert proper server IP address)
# now test
$ ssh ***.***.*.**
# this should have erected in .ssh/ on the server:
# -rw------- 1 *** *** 2000 aug.  11 09:55 authorized_keys
# no other magic going on! :)

Answer 20

I ended up dropping my known hosts file and it worked. Had to put in a password again, but it finally accepted the right password. It was after a new install.