SSH - run both Dropbear and OpenSSH

Tutorials on replacing Dropbear with OpenSSH would have you disable and stop Dropbear once you have OpenSSH up and running. An example would be:

https://oldwiki.archive.openwrt.org/inbox/replacingdropbearbyopensshserver

Question: Would it be "machine-wise" okay to have both Dropbear and OpenSSH running, listening on different ports?

"Machine-wise" means basically whether the two SSH apps would run into conflict. (I don't quite know how to generalize from that.)

I'm setting aside administration or security issues (more work, less secure). Thanks.

A BIT MORE CONTEXT

My plan is to make custom images with both SSH apps running but, on flashing, disable and stop Dropbear by hand. Password authentication is to be allowed for Dropbear, but not OpenSSH (which is to be key authentication only).

This way, if anything happens to the router and I have to factory-reset it, it would come back to life in a form that is accessible to SSH with a password. If in the mean time OpenSSH client key authorized by the router has disappeared, I can get the router to accept a new key (after SSH-ing into Dropbear with a password).

I even considered so creating the image that, on flashing, the router will have no password and allow free access. But that would mean I really must remember to close things down right away.

Yes, an alternative would be to let OpenSSH start life (on flashing) with password authentication allowed. But my plan is that OpenSSH will be open to WAN, but Dropbear only to LAN.

Oh yes, I know that Wireguard is better, and I will get there eventually.

Anyway, my purpose in this post is not have this overall plan sanctioned, but to have the technical question answered.

Dropbear is secure enough, integrates with UCI, and supports Ed25519.
There's no benefit to run Dropbear and OpenSSH at the same time.
It's better to configure properly than increase potential attack surface.

Set up key-based authentication and disable password authentication.
You can also create a non-privileged user and prohibit root login.
Note that WireGuard is not a replacement, but an extra security layer.

2 Likes

You can do it, I am doing the same myself running both Dropbear and OpenSSH. Not for security reasons, more like to have an alternative way in, in case the default ssh server is dead.

2 Likes

Thanks for all the extra info. My main motivation is to have the same setup across all machines as I tend to make all available mistakes and if Dropbear is around I will make Dropbear mistakes as well as OpenSSH mistakes. (I won't be running both except as a result of, and just after, a re-flash.) I found this on using SFTP with Dropbear (as supplemented by the SFTP element of OpenSSH) for any other novice landing here.

1 Like

Note that SFTP doesn't actually require OpenSSH server.
It can as well work with Dropbear like this:
https://openwrt.org/docs/guide-user/services/nas/sftp.server

2 Likes

Ah ha! This is just what happened to me today (and what I expected would happen to someone that makes every available mistake).

After compiling a new custom image and flashing the router with it, I found myself locked out of the router insofar as its OpenSSH server was concerned.

I promptly logged in through Dropbear and saw that the permissions for /root and /root/.ssh were wrong. When I used chmod to fix them to expected values, voila OpenSSH let me in!

Now so long as I have LuCI access and can re-flash with another (corrected) image, I am not truly locked out. But imagine how much more trouble to find out what needs correcting. Without Dropbear, every hypothesis would meant an image embodying it. (E.g. for every chmod, compile, flash, and oh let's see.)

What nightmare that would have been!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.