You're mixing up the authentication of the server machine to the client machine, and the authentication of the user to the server machine.
Server authentication
One of the first things that happens when the SSH connection is being established is that the server sends its public key to the client, and proves (thanks to public-key cryptography) to the client that it knows the associated private key. This authenticates the server: if this part of the protocol is successful, the client knows that the server is who it pretends it is.
The client may check that the server is a known one, and not some rogue server trying to pass off as the right one. SSH provides only a simple mechanism to verify the server's legitimacy: it remembers servers you've already connected to, in the ~/.ssh/known_hosts
file on the client machine (there's also a system-wide file /etc/ssh/known_hosts
). The first time you connect to a server, you need to check by some other means that the public key presented by the server is really the public key of the server you wanted to connect to. If you have the public key of the server you're about to connect to, you can add it to ~/.ssh/known_hosts
on the client manually.
Authenticating the server has to be done before you send any confidential data to it. In particular, if the user authentication involves a password, the password must not be sent to an unauthenticated server.
User authentication
The server only lets a remote user log in if that user can prove that they have the right to access that account. Depending on the server's configuration and the user's choice, the user may present one of several forms of credentials (the list below is not exhaustive).
- The user may present the password for the account that he is trying to log into; the server then verifies that the password is correct.
- The user may present a public key and prove that he possesses the private key associated with that public key. This is exactly the same method that is used to authenticate the server, but now the user is trying to prove their identity and the server is verifying them. The login attempt is accepted if the user proves that he knows the private key and the public key is in the account's authorization list (
~/.ssh/authorized_keys
on the server).
- Another type of method involves delegating part of the work of authenticating the user to the client machine. This happens in controlled environments such as enterprises, when many machines share the same accounts. The server authenticates the client machine by the same mechanism that is used the other way round, then relies on the client to authenticate the user.
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.
Best Answer
Lines in the
known_hosts
file are not encrypted, they are hashed. You can't decrypt them, because they're not encrypted. You can't “unhash” them, because that what a hash is all about — given the hash, it's impossible¹ to discover the original string. The only way to “unhash” is to guess the original string and verify your guess.If you have a list of host names, you can pass them to
ssh-keygen -F
and replace them by the host name.¹ In a practical sense, i.e. it would take all the computers existing today longer than the present age of the universe to do it.