SSH Login doesn't work using a key Without Password?

Question

Agent admitted failure to sign using the key

I'm working on centos6.5(32bit) and I have tried to ssh log in without Password Using ssh-keygen & ssh-copy-id? the steps that I have done:

first I created the key:

[root@dd ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
/root/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
8f:48:0b:04:3a:e1:90:f4:9f:de:2a:33:63:ea:a8:82 [email protected]
The key's randomart image is:
+--[ RSA 2048]----+
|+o.              |
|+o..             |
|o. ..            |
| . .. .          |
|    .o. S        |
|    .o.o o       |
|.    .o.. .      |
|E  *  .          |
|*oo =.           |
+-----------------+

then I copy the key to the remote host:

[root@dd ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub 192.168.1.3
[email protected]'s password: My_Password
Now try logging into the machine, with "ssh '[email protected]'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

then I try to login but it fails (with key):

[root@dd ~]# ssh 192.168.1.3
Agent admitted failure to sign using the key.
[email protected]'s password: 

and as a verbose logging:

[root@dd ~]# ssh -v [email protected]
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.3 [192.168.1.3] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.3' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information 
Cannot determine realm for numeric host address

debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
Cannot determine realm for numeric host address

debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
Agent admitted failure to sign using the key.
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
[email protected]'s password: 

Answer 1

You were suffering from the following failure:

Agent admitted failure to sign using the key.

This is an unfortunately non-diagnostic message. There are (at least) two classes of issues it could address:

 

The key is not loaded

For most issues, this means that your ssh-agent doesn't have any ssh keys loaded that are accepted for your account on the target server. In this case, as noted by @Networker's answer to this question, the solution is rather simple: add the key:

ssh-add

If the key is in a non-default location, you'll need to tell that to ssh-add:

ssh-add /path/to/key

 

The agent cannot understand the key

This was GNOME bug 754028, resolved in Seahorse 3.29.90 (stable 3.30 released 2018-09-03, included in Ubuntu 18.10, Fedora 29, and probably Red Hat/CentOS 9). Seahorse before 3.29.90 (and therefore GNOME Keyring) could neither create nor add new key types like ed25519 and keys generated with ssh-keygen -o -a 100 (as suggested by the Secure Secure Shell tutorial).

Diagnosis of this problem:

• ssh myserver fails with "ssh Agent admitted failure"
• SSH_AUTH_SOCK= ssh myserver works just fine
• Conclusion: gnome-keyring can't deal with complex keys

As I just found a viable workaround for this bug, and it doesn't seem to be published anywhere (except the comment I just added to an Ubuntu bug), I'll put it here.

Workaround: Launch a new ssh-agent using the same socket as the one from gnome-keyring:

ssh-agent -a $SSH_AUTH_SOCK

This launches a new instance of ssh-agent (overwriting GNOME's less capable instance), so it won't have any keys in it (despite what seahorse says, since that's tied to the old agent). You'll have to add them via ssh-add as noted in the The key is not loaded section above.

You'll have to run this every time you log in (or manually add it to your startup scripts). If you want to preserve the old socket, run mv $SSH_AUTH_SOCK $SSH_AUTH_SOCK.broken first.

Answer 2

I have solved the problem simply by running this command on the local machine ( after generating the key):

$ ssh-add

Answer 3

I added:

Host github.com
  HostName github.com
  User YOURUSERNAME
  IdentityFile ~/.ssh/id_rsa.pub

to my ~/.ssh/config file to circumvent this problem and looks to be working.