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

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












5















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 root@dd.hiast.com
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
root@192.168.1.3's password: My_Password
Now try logging into the machine, with "ssh 'root@192.168.1.3'", 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.
root@192.168.1.3's password:


and as a verbose logging:



[root@dd ~]# ssh -v root@192.168.1.3
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
root@192.168.1.3's password:









share|improve this question
























  • Please add ssh -v 192.168.1.3 to question; -v adds verbose logging.

    – bsd
    May 25 '14 at 9:39











  • @bdowning edited

    – Networker
    May 25 '14 at 9:45















5















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 root@dd.hiast.com
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
root@192.168.1.3's password: My_Password
Now try logging into the machine, with "ssh 'root@192.168.1.3'", 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.
root@192.168.1.3's password:


and as a verbose logging:



[root@dd ~]# ssh -v root@192.168.1.3
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
root@192.168.1.3's password:









share|improve this question
























  • Please add ssh -v 192.168.1.3 to question; -v adds verbose logging.

    – bsd
    May 25 '14 at 9:39











  • @bdowning edited

    – Networker
    May 25 '14 at 9:45













5












5








5


2






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 root@dd.hiast.com
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
root@192.168.1.3's password: My_Password
Now try logging into the machine, with "ssh 'root@192.168.1.3'", 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.
root@192.168.1.3's password:


and as a verbose logging:



[root@dd ~]# ssh -v root@192.168.1.3
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
root@192.168.1.3's password:









share|improve this 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 root@dd.hiast.com
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
root@192.168.1.3's password: My_Password
Now try logging into the machine, with "ssh 'root@192.168.1.3'", 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.
root@192.168.1.3's password:


and as a verbose logging:



[root@dd ~]# ssh -v root@192.168.1.3
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
root@192.168.1.3's password:






linux ssh centos






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 25 '14 at 11:42







Networker

















asked May 25 '14 at 9:36









NetworkerNetworker

6,045104069




6,045104069












  • Please add ssh -v 192.168.1.3 to question; -v adds verbose logging.

    – bsd
    May 25 '14 at 9:39











  • @bdowning edited

    – Networker
    May 25 '14 at 9:45

















  • Please add ssh -v 192.168.1.3 to question; -v adds verbose logging.

    – bsd
    May 25 '14 at 9:39











  • @bdowning edited

    – Networker
    May 25 '14 at 9:45
















Please add ssh -v 192.168.1.3 to question; -v adds verbose logging.

– bsd
May 25 '14 at 9:39





Please add ssh -v 192.168.1.3 to question; -v adds verbose logging.

– bsd
May 25 '14 at 9:39













@bdowning edited

– Networker
May 25 '14 at 9:45





@bdowning edited

– Networker
May 25 '14 at 9:45










3 Answers
3






active

oldest

votes


















5














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.






share|improve this answer
































    3














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



    $ ssh-add





    share|improve this answer
































      1














      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.






      share|improve this answer























      • Does IdentityFile ~/.ssh/id_rsa.pub really work? That should be your public key. You need the private key (without the .pub suffix) there. SSH may figure this out, or else you may have the file named inappropriately.

        – Adam Katz
        Apr 8 '16 at 17:56











      Your Answer








      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "106"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













      draft saved

      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f131882%2fssh-login-doesnt-work-using-a-key-without-password%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      3 Answers
      3






      active

      oldest

      votes








      3 Answers
      3






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      5














      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.






      share|improve this answer





























        5














        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.






        share|improve this answer



























          5












          5








          5







          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.






          share|improve this answer















          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.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Feb 14 at 20:16

























          answered Mar 12 '15 at 1:41









          Adam KatzAdam Katz

          2,2701221




          2,2701221























              3














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



              $ ssh-add





              share|improve this answer





























                3














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



                $ ssh-add





                share|improve this answer



























                  3












                  3








                  3







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



                  $ ssh-add





                  share|improve this answer















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



                  $ ssh-add






                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Jan 2 '16 at 15:41









                  Mohammad

                  469418




                  469418










                  answered May 25 '14 at 11:48









                  NetworkerNetworker

                  6,045104069




                  6,045104069





















                      1














                      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.






                      share|improve this answer























                      • Does IdentityFile ~/.ssh/id_rsa.pub really work? That should be your public key. You need the private key (without the .pub suffix) there. SSH may figure this out, or else you may have the file named inappropriately.

                        – Adam Katz
                        Apr 8 '16 at 17:56
















                      1














                      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.






                      share|improve this answer























                      • Does IdentityFile ~/.ssh/id_rsa.pub really work? That should be your public key. You need the private key (without the .pub suffix) there. SSH may figure this out, or else you may have the file named inappropriately.

                        – Adam Katz
                        Apr 8 '16 at 17:56














                      1












                      1








                      1







                      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.






                      share|improve this answer













                      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.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Apr 7 '16 at 22:37









                      user164804user164804

                      111




                      111












                      • Does IdentityFile ~/.ssh/id_rsa.pub really work? That should be your public key. You need the private key (without the .pub suffix) there. SSH may figure this out, or else you may have the file named inappropriately.

                        – Adam Katz
                        Apr 8 '16 at 17:56


















                      • Does IdentityFile ~/.ssh/id_rsa.pub really work? That should be your public key. You need the private key (without the .pub suffix) there. SSH may figure this out, or else you may have the file named inappropriately.

                        – Adam Katz
                        Apr 8 '16 at 17:56

















                      Does IdentityFile ~/.ssh/id_rsa.pub really work? That should be your public key. You need the private key (without the .pub suffix) there. SSH may figure this out, or else you may have the file named inappropriately.

                      – Adam Katz
                      Apr 8 '16 at 17:56






                      Does IdentityFile ~/.ssh/id_rsa.pub really work? That should be your public key. You need the private key (without the .pub suffix) there. SSH may figure this out, or else you may have the file named inappropriately.

                      – Adam Katz
                      Apr 8 '16 at 17:56


















                      draft saved

                      draft discarded
















































                      Thanks for contributing an answer to Unix & Linux Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f131882%2fssh-login-doesnt-work-using-a-key-without-password%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown