144

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.

17 Answers 17

269

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
  • it's not -1 (number <one>), it's -l (lowercase L) in your second command – Daniel Alder Jun 11 '16 at 15:31
  • 3
    @Daniel Alder It IS indeed lower case l. – Ron Jun 11 '16 at 15:38
  • You are right, sorry. Problem is the lower-case L of the font "Liberation Mono" :-( – Daniel Alder Jun 12 '16 at 13:42
  • 1
    I do not think you should use ssh-add other than to use ssh-add -l because you can end up with too many entries in the ssh-agent. There is no need to manually add. Dash > Startup Applications shows that ssh-agent is already running and it will automatically detect the files such as ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub. To prove this you can use ssh-add -l before and after using ssh-keygen. You will see that it monitors the for the files so you don't have to add them manually. – H2ONaCl Jan 26 '17 at 8:20
  • 1
    Likewise do not use ssh-add -d and ssh-add -D to perform manual deletion. Just delete the key files ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub and the ssh-agent will notice. To prove that you can do ssh-add -l before and after deleting the key files. – H2ONaCl Jan 26 '17 at 8:24
42

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.

  • 14
    Your solution half-worked for me (different problem with similar symptoms). Using step 1 I got the error message Permissions 0775 for '.ssh/id_rsa' are too open. The simple solution here was to chmod 600 .ssh/id_rsa. – Matt Mar 26 '18 at 16:25
  • This also helps debugging not only ssh shell connection but also git ssh auth. Used this command SSH_AUTH_SOCK=0 before git pull and got permissions warning like Matt. – Serge Nov 24 '18 at 12:45
  • Worked for me as well. Apparently the reason was that I have changed comment in my key and most probably the gnome keyring agent (aka SeaHorse) was still keeping the old version in the memory – maoizm Dec 11 '18 at 12:09
22

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
  • 2
    The path should be absolute like this: chmod 600 ~/.ssh/id_rsa to make it work on all cases. – Omar Alahmed Oct 14 '18 at 7:59
15

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 )

  • 2
    Yes but this removes all the ssh-agent functionality which is super useful – Martin Konecny Jan 17 '17 at 15:42
  • please note us in which PC to use sudo apt-get, our own computer or remote server. thanks. – Shicheng Guo Jun 15 '17 at 3:52
  • Keyring on your own local PC, because Keyring is part of GNOME, it is not usually installed on server at all. – Mike Jun 15 '17 at 6:20
  • 1
    @MartinKonecny well, it just removes the ssh agent that is provided by gnome, it does not remove the plain and simple console ssh-agent (if you have that installed). The problem is that the gnome variety gets in the way of the normal ssh-agent. You can still start ssh-agent and enter private key passwords on the console/shell. – blubberdiblub Mar 18 '18 at 3:15
12

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

8

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.

  • 2
    And what if you do need them? – Gringo Suave Oct 20 '16 at 23:33
  • @GringoSuave Good question. Did you try? Maybe the format changed or is not supported anymore by ssh - or it's a bug. Personally, I was happy that I didn't have to test it out... – Daniel Alder Oct 21 '16 at 9:39
  • Still not working for me, I have no solution: Could not add identity "~/.ssh/id_ed25519": communication with agent failed, agent running and configured as far as I can tell. – Gringo Suave Oct 21 '16 at 19:09
  • 2
    @GringoSuave the solution here is also to get rid of the gnome authentication agent which foists an agent socket onto your shell in place of the plain ssh-agent socket. The plain ssh-agent is able to handle ED25519 keys whereas the gnome authentication agent is not (besides other problems it causes). See the answer of sam askubuntu.com/a/835114/167846 or Mike askubuntu.com/a/762968/167846 – blubberdiblub Mar 18 '18 at 3:20
7

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.

3

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

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

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:

Image

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

1

ssh-add

works for me. But be sure

ssh-agent

is running.

0

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

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.

0

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

0

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.

0

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.

0

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

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.