Details
-
Bug
-
Resolution: Handled by Support
-
Medium
Description
[This ticket is a follow up of a change in 2016. Original ticket: BBS-35401]
Dear Atlassian,
Bitbucket SSH server drop the connection in some cases when an unsupported RSA public key is offered for authentication.
I normally use a hardware token with a 1024bit rsa key. This key size is not supported by bitbucket since 2016, so I generate a software token for bitbucket access.
Unfortunately when my hardware key precedes the software key at the authentication then bitbucket disconnects and doesn't wait for the software key to offered.
Details
This is what happens when the 1024bit key is offered first:
#!bash mrbig@toodark:~ $ ssh-add -l 1024 a7:83:14:47:7b:a1:ae:45:6b:c9:be:01:5c:74:7d:20 Private Key (RSA1) 1024 c6:f4:4b:b9:64:59:00:1a:fd:3c:ea:0a:fe:dd:4f:0a Private Key (RSA) 2048 9c:53:e4:1b:07:9d:b6:50:cc:4a:09:a4:41:f5:93:5a .ssh/id_rsa_bitbucket (RSA) mrbig@toodark:~ $ ssh -v -T git@bitbucket.org OpenSSH_5.1p1 Debian-6, OpenSSL 0.9.8m 25 Feb 2010 debug1: Reading configuration data /home/mrbig/.ssh/config debug1: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to bitbucket.org [2406:da00:ff00::6b17:d1f5] port 22. debug1: Connection established. debug1: identity file /home/mrbig/.ssh/identity type -1 debug1: identity file /home/mrbig/.ssh/id_rsa type -1 debug1: identity file /home/mrbig/.ssh/id_dsa type 2 debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 debug1: Remote protocol version 2.0, remote software version conker_1.1.15-49a70a8 app-130 debug1: no match: conker_1.1.15-49a70a8 app-130 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client arcfour128 hmac-sha1 none debug1: kex: client->server arcfour128 hmac-sha1 none debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Host 'bitbucket.org' is known and matches the RSA host key. debug1: Found key in /home/mrbig/.ssh/known_hosts:276 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 debug1: Next authentication method: publickey debug1: Offering public key: Private Key Connection closed by 2406:da00:ff00::6b17:d1f5
Please not the connection closed at the end.
And this happens when I change the order of the keys:
#!bash mrbig@toodark:~ $ ssh-add -l 1024 a7:83:14:47:7b:a1:ae:45:6b:c9:be:01:5c:74:7d:20 Private Key (RSA1) 2048 9c:53:e4:1b:07:9d:b6:50:cc:4a:09:a4:41:f5:93:5a .ssh/id_rsa_bitbucket (RSA) 1024 c6:f4:4b:b9:64:59:00:1a:fd:3c:ea:0a:fe:dd:4f:0a Private Key (RSA) mrbig@toodark:~ $ ssh -v -T git@bitbucket.org OpenSSH_5.1p1 Debian-6, OpenSSL 0.9.8m 25 Feb 2010 debug1: Reading configuration data /home/mrbig/.ssh/config debug1: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to bitbucket.org [2406:da00:ff00::6b17:d1f5] port 22. debug1: Connection established. debug1: identity file /home/mrbig/.ssh/identity type -1 debug1: identity file /home/mrbig/.ssh/id_rsa type -1 debug1: identity file /home/mrbig/.ssh/id_dsa type 2 debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 debug1: Remote protocol version 2.0, remote software version conker_1.1.15-49a70a8 app-126 debug1: no match: conker_1.1.15-49a70a8 app-126 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client arcfour128 hmac-sha1 none debug1: kex: client->server arcfour128 hmac-sha1 none debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Host 'bitbucket.org' is known and matches the RSA host key. debug1: Found key in /home/mrbig/.ssh/known_hosts:276 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 debug1: Next authentication method: publickey debug1: Offering public key: .ssh/id_rsa_bitbucket debug1: Server accepts key: pkalg ssh-rsa blen 277 debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Requesting X11 forwarding with authentication spoofing. debug1: Requesting authentication agent forwarding. debug1: Sending environment. debug1: Sending env LC_CTYPE = hu_HU.UTF-8 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 logged in as mr_big. You can use git or hg to connect to Bitbucket. Shell access is disabled. debug1: channel 0: free: client-session, nchannels 1 Transferred: sent 2400, received 2080 bytes, in 0.2 seconds Bytes per second: sent 10781.1, received 9343.7 debug1: Exit status 0
And this is what happens when I offer a not registered 2048bit rsa key first:
#!bash mrbig@toodark:~ $ ssh-add -l 2048 78:7b:96:e9:e3:be:71:48:dc:3b:b8:fe:27:80:b6:d4 .ssh/id_rsa_unkown (RSA) 2048 9c:53:e4:1b:07:9d:b6:50:cc:4a:09:a4:41:f5:93:5a .ssh/id_rsa_bitbucket (RSA) mrbig@toodark:~ $ ssh -v -T git@bitbucket.org OpenSSH_5.1p1 Debian-6, OpenSSL 0.9.8m 25 Feb 2010 debug1: Reading configuration data /home/mrbig/.ssh/config debug1: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to bitbucket.org [2406:da00:ff00::22c0:3470] port 22. debug1: Connection established. debug1: identity file /home/mrbig/.ssh/identity type -1 debug1: identity file /home/mrbig/.ssh/id_rsa type -1 debug1: identity file /home/mrbig/.ssh/id_dsa type 2 debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 debug1: Remote protocol version 2.0, remote software version conker_1.1.15-49a70a8 app-154 debug1: no match: conker_1.1.15-49a70a8 app-154 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client arcfour128 hmac-sha1 none debug1: kex: client->server arcfour128 hmac-sha1 none debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Host 'bitbucket.org' is known and matches the RSA host key. debug1: Found key in /home/mrbig/.ssh/known_hosts:276 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 debug1: Next authentication method: publickey debug1: Offering public key: .ssh/id_rsa_unkown debug1: Authentications that can continue: publickey debug1: Offering public key: .ssh/id_rsa_bitbucket debug1: Server accepts key: pkalg ssh-rsa blen 277 debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Requesting X11 forwarding with authentication spoofing. debug1: Requesting authentication agent forwarding. debug1: Sending environment. debug1: Sending env LC_CTYPE = hu_HU.UTF-8 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 logged in as mr_big. You can use git or hg to connect to Bitbucket. Shell access is disabled. debug1: channel 0: free: client-session, nchannels 1 Transferred: sent 2744, received 2112 bytes, in 0.2 seconds Bytes per second: sent 12529.5, received 9643.7 debug1: Exit status 0
As you can see in this case the unregistered key is simply rejectet but the connection is not closed by the server.
#Expected behavior
The server should reject the unsupported rsa key as if it would not been known. This would allow the authentication process to continue with the next key.