KeeAgent is mistaken SSH key

[crazy-max]

While I added my SSH keys on KeePass, I have not been able to connect via PuTTY to one of my servers.

From my research, KeeAgent is mistaken SSH key and gets another SSH key present on KeePass. By removing the presumed key, I finally was able to connect.
So I think there is a problem in verifying the SSH key to transmit. What is the method to check how KeeAgent key belongs to the correct server?

Thanks!

[dlech]

Keys are selected by looking at the public key. If you open the two conflicting keys in PuTTYgen, do they have the same public key?

The exchange with the server goes something like this:

• putty asks KeeAgent for a list of public keys of all of the keys.
• These are sent to server.
• If server has a public key that matches one from the list, then it sends a request back to putty to use that key.
• putty asks KeeAgent for the matching private key and uses it to encrypt the connection.

[crazy-max]

Ok but in my case public keys are different.
How can i debug?

[dlech]

You can try enabling logging in putty. In the Logging settings, select 'SSH packets and raw data'. This should give some insight into what is going on.

[crazy-max]

I have logged the SSH packets :

Event Log: Writing new session log (SSH packets mode) to file: E:putty.log
Event Log: Looking up host "192.168.0.7"
Event Log: Connecting to 192.168.0.7 port 22
Event Log: Server version: SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2
Event Log: Using SSH protocol version 2
Event Log: We claim version: SSH-2.0-PuTTY_KiTTY
Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Event Log: Doing Diffie-Hellman group exchange
Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEX_DH_GEX_REQUEST)
Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEX_DH_GEX_GROUP)
Event Log: Doing Diffie-Hellman key exchange with hash SHA-256
Outgoing packet #0x2, type 32 / 0x20 (SSH2_MSG_KEX_DH_GEX_INIT)
Incoming packet #0x2, type 33 / 0x21 (SSH2_MSG_KEX_DH_GEX_REPLY)
Event Log: Host key fingerprint is:
Event Log: ssh-rsa 2048 cf:b4:88:f9:0a:3b:98:9f:e8:7e:c3:2e:9e:0d:74:f8
Outgoing packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA1 client->server MAC algorithm
Incoming packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA1 server->client MAC algorithm
Outgoing packet #0x4, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
Incoming packet #0x4, type 6 / 0x06 (SSH2_MSG_SERVICE_ACCEPT)
Event Log: Pageant is running. Requesting keys.
Event Log: Pageant has 7 SSH-2 keys
Outgoing packet #0x5, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x5, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
Event Log: Trying Pageant key #0
Outgoing packet #0x6, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x6, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
Event Log: Server refused our key
Event Log: Trying Pageant key #1
Outgoing packet #0x7, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x7, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
Event Log: Server refused our key
Event Log: Trying Pageant key #2
Outgoing packet #0x8, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x8, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
Event Log: Server refused our key
Event Log: Trying Pageant key #3
Outgoing packet #0x9, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x8, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
Event Log: Server refused our key
Event Log: Trying Pageant key #4
Outgoing packet #0x9, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x8, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
Event Log: Server refused our key
Event Log: Trying Pageant key #5
Outgoing packet #0x9, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0xb, type 1 / 0x01 (SSH2_MSG_DISCONNECT)
Event Log: Received disconnect message (protocol error)
Event Log: Disconnection message text: Too many authentication failures for crazymax
Event Log: Server sent disconnect message
type 2 (protocol error):
"Too many authentication failures for crazymax"

As you can see from the logs, I have SSH keys 7. That's good, he sees all the keys.
Event Log: Pageant has 7 SSH-2 keys

PuTTY then checks all keys found and this is the part that I find weird. After 6 keys verified, there is the following message: "Too many authentication failures for crazymax"

Thus removing one of the key present on KeePass PUTTY finally arrives at the key and validates the connection to the server. The problem is therefore the number of audits of keys. How to increase the number of audits or tell PuTTY to take the right key according to the fingerprint?

Thanks!

[crazy-max]

I found how to increase the number of audits of keys.
Server-side in the /etc/ssh/sshd_config file i have added the MaxAuthTries parameter which is to 6 by default but I would prefer to disable this check if you've got a solution :)

In the PuTTY manual, I found this: http://rc.quest.com/topics/putty/doc.php#errors-toomanyauth. Maybe it could help you.

[dlech]

Thanks for the tip. This got me going in the right direction.

Unfortunately, there is not a good solution without modifying PuTTY itself. So, all I can offer is a couple of other workarounds in addition to the one above.

1. Only use one key (or up to 6 keys) for all of your servers. I know - this is probably not agreeable to many people.
2. Keep a copy of your ssh keys on the hard drive in addition to KeePass. Setup PuTTY to read that file per http://rc.quest.com/topics/putty/doc.php#config-ssh-privkey. When PuTTY tries to connect to a server, it will read the public key from the file on your hard drive. Then, it will find the matching key in KeePass and use it for authentication instead of trying all of the keys.

[ghost]

Option 2 defeats the purpose of using KeeAgent in the first place.

I do not want the key files in anything but keepass so they are never exposed in cleartext.

[dlech]

In the latest beta (v0.3.x) I have added some new features that provide other ways of working around this problem.

http://lechnology.com/KeeAgent+Beta

[ghost]

Interesting solutions, great work!

This happened when I didn't select an attachment. I figured that perhaps it was set to add *.ppk if there was only one available. I like where you're going with this, but there are a few steps that can be taken to lean more toward the side of automation. It yielded the general feeling of "This is too many clicks to add a key" However, these fine grained controls are extremely useful and necessary, and I'm glad you've implemented them. I wouldn't see a problem if right-clicking -> Load entry... did add the first *.ppk it saw in the entry.

Another thought is perhaps adding a column in the "List View" that shows whether or not it's enabled with KeeAgent.

If you need me to file any formal bug/feature requests let me know. Thanks for your work.

[dlech]

If you need me to file any formal bug/feature requests let me know. Thanks for your work.

Good suggestions! I went ahead and created new issues for each idea. In the future, just go ahead and create an issue for each idea or problem that you have.

[ghost]

Alright, no problem. Thanks for listening!

[crazy-max]

@dlech I will check the latest beta. Thanks :)