| Message ID | 20200702095124.23862-1-ynezz@true.cz |
|---|---|
| State | Accepted |
| Delegated to: | Petr Štetiar |
| Headers | show |
| Series | dropbear: make rsa-sha2-256 pubkeys usable again | expand |
Matt Johnston <matt@ucc.asn.au> [2020-07-16 21:24:43]: Hi, > I can't reproduce a problem authenticating to a Dropbear 2020.80 server with > rsa keys. I've tried with either dbclient 2019.78 (using ssh-rsa sha1 > signatures) or dbclient 2020.80 (rsa-sha2-256 signatures). Could you give me > some steps to reproduce it? just use any other SSH client which is implemented according to rfc8332, like OpenSSH as those would likely send the public keys with 'ssh-rsa' string: Since RSA keys are not dependent on the choice of hash function, the new public key algorithms reuse the "ssh-rsa" public key format as defined in [RFC4253]: string "ssh-rsa" mpint e mpint n All aspects of the "ssh-rsa" format are kept, including the encoded string "ssh-rsa". This allows existing RSA keys to be used with the new public key algorithms, without requiring re-encoding or affecting already trusted key fingerprints. In other words, OpenSSH client sends the key with `ssh-rsa` string, but Dropbear checks for `rsa-sha2-256` and thus refusing the client. Server: $ dropbear -V Dropbear v2020.80 $ dropbear -F -s -v TRACE (2907) 2.994471: buf_put_sign type 101 rsa-sha2-256 TRACE (2907) 3.008211: enter send_msg_ext_info TRACE (2907) 3.008608: algolist add 20 'rsa-sha2-256,ssh-rsa���@E�W7��'�_��U��q}�+*L#� +R�g���d����$p��vqp��� ��,@��n):�TfIÂj��_' ... TRACE (2907) 3.999860: checkpubkey: opened authorized_keys OK TRACE (2907) 4.001785: checkpubkey_line: line pos = 8 len = 724 TRACE (2907) 4.003487: checkpubkey: base64_decode success TRACE (2907) 4.004858: leave checkpubkey: ret=0 TRACE (2907) 4.006211: enter buf_get_rsa_pub_key TRACE (2907) 4.007392: leave buf_get_rsa_pub_key: success TRACE (2907) 4.008283: enter buf_verify [2907] Jul 17 08:30:56 Exit before auth from <192.168.200.1:49142>: (user 'root', 0 fails): Non-matching signing type ^--- here it fails in buf_verify as expected sigtype=DROPBEAR_SIGNATURE_RSA_SHA256, but actual sigtype is DROPBEAR_SIGNATURE_RSA_SHA1 TRACE (2907) 4.010526: enter session_cleanup Client: $ ssh -v root@192.168.200.77 OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 ... debug1: kex: host key algorithm: rsa-sha2-256 ... debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,ssh-rsa> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:ZLONs7adjPBljemwKAX5dXDiKPDVh4fsStkqi2eJsiI cardno:000610530066 debug1: Server accepts key: pkalg rsa-sha2-256 blen 535 Connection closed by 192.168.200.77 port 22 -- ynezz
Hi Petr, I still can't reproduce this with OpenSSH_7.6p1 Ubuntu-4ubuntu0.3. Are you using a rsa key on disk, or using a SSH agent? I wonder if the agent doesn't support rsa-sha2-256 signatures or something? Dropbear is meant to be handling the difference between the key names and signature names - it's possible there are bugs, but I can't reproduce it yet. Thanks, Matt > On Fri 17/7/2020, at 4:38 pm, Petr Štetiar <ynezz@true.cz> wrote: > > Matt Johnston <matt@ucc.asn.au> [2020-07-16 21:24:43]: > > Hi, > >> I can't reproduce a problem authenticating to a Dropbear 2020.80 server with >> rsa keys. I've tried with either dbclient 2019.78 (using ssh-rsa sha1 >> signatures) or dbclient 2020.80 (rsa-sha2-256 signatures). Could you give me >> some steps to reproduce it? > > just use any other SSH client which is implemented according to rfc8332, like > OpenSSH as those would likely send the public keys with 'ssh-rsa' string: > > Since RSA keys are not dependent on the choice of hash function, the > new public key algorithms reuse the "ssh-rsa" public key format as > defined in [RFC4253]: > > string "ssh-rsa" > mpint e > mpint n > > All aspects of the "ssh-rsa" format are kept, including the encoded > string "ssh-rsa". This allows existing RSA keys to be used with the > new public key algorithms, without requiring re-encoding or affecting > already trusted key fingerprints. > > In other words, OpenSSH client sends the key with `ssh-rsa` string, but > Dropbear checks for `rsa-sha2-256` and thus refusing the client. > > Server: > > $ dropbear -V > Dropbear v2020.80 > > $ dropbear -F -s -v > TRACE (2907) 2.994471: buf_put_sign type 101 rsa-sha2-256 > TRACE (2907) 3.008211: enter send_msg_ext_info > TRACE (2907) 3.008608: algolist add 20 'rsa-sha2-256,ssh-rsa���@E�W7��'�_��U��q}�+*L#� > +R�g���d����$p��vqp��� > ��,@��n):�TfIÂj��_' > ... > > TRACE (2907) 3.999860: checkpubkey: opened authorized_keys OK > TRACE (2907) 4.001785: checkpubkey_line: line pos = 8 len = 724 > TRACE (2907) 4.003487: checkpubkey: base64_decode success > TRACE (2907) 4.004858: leave checkpubkey: ret=0 > TRACE (2907) 4.006211: enter buf_get_rsa_pub_key > TRACE (2907) 4.007392: leave buf_get_rsa_pub_key: success > TRACE (2907) 4.008283: enter buf_verify > [2907] Jul 17 08:30:56 Exit before auth from <192.168.200.1:49142>: (user 'root', 0 fails): Non-matching signing type > > ^--- here it fails in buf_verify as expected > sigtype=DROPBEAR_SIGNATURE_RSA_SHA256, but actual sigtype is DROPBEAR_SIGNATURE_RSA_SHA1 > > TRACE (2907) 4.010526: enter session_cleanup > > Client: > > $ ssh -v root@192.168.200.77 > OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 > ... > debug1: kex: host key algorithm: rsa-sha2-256 > ... > debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,ssh-rsa> > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug1: Authentications that can continue: publickey > debug1: Next authentication method: publickey > debug1: Offering public key: RSA SHA256:ZLONs7adjPBljemwKAX5dXDiKPDVh4fsStkqi2eJsiI cardno:000610530066 > debug1: Server accepts key: pkalg rsa-sha2-256 blen 535 > Connection closed by 192.168.200.77 port 22 > > -- ynezz
Matt Johnston <matt@ucc.asn.au> [2020-07-17 19:54:51]: Hi, > Are you using a rsa key on disk, or using a SSH agent? I wonder if the agent > doesn't support rsa-sha2-256 signatures or something? I'm using Yubikeys as my key storage, so it's gpg-agent (GnuPG) 2.2.4 with libgcrypt 1.8.1 running on Ubuntu 18.04. Disabling the agent and using the key from disk makes it working again. It was working fine with 2019.78. -- ynezz
Matt Johnston <matt@ucc.asn.au> [2020-07-19 11:32:56]: Hi, > It looks like gpg-agent added support in 2.2.5. OpenSSH client 7.7 or later will print a warning about it. > https://dev.gnupg.org/T3880 Debian 9 (EOL in June 30, 2022) has following: gpg-agent (GnuPG) 2.1.18, OpenSSH_7.4p1 Ubuntu 18.04 (EOL in April, 2023) has following: gpg-agent (GnuPG) 2.2.4, OpenSSH_7.6p1 > I don't think there's anything to change server side - the client is sending > the wrong signature type. BTW latest OpenSSH server version 8.3 works fine with those broken clients, so perhaps there is no such strict checking in place or such? > Old Dropbear worked OK because it didn't advertise rsa-sha2-256 support, so > the client didn't try it. As you can see, there are some users with broken clients which are unable to use Dropbear version > 2019.78. Dropbear is shipped by default in OpenWrt and it's likely, that the next OpenWrt relase will ship with Dropbear version >= 2020.80 and users with those broken clients wouldn't be able to SSH into their devices after the upgrade. Nonethless I've closed the PR and we'll just keep this workaround for those broken clients in our tree. -- ynezz
diff --git a/package/network/services/dropbear/patches/910-signkey-fix-use-of-rsa-sha2-256-pubkeys.patch b/package/network/services/dropbear/patches/910-signkey-fix-use-of-rsa-sha2-256-pubkeys.patch new file mode 100644 index 000000000000..afa0ebb310c9 --- /dev/null +++ b/package/network/services/dropbear/patches/910-signkey-fix-use-of-rsa-sha2-256-pubkeys.patch @@ -0,0 +1,40 @@ +From 667d9b75df86ec9ee1205f9101beb8dbbe4a00ae Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Petr=20=C5=A0tetiar?= <ynezz@true.cz> +Date: Wed, 1 Jul 2020 11:38:33 +0200 +Subject: [PATCH] signkey: fix use of rsa-sha2-256 pubkeys +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +Commit 972d723484d8 ("split signkey_type and signature_type for RSA sha1 +vs sha256") has added strict checking of pubkey algorithms which made +keys with SHA-256 hashing algorithm unusable as they still reuse the +`ssh-rsa` public key format. So fix this by disabling the check for +rsa-sha2-256 pubkeys. + +Ref: https://tools.ietf.org/html/rfc8332#section-3 +Fixes: 972d723484d8 ("split signkey_type and signature_type for RSA sha1 vs sha256") +Signed-off-by: Petr Štetiar <ynezz@true.cz> +--- + signkey.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +diff --git a/signkey.c b/signkey.c +index 92fe6a242cd0..d16ab174d83a 100644 +--- a/signkey.c ++++ b/signkey.c +@@ -657,8 +657,12 @@ int buf_verify(buffer * buf, sign_key *key, enum signature_type expect_sigtype, + sigtype = signature_type_from_name(type_name, type_name_len); + m_free(type_name); + +- if (expect_sigtype != sigtype) { +- dropbear_exit("Non-matching signing type"); ++ if (sigtype == DROPBEAR_SIGNATURE_NONE) { ++ dropbear_exit("No signature type"); ++ } ++ ++ if ((expect_sigtype != DROPBEAR_SIGNATURE_RSA_SHA256) && (expect_sigtype != sigtype)) { ++ dropbear_exit("Non-matching signing type"); + } + + keytype = signkey_type_from_signature(sigtype);
Upstream in commit 972d723484d8 ("split signkey_type and signature_type for RSA sha1 vs sha256") has added strict checking of pubkey algorithms which made keys with SHA-256 hashing algorithm unusable as they still reuse the `ssh-rsa` public key format. So fix this by disabling the check for `rsa-sha2-256` pubkeys. Ref: https://tools.ietf.org/html/rfc8332#section-3 Cc: Matt Johnston <matt@ucc.asn.au> Fixes: d4c80f5b172e ("dropbear: bump to 2020.80") Signed-off-by: Petr Štetiar <ynezz@true.cz> --- I'm unable to connect with the latest Dropbear with my rsa-sha2-256: debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,ssh-rsa> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:ZLONs7adjPBljemwKAX5dXDiKPDVh4fsStkqi2eJsiI cardno:000610530066 debug1: Server accepts key: pkalg rsa-sha2-256 blen 535 Connection closed by 192.168.1.1 port 22 Upstreamed in https://github.com/mkj/dropbear/pull/106 ...nkey-fix-use-of-rsa-sha2-256-pubkeys.patch | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 package/network/services/dropbear/patches/910-signkey-fix-use-of-rsa-sha2-256-pubkeys.patch