Strange SSH key behavior?

664 views
Skip to first unread message

Doug Kelly

unread,
Jul 8, 2015, 9:52:07 AM7/8/15
to repo-d...@googlegroups.com
While testing the ECDSA support added in recent versions of Gerrit -- specifically 2.10.5 here (I figured it'd be a worthwhile use of my time, since I had a user asking me about it)... I was testing by moving my normal RSA private key to ~/.ssh/id_rsa.save, then trying to log in, and would find my ECDSA key would be rejected.  Eventually, I tried deleting all keys but the ECDSA key from the server and found I was able to log in normally.  Re-adding the RSA public key would again break login... and moving the matching public key to a different name would also fix login.

While this seems like an unlikely scenario to occur, it does seem important to address.  One key failure should not be affecting the success/failure of other key pairs, and indeed, OpenSSH has the behavior I would expect: if the RSA key fails (because the associated private key is missing), the ECDSA key still succeeds.  I can think of a few times where I've had users that inexplicably received permission denied errors, and now I wonder if this may have been related.

This may be an issue upstream in MINA (though I didn't find any reports that seemed relevant), or it may be something like an error condition not getting reset when trying the new key.  Does anyone else have any thoughts?

David Ostrovsky

unread,
Jul 8, 2015, 10:57:20 AM7/8/15
to repo-d...@googlegroups.com

Am Mittwoch, 8. Juli 2015 15:52:07 UTC+2 schrieb Doug Kelly:
While testing the ECDSA support added in recent versions of Gerrit -- specifically 2.10.5 here (I figured it'd be a worthwhile use of my time, since I had a user asking me about it)... I was testing by moving my normal RSA private key to ~/.ssh/id_rsa.save, then trying to log in, and would find my ECDSA key would be rejected.  Eventually, I tried deleting all keys but the ECDSA key from the server and found I was able to log in normally.

This sounds like a bug. After configuring a Gerrit project to use ECDSA key, this should work,
no matter what happens with RSA key. The better question is: Is this upstream MINA bug or
Gerrit bug?

Doug Kelly

unread,
Jul 8, 2015, 11:37:18 AM7/8/15
to repo-d...@googlegroups.com
Exactly my thought.  It could be either, since Gerrit extends MINA by handling the key validation... Hopefully the Gerrit side is at least relatively easy to rule out, though. 

Alex Blewitt

unread,
Jul 8, 2015, 11:54:50 AM7/8/15
to Doug Kelly, repo-d...@googlegroups.com
Can you show the log of ssh -v -v -v when you have both keys present to verify that it's sending both?

Sent from my iPhat 6
--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Doug Kelly

unread,
Jul 8, 2015, 12:02:05 PM7/8/15
to repo-d...@googlegroups.com, doug...@gmail.com
Absolutely; Here's where I have the public key in place (but the private RSA key is missing): from the looks of it, the client sends the RSA public key, fails to find the private key, then bails out and sends another publickey packet, which the server just rejects.

OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014
debug1: Reading configuration data /h/.ssh/config
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxxxxxx [xxxxxxx] port 29418.
debug1: Connection established.
debug1: identity file /h/.ssh/id_rsa type 1
debug1: identity file /h/.ssh/id_rsa-cert type -1
debug1: identity file /h/.ssh/id_dsa type -1
debug1: identity file /h/.ssh/id_dsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/h/.ssh/id_ecdsa" as a RSA1 public key
debug1: identity file /h/.ssh/id_ecdsa type 3
debug1: identity file /h/.ssh/id_ecdsa-cert type -1
debug1: identity file /h/.ssh/id_ed25519 type -1
debug1: identity file /h/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version GerritCodeReview_2.10.5 (SSHD-CORE-0.14.0)
debug1: no match: GerritCodeReview_2.10.5 (SSHD-CORE-0.14.0)
debug2: fd 3 setting O_NONBLOCK
debug3: put_host_port: [xxxxxxx]:29418
debug3: load_hostkeys: loading entries for host "[xxxxxxx]:29418" from file "/h/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /h/.ssh/known_hosts:61
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-...@openssh.com,ssh-rsa-...@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve255...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes12...@openssh.com,aes25...@openssh.com,chacha20...@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijnda...@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes12...@openssh.com,aes25...@openssh.com,chacha20...@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijnda...@lysator.liu.se
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit: none,zl...@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,aes128-ctr,arcfour128
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,aes128-ctr,arcfour128
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: setup hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug2: bits set: 1018/2048
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA 44:52:c8:de:1b:50:0c:0f:3e:67:dc:0d:9d:a7:e0:6e
debug3: put_host_port: [xxxxxxx]:29418
debug3: put_host_port: [xxxxxxx]:29418
debug3: load_hostkeys: loading entries for host "[xxxxxxx]:29418" from file "/h/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /h/.ssh/known_hosts:61
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "[xxxxxxx]:29418" from file "/h/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /h/.ssh/known_hosts:61
debug3: load_hostkeys: loaded 1 keys
debug1: Host '[xxxxxxx]:29418' is known and matches the RSA host key.
debug1: Found key in /h/.ssh/known_hosts:61
debug2: bits set: 1042/2048
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /h/.ssh/id_rsa (0xa0218e8),
debug2: key: /h/.ssh/id_dsa (0x0),
debug2: key: /h/.ssh/id_ecdsa (0xa021a70),
debug2: key: /h/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /h/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp b2:0e:a6:0d:07:ef:96:7b:e6:0e:fc:f7:ea:5e:63:10
debug3: sign_and_send_pubkey: RSA b2:0e:a6:0d:07:ef:96:7b:e6:0e:fc:f7:ea:5e:63:10
debug3: no such identity: /h/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /h/.ssh/id_dsa
debug3: no such identity: /h/.ssh/id_dsa: No such file or directory
debug1: Offering ECDSA public key: /h/.ssh/id_ecdsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Trying private key: /h/.ssh/id_ed25519
debug3: no such identity: /h/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

(I figured this is the most interesting log, and I had looked at this before, but I didn't notice until just now that it almost looks like a state machine getting messed up when the client bails on the RSA key...)

--Doug
Reply all
Reply to author
Forward
0 new messages