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.

2 Likes

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

So OpenSSH has steadily been dropping support for older protocols that Dropbear used in the past. If you are running a newer Linux distro with latest OpenSSH and connecting to a 5 year embedded Linux product running dropbear, you’ll likely see two problems when you try to connect:

  • complaining about ssh-rsa
  • scp no longer works

You can add the following to your ~/.ssh/config file:

Host 10.0.0.123
    PubkeyAcceptedAlgorithms +ssh-rsa
    HostkeyAlgorithms +ssh-rsa

Where 10.0.0.123 is the IP of the embedded device.

To get scp working again, use with -O option, when enables the old scp protocol instead of sftp.

Fixing security problems is great, but it comes with a cost when you have old systems deployed you still need to connect to. Of course the ideal solution would be to upgrade all the old systems, however if the SSH ports are not exposed to the internet on these systems, there is not a security concern, so it’s hard to justify doing an OS update on all these systems – especially when many of them are remote and connected via very slow Cat-M modems.

Kind of reminds me of 2FA/MFA – I’m to the point I’m more concerned about getting locked out of my accounts due to 2FA than someone cracking my strong passwords. What happens if my phone is destroyed, or someone hacks my phone number? It is nearly impossible to get accounts unlocked that are 2FA protected without going in endless circles with customer-support people. Many companies don’t even offer customer support any more except through their ticket system, which you can’t get to unless you log in (Digital Ocean, I’m talking about you …). Does it make sense to force everyone to use 2FA just because some people use weak passwords or insecure operating systems/apps?

1 Like

-O worked for me. Thanks for this detail, super useful

a fix is posted to handle it with OE now here

https://lists.openembedded.org/g/openembedded-core/message/165363

1 Like

When ever possible, use U2F for your 2FA. Enroll more than one U2F key and keep one of those keys somewhere safe at home, then carry the other one with you at all times for doing auth.

Thankfully, lots of the big tech companies are seeming to finally embrace U2F which is great news!

2 Likes

I was looking at Discover YubiKeys | Strong Two-Factor Authentication for Secure Login
which products do you recommend for a family/personal use

I have experience with Feitian U2F USB and Bluetooth dongles, Google Titan USB and Bluetooth dongles (just rebranded Feitian, really), and Yubico Yubikey dongles. I’ve not used any of the Nitrokey U2F devices, just some of their other products.

If you just want FIDO U2F support and don’t care about other fancy things that some of the dongles can do, just buy the Feitian USB key or Yubico Security Key. Each is like $20-25. Only get the Google Titan if they’re on sale or Google gives you one for free, it’s just a Feitian key with Google written on it. Be sure you get keys with NFC so you can use it with your phone (most Androids and all currently updated iPhones work fine with NFC now) but verify which apps you use to understand if they can actually use the NFC U2F interface correctly (bitwarden on iOS couldn’t, last time I checked).

If you want to do fancy smartcard things in addition to U2F, then get a Yubikey with NFC. Make sure you have at least 2 U2F dongles per person and that each has a USB connectivity method so you can enroll them each easily with a PC (much easier than using the phone to enroll most times).

If you’re going to buy some U2F dongles, also consider enrolling yourself in Google’s Advanced Protection program, which will require use of U2F dongles in order to sign into your account and give a few other protections from account takeover by unauthorized (non-Google) 3rd parties: Advanced Protection Program

Be aware, if you get locked out of your Google account and you’re enrolled in Advanced Protection, it’s a royal pain in the butt to get it fixed.

Neat, I really like the idea of USB dongles vs being locked to a phone!

came across this article Hackers can clone Google Titan 2FA keys using a side channel in NXP chips | Ars Technica
I think I will prefer ubikey

an article about yubikeys:

One last piece of advice: Buy a YubiKey

To be fair, if you’re at risk of having your U2F dongle physically compromised and you ever notice it missing, you have to assume it’s been fully compromised. Same thing for a laptop even with secure boot and full disk verification. An attacker with extended duration physical access is going to win if they have the ability and funding to do so.

This vulnerability is not enough that I would recommend anyone in my family to abandon their Titan keys. The attacker still needs to perform a physical attack, which is very hard and expensive in comparison to just using a password, so even with somewhat vulnerable U2F keys it’s still tremendously more secure than a password alone or even SMS verification.

1 Like

Right, I do agree if physical access is obtained most of bets are off.