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

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 3

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

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

Then all my keys started to work perfectly.

Answer 4

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 5

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 6

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 7

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 8

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.