Configuring a new Digital Ocean droplet with SSH keys. When I run
ssh-copy-id this is what I get:
ssh-copy-id [email protected] /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys sign_and_send_pubkey: signing failed: agent refused operation [email protected]'s password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh '[email protected]'" and check to make sure that only the key(s) you wanted were added.
However, when I then attempt to ssh in, this happens:
ssh [email protected] sign_and_send_pubkey: signing failed: agent refused operation [email protected]'s password:
Upon entering the password, I am logged in just fine, but this of course defeats the purpose of creating the SSH key in the first place. I decided to take a look at the ssh-agent server-side and here's what I get:
[email protected]:~# eval `ssh-agent -s` Agent pid 5715 [email protected]:~# ssh-add -l The agent has no identities.
user/.ssh/authorized_keys does contain an ssh-rsa key entry, as well, but
find -name "keynamehere" returns nothing.
ssh-add on the client machine, that will add the SSH key to the agent.
ssh-add -l (again on the client) that it was indeed added.
After upgrading Fedora 26 to 28 I faced same issue. And following logs were missing
[email protected] ~ ssh [email protected].com 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/*
I was having the same problem in Linux Ubuntu 18. After the update from Ubuntu 17.10, every git command would show that message.
The way to solve it is to make sure that you have the correct permission on the
Check the current chmod number by using
stat --format '%a' <file>.
It should be 600 for
id_rsa and 644 for
To change the permission on the files use
chmod 600 id_rsa chmod 644 id_rsa.pub
That solved my issue with the update.
I had the error when using gpg-agent as my ssh-agent and using a gpg subkey as my ssh key https://wiki.archlinux.org/index.php/GnuPG#gpg-agent.
I suspect that the problem was caused by having an invalid pin entry tty for gpg caused by my sleep+lock command used in my sway config
bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock'"
or just the sleep/suspend
Reset the pin entry tty to fix the problem
gpg-connect-agent updatestartuptty /bye > /dev/null
and the fix for my sway sleep+lock command:
bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock; gpg-connect-agent updatestartuptty /bye > /dev/null'"
To this error:
# git pull sign_and_send_pubkey: signing failed: agent refused operation [email protected]: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
Verify or add again the public key in Github account > profile > ssh.
I solved like this:
# chmod 400 ~/.ssh/id_rsa # ls ~/.ssh/id_rsa -ls 4 -r--------. 1 reinaldo reinaldo 1679 Jul 26 2017 /home/reinaldo/.ssh/id_rsa # git pull remote: Counting objects: 35, done. remote: Compressing objects: 100% (19/19), done. remote: Total 35 (delta 9), reused 34 (delta 9), pack-reused 0 Unpacking objects: 100% (35/35), done.
There could be various reason for getting the SSH error:
sign_and_send_pubkey: signing failed: agent refused operation
Some of them could be related to the issues highlighted by the other answers (see this thread answers), some of them could be hidden and thus would require a closer investigation.
In my case I've got the following error message:
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]: Permission denied (publickey,gssapi-keyex,gssapi-with-mic)
The only way to find the real problem was to invoke the -v verbose option which resulted in printing a lot of debugging info:
debug1: Connecting to website.domain.com [xxx.xxx.xxx.xxx] port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/id_rsa.website.domain.com type 0 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_rsa.website.domain.com-cert type -1
Please note that the line saying
key_load_public: No such file or directory is referring the next line and not the previous line.
So what SSH really says is that it could not find the public key file named
id_rsa.website.domain.com-cert and that seemed to be the problem in my case since my public key file did not contain the
Long story short: the fix in my case was just to make sure that the public key file was named as expected. I could never suspected that without debugging the connection.
The bottom line is USE THE SSH VERBOSE MODE (-v option) to figure out what is wrong, there could be various reasons, none that could be found on this/another thread.
This should be rather a SuperUser question.
Right I have the exact same error inside MacOSX SourceTree, however, inside a iTerm2 terminal, things work just dandy.
However, the problem seemed to be that I've got two
ssh-agents running ;(
The first being
/usr/bin/ssh-agent (aka MacOSX's) and then also the HomeBrew installed
Firing up a terminal from SourceTree, allowed me to see the differences in
lsof I found the two different
ssh-agents and then I was able to load the keys (using
ssh-add) into the system's default
/usr/bin/ssh-agent), SourceTree was working again.
Yes. Run ssh-add on the client machine. Then repeat command ssh-copy-id [email protected]
For me the problem was a wrong copy/paste of the public key into Gitlab. The copy generated an extra return. Make sure what you paste is a one-line key.
I got a
sign_and_send_pubkey: signing failed: agent refused operation error as well. But in my case the problem was a wrong
pinentry-program property was pointing to an old pinentry path. Correcting the path there and restarting the
gpg-agent fixed it for me.
I discovered it by following the logs with
journalctl -f. There where log lines like the following containing the wrong path:
Jul 02 08:37:50 my-host gpg-agent: ssh sign request failed: No pinentry <GPG Agent> Jul 02 08:37:57 my-host gpg-agent: can't connect to the PIN entry module '/usr/local/bin/pinentry': IPC connect call failed