dropbear icon indicating copy to clipboard operation
dropbear copied to clipboard

Compatibility with OpenSSH authorized_keys / sshd(8) is broken

Open Tlepel opened this issue 2 years ago • 3 comments

The option no-user-rc in the authorized_keys file breaks public key authorization when using Dropbear. The option is allowed by OpenSSH (and is stipulated in sshd(8)).

I found this out when I wanted to use gitea on my dietpi server which is running Dropbear for ssh. Gitea will create the authorized_keys file for the git user on the server, which includes all ssh-keys for connecting to the git server. Gitea will automatically include several options for public key authorization: no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict. However, those last two options break the public key authorization:

Jan 04 21:30:29 DietPi dropbear[58386]: Child connection from IP-ADDR
Jan 04 21:30:29 DietPi dropbear[58386]: Port forwarding disabled.
Jan 04 21:30:29 DietPi dropbear[58386]: Agent forwarding disabled.
Jan 04 21:30:29 DietPi dropbear[58386]: Pty allocation disabled.
Jan 04 21:30:29 DietPi dropbear[58386]: Bad public key options at /mnt/dietpi_userdata/gitea/.ssh/authorized_keys:2
Jan 04 21:30:31 DietPi dropbear[58386]: Exit before auth from <IP-ADDR>: (user 'gitea', 0 fails): Exited normally

When I removed both those options, the public key authorization worked fine, and it should be noted that Dropbear already supports restrict, so only no-user-rc is missing support.

Gitea issue where this behaviour is discussed: go-gitea/gitea/issues/21383

Tlepel avatar Jan 05 '23 11:01 Tlepel

restrict should be supported since Dropbear 2022.82, is it using an older version? I'll add no-user-rc support.

mkj avatar Jan 06 '23 01:01 mkj

Hmm, perhaps I didn't check it well enough. I removed both options just to be sure, and that fixed it, but I guess I didn't verify which of the 2 was the issue.

Thanks for the quick reply and adding the support for no-user-rc!

Tlepel avatar Jan 06 '23 08:01 Tlepel