Hacker News Reader

> It's the same with the OpenBSD operating system. There's so much extremely obscure, complex code that attempts to address the same problems we have been dealing with for 30+ years. What if we started removing code and reducing the attack surface instead of trying to patch over them, or we came up with an entirely new approach?

OpenBSD absolutely removes things: Bluetooth, Linux binary compatibility, and sudo, off the top of my head, with the sudo->doas replacement being exactly what you're asking for.

Also Apache → httpd, sendmail → (open)smtpd, ntpd → (open)ntpd. Probably some other things I'm forgetting.

I've seen a number of reasonable criticisms of OpenBSD over the years. Not being minimalist enough is certainly a novel one.

I can't think of any long term, open source project that has removed and ripped out more code than OpenBSD.

They are know for doing exactly what you are suggesting.

Go ask @tedunangst. It was literally called "tedu'd" for ripping out old crusty code.

You can (and need) to do both. And OpenBSD does. LibreSSL as one example removed a huge amount of dead/spaghetti/obsolete code from OpenSSL. And they are removing old/obsolete features all the time. Do you use OpenBSD? Do you read the release notes?

That's not really good enough though, the distros just enable the build flags that let them do naughty things. The software needs to be opinionated on how to use it securely, not leave it up to the users, because the developers that wrote it probably know best! The code simply needs to not exist. If users want to fork and maintain their own insecure branch, let them.

OpenBSD is also known for this. They constantly push back against adding configuration knobs or running non standard configurations.

Have you used OpenBSD? You're telling them they should be doing something, that is already basically their mission statement.

Looking at OpenSSH tells a different story. It is a massive, overly configurable behemoth. The 'WireGuard of SSH' would be 1% of the LOC. It would not provide password auth, or let you log in as root with password auth, or let you use old insecure ciphers.

Maybe OpenBSD itself is better at sticking to these principles than OpenSSH. I haven't used (experimented with) it for ~5 years but read about various updates every so often.

You seem to be confusing "OpenSSH" with "OpenSSH Portable Release". As explained here: https://www.openssh.com/portable.html

> Normal OpenSSH development produces a very small, secure, and easy to maintain version for the OpenBSD project. The OpenSSH Portability Team takes that pure version and adds portability code so that OpenSSH can run on many other operating systems.

Unless you actually run OpenBSD, what you think is "OpenSSH" is in fact "OpenSSH Portable Release". These are very different things.

As the parent comments note, LibreSSL ripped out tons of code. Not "hidden behind build flags". Deleted.

There's plenty of flaws with any project, but OpenBSD is pretty well known for doing exactly the thing you're claiming they don't do.

By removing password auth from openssh, you're not reducing the complexity, you're just moving it somewhere else. I would argue that you're actually adding significantly more complexity because now users/admins can't just bootstrap by using a default or generated root password on a new machine, creating a user, copying over the public key, and then disabling password auth. Now you have to figure out how to get that key into the image, an image you may or may not control. God help you if you don't have physical access to the machine.

Edit: I realized after posting that I was equivocating on "complexity" a bit because you're talking about code complexity for openssh itself. I don't disagree with you that openssh itself would be less complex and more secure without password auth features, but I think it would have spillover effect that isn't a net positive when considering the whole picture.

>Now you have to figure out how to get that key into the image, an image you may or may not control

I'd say this is a good thing, initial secret distribution is an unavoidable complexity and avoiding it leads to "admin/admin" logins which get hacked within seconds of internet access. There is plenty of tooling developed for this, even when setting up a VPS or flashing a Raspberry PI you can put a public key on the device to be active on first boot.

That's a pretty weird summary of openbsd development.

OpenSSH is used in variety of platforms, enforcing secret key will prohibit it's usage in lot of places due to the added complexity.

Indeed. And then someone will just fork it and the situation will be messier.

Just for info: there are alternative SSH server implementations out there that disable features that are discouraged (e.g. password authentication)[0]

Tinyssh is just one I already knew, I suppose you would find more via a proper search.

[0] https://tinyssh.org/

If you want password auth, you already have to change a default setting in SSHD and restart it. How exactly is removing that as a option ‘less complex’ for the downstream distros?

I don't really understand your question. Removing password auth reduces code complexity and therefore attack surface whilst also preventing users from using the software with a dangerous configuration. Maybe the users don't want that, but tough shit, maybe it's the nudge they need to use SSH keys.

In practice, this will just result in people and organisations using the last version of OpenSSH that supports password authentication.

Last time I checked "apt install openssh-server" on debian still launched sshd with password login enabled