Configuring a new Digital Ocean droplet with SSH keys. When I run ssh-copy-id
this is what I get:
ssh-copy-id user@012.345.67.89
/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
user@012.345.67.89's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'user@012.345.67.89'"
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 user@012.345.67.89
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89'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:
user@012.345.67.89:~# eval `ssh-agent -s`
Agent pid 5715
user@012.345.67.89:~# 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.
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
id_rsa
andid_rsa.pub
.Check the current chmod number by using
stat --format '%a' <file>
. It should be 600 forid_rsa
and 644 forid_rsa.pub
.To change the permission on the files use
That solved my issue with the update.
To this error:
I solved like this:
Thank you.
There could be various reason for getting the SSH error:
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:
The only way to find the real problem was to invoke the -v verbose option which resulted in printing a lot of debugging info:
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-cert
suffix.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.
Yes. Run ssh-add on the client machine. Then repeat command ssh-copy-id userserver@012.345.67.89
Run
ssh-add
on the client machine, that will add the SSH key to the agent.Confirm with
ssh-add -l
(again on the client) that it was indeed added.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.