Hello,
Does default dropbear suports ed25519 user keys? If yes, how could I enable it?
Thanks
2 Likes
I'd be interested to know if this is possible too. I've added my id_ed25519.pub to the dropbear ssh key dialog (under Administration > SSH-Keys) but it doesn't seem to work even though I have the key loaded by keychain on the client I'm trying to SSH into the router from (I've restarted dropbear with /etc/init.d/dropbear restart).
No, it's not possible. dropbear itself doesn't support ed25519 keys. I think long term plan is to support them but I guess it wasn't a priority. You might want to talk to dropbear developer, maybe priority would increase if there is interest in this feature. I think there are actually some unmerged patches adding ed25519 to dropbear but openwrt doesn't include them.
There seems to be a fork of dropbear that does, I'm not sure if upstream is interested in these changes or not (nor their veracity).
I found both this forum topic and the github repo while searching to see how to enable ED25519 keys for dropbear (as it's not supported at this time, I'll just be using openssh).
One more step forward 
Yeah, awesome!
Also looking for that and dropbear even in OpenWRT 19.07 does not seem to support that.
Also the wiki states:
It does not appear that dropbear supports ssh-ed25519 keys.
And people on reddit discuss it.
However, there is a good sign. Support seems to have been merged in OpenWRT In April this year: 
2 Likes
It works, at least on the master branch:
cat << EOF >> openwrt/.config
CONFIG_DROPBEAR_ED25519=y
EOF
The problem seems to be, it's not enabled by default.
On the mailing list, it says that need to be enabled:
https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg54127.html
And I've found this bug for enabling it:
https://bugs.openwrt.org/index.php?do=details&task_id=3216&string=dropbear
1 Like
It doesn't look like ed25519 is enabled in 19.07.4.
That is correct. New features usually don't end up in already branched releases, only bug fixes. You'll have to wait for a 20.xx release for that
4 Likes
Could the decision possibly be reconsidered? Fedora 33 doesn't support RSA any more by default, see https://dev.to/bowmanjd/upgrade-ssh-client-keys-and-remote-servers-after-fedora-33-s-new-crypto-policy-47ag - meaning there is no more common SSH algorithm (I tried ecdsa and ed25519).
1 Like
It is already enabled by default in the master branch since September this year: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=d0f295837a03f7f52000ae6d395827bdde7996a4
Either use a snapshot image, or wait for the 20.xy release. I wouldn't expect this to be backported to 19.07, since release branches usually don't get new features.
3 Likes
I had understood your answer that such new features usually aren't back ported, and my question was if this decision could be re-considered, because currently SSH keys are practically non functional, so this could be considered a bug and not a feature 
SSH keys aren't even mandatory, since dropbear will accept password based logins just fine. No matter how you are going to word it, adding support for a new type of key is a new feature, especially since it's Fedora that is breaking the compatibility, not OpenWRT. Having said that, I am already using ed25519 on a 19.07 based installation by installing openssh server on the router. I simply moved dropbear to a different port, and made openssh listen on port 22 for easy access with ed25519 keys.
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.