Skip to main content
Unix & Linux

Return to Answer

simplified language re: where it's fixed
Source Link
Adam Katz
Adam Katz
  • 4.2k
  • 1
  • 28
  • 35

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@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 754028754028, resolved in Seahorse 3.29.90 (stable 3.30 released 2018-09-03, included in Ubuntu 18.10 via Ubuntu bug 142052218.10 and, Fedora 29, still a bug in Red Hat/CentOS 8and probably Red Hat/CentOS 9). Seahorse before 3.29.90 (and therefore GNOME Keyring) cancould 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.

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 via Ubuntu bug 1420522 and Fedora 29, still a bug in Red Hat/CentOS 8). Seahorse before 3.29.90 (and therefore GNOME Keyring) can 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.

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.

noted the bug fix and where it has landed
Source Link
Adam Katz
Adam Katz
  • 4.2k
  • 1
  • 28
  • 35

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 iswas GNOME bug 754028754028, resolved in Seahorse 3.29.90 (among others and at Ubuntu):(stable 3.30 gnome-keyringreleased 2018-09-03, included in Ubuntu 18.10 via Ubuntu bug 1420522 and seahorseFedora 29, still a bug in Red Hat/CentOS 8). Seahorse before 3.29.90 (and therefore GNOME Keyring) can 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.

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 is GNOME bug 754028 (among others and at Ubuntu): gnome-keyring and seahorse can 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.

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 via Ubuntu bug 1420522 and Fedora 29, still a bug in Red Hat/CentOS 8). Seahorse before 3.29.90 (and therefore GNOME Keyring) can 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.

better bug links
Source Link
Adam Katz
Adam Katz
  • 4.2k
  • 1
  • 28
  • 35

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 is Ubuntu bug 201786GNOME bug 754028 (among others and at Ubuntu): gnome-keyring cannot understandand seahorse can neither create nor add new key types, such as 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 thatan 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 is Ubuntu bug 201786: gnome-keyring cannot understand new key types, such as 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 that 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 is GNOME bug 754028 (among others and at Ubuntu): gnome-keyring and seahorse can 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.

noted that this is per-session, moved backup to a later note, added more links
Source Link
Adam Katz
Adam Katz
  • 4.2k
  • 1
  • 28
  • 35
Source Link
Adam Katz
Adam Katz
  • 4.2k
  • 1
  • 28
  • 35