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 <yn...@true.cz> wrote: > > Matt Johnston <m...@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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel