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

Clash Royale CLAN TAG#URR8PPP
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
add a comment |
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
Please addssh -v 192.168.1.3to question;-vadds verbose logging.
– bsd
May 25 '14 at 9:39
@bdowning edited
– Networker
May 25 '14 at 9:45
add a comment |
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
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
linux ssh centos
edited May 25 '14 at 11:42
Networker
asked May 25 '14 at 9:36
NetworkerNetworker
6,045104069
6,045104069
Please addssh -v 192.168.1.3to question;-vadds verbose logging.
– bsd
May 25 '14 at 9:39
@bdowning edited
– Networker
May 25 '14 at 9:45
add a comment |
Please addssh -v 192.168.1.3to question;-vadds 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
add a comment |
3 Answers
3
active
oldest
votes
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 myserverfails with "ssh Agent admitted failure"SSH_AUTH_SOCK= ssh myserverworks just fine- Conclusion:
gnome-keyringcan'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.
add a comment |
I have solved the problem simply by running this command on the local machine ( after generating the key):
$ ssh-add
add a comment |
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.
DoesIdentityFile ~/.ssh/id_rsa.pubreally work? That should be your public key. You need the private key (without the.pubsuffix) there. SSH may figure this out, or else you may have the file named inappropriately.
– Adam Katz
Apr 8 '16 at 17:56
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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 myserverfails with "ssh Agent admitted failure"SSH_AUTH_SOCK= ssh myserverworks just fine- Conclusion:
gnome-keyringcan'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.
add a comment |
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 myserverfails with "ssh Agent admitted failure"SSH_AUTH_SOCK= ssh myserverworks just fine- Conclusion:
gnome-keyringcan'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.
add a comment |
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 myserverfails with "ssh Agent admitted failure"SSH_AUTH_SOCK= ssh myserverworks just fine- Conclusion:
gnome-keyringcan'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.
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 myserverfails with "ssh Agent admitted failure"SSH_AUTH_SOCK= ssh myserverworks just fine- Conclusion:
gnome-keyringcan'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.
edited Feb 14 at 20:16
answered Mar 12 '15 at 1:41
Adam KatzAdam Katz
2,2701221
2,2701221
add a comment |
add a comment |
I have solved the problem simply by running this command on the local machine ( after generating the key):
$ ssh-add
add a comment |
I have solved the problem simply by running this command on the local machine ( after generating the key):
$ ssh-add
add a comment |
I have solved the problem simply by running this command on the local machine ( after generating the key):
$ ssh-add
I have solved the problem simply by running this command on the local machine ( after generating the key):
$ ssh-add
edited Jan 2 '16 at 15:41
Mohammad
469418
469418
answered May 25 '14 at 11:48
NetworkerNetworker
6,045104069
6,045104069
add a comment |
add a comment |
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.
DoesIdentityFile ~/.ssh/id_rsa.pubreally work? That should be your public key. You need the private key (without the.pubsuffix) there. SSH may figure this out, or else you may have the file named inappropriately.
– Adam Katz
Apr 8 '16 at 17:56
add a comment |
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.
DoesIdentityFile ~/.ssh/id_rsa.pubreally work? That should be your public key. You need the private key (without the.pubsuffix) there. SSH may figure this out, or else you may have the file named inappropriately.
– Adam Katz
Apr 8 '16 at 17:56
add a comment |
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.
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.
answered Apr 7 '16 at 22:37
user164804user164804
111
111
DoesIdentityFile ~/.ssh/id_rsa.pubreally work? That should be your public key. You need the private key (without the.pubsuffix) there. SSH may figure this out, or else you may have the file named inappropriately.
– Adam Katz
Apr 8 '16 at 17:56
add a comment |
DoesIdentityFile ~/.ssh/id_rsa.pubreally work? That should be your public key. You need the private key (without the.pubsuffix) 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
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
Please add
ssh -v 192.168.1.3to question;-vadds verbose logging.– bsd
May 25 '14 at 9:39
@bdowning edited
– Networker
May 25 '14 at 9:45