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.

Simple Solution

I had the same problem at 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

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.

UPDATE:

Temporary solution without uninstalling keyring

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

eval `ssh-agent -s`

ssh-add

or use SSH_AUTH_SOCK=0 ssh your-server

The 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 )

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

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.

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.

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

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!!

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?!

ssh-add

works for me.
But be sure

ssh-agent

is running.

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! :)

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.

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

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.

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.