Using dropbear vs openssh

I have been fighting to bring up bluetooth audio using yocto and I was trying few options pulseaudio and pipewire are one’s I was finally getting to work and I was stuck in starting pipewire systemd services in usermode and it would always complain about not being able to connect to bus and then I tried to use root user and media-session wont start since pipewire does not set it up as root user. I accidentally bumped into this post

which saved my day. I replaced dropbear with openssh for ssh daemon and I was able to start the services properly using remote ssh connection and finally play the audio from a rk3388 board to my bluetooth headset.

It seems dropbear does not have full support for PAM and that was the key. We should be careful of chosing base components. Always understand the end usecase thoroughly before making decisions on which components to use to build your embedded linux stack.

1 Like

Good story – the solutions to problems are not always obvious!

As flash disk space becomes cheaper and cheaper, I wonder if makes sense to continue using components like dropbear. The conservative nature in me still likes the idea of a 30MB embedded Linux image. However, for modern connected devices, security and functionality may be a bigger concern.

Dropbear also doesn’t support using hardware accelerators, OpenSSH does. On slower ARM SoCs this is very noticeable. For example on a Microchip SAMA5 board I work with, SCP file transfers can only attain about 1.5MB/s transfer rate using dropbear as it’s CPU-bound while the encryption hardware sits idle.


That is very interesting – I’ve often wondered why scp’ing stuff to my target boards was so slow …