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.


20 Answers 20


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:


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
  • 3
    it's not -1 (number <one>), it's -l (lowercase L) in your second command Jun 11, 2016 at 15:31
  • 6
    @Daniel Alder It IS indeed lower case l.
    – Ron
    Jun 11, 2016 at 15:38
  • 2
    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, 2017 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, 2017 at 8:24
  • 4
    had to change the permission of my key to 0400 before adding it
    – pensan
    May 11, 2018 at 7:34

Simple Solution

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

$ ssh [email protected]
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
  • 3
    If you are using Ed25519 you should execute: chmod 600 ~/.ssh/id_ed25519 Jan 14, 2020 at 22:43
  • 5
    This is the correct answer if anyone ends up here because of copying the key from one computer to another. That was what was happening in my case.
    – m4l490n
    Feb 27, 2020 at 15:50
  • 1
    I had the exact same problem and this solved it for me. Just a small addition, even if you have something more than 600, it won't work, at least it didn't for me. So just set them to 600. And the .ssh folder to 700, by the way. Mar 19, 2020 at 10:49
  • 1
    600 mean this key is read and write only by the owner.
    – logbasex
    Nov 5, 2020 at 8:32
  • 1
    this answer should be marked as right answer
    – fahim152
    Dec 7, 2020 at 5:21

I had the same problem (same symptoms)

sam@xxxxx:~/.ssh$ ssh [email protected]
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 [email protected]
  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.

  • 25
    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, 2018 at 16:25
  • 3
    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. Nov 24, 2018 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, 2018 at 12:09
  • +1 for the method to check if this is GNOME keyring related
    – silverdr
    Dec 10, 2019 at 14:04
  • my initial problem was that i had first a set of keys from a template and later generated my own keys on the command line. then e.g. git pull failed for me. having it working with the =0 prefix text hinted me for gnome-keyring problems. trying the solution given in some other post solved it. commands were: eval ssh-agent -s ssh-add Feb 18, 2020 at 14:38

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`

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 [email protected]

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 Jan 17, 2017 at 15:42
  • Keyring on your own local PC, because Keyring is part of GNOME, it is not usually installed on server at all.
    – Mike
    Jun 15, 2017 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. Mar 18, 2018 at 3:15
  • This works if you've set to automatically login to your DE without entering your password, because then in fact your gnome-keyring won't be unlocked.
    – xjcl
    Apr 15, 2019 at 16:46
  • This work for me !Thank you!
    – linjiejun
    Nov 14, 2021 at 11:24

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.

  • 2
    And what if you do need them? Oct 20, 2016 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... Oct 21, 2016 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. Oct 21, 2016 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 Mar 18, 2018 at 3:20

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.


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 [email protected]

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:


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


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 [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'s password:

error message is not pointing actual issue. Issue resolved by

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

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

  • While this may answer the question, it would be better if you could include some context around the code.
    – Mark Kirby
    Oct 28, 2019 at 22:28

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:


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





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



works for me. But be sure


is running.


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.


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)

  • Thanks for this. The steps mentioned in the ticket worked for me, although curiously I already have dbus-user-session installed. Apr 6, 2020 at 21:07

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.


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.


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


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .