The OpenBSD approach to security always seems to be adding things rather than removing them. For example, this feature is intended to make it harder for attackers to break in by guessing the password. So why not remove password authentication, or enforce a minimum password complexity? Password auth for SSH is almost always a bad idea anyway - good, secure software should nudge people towards using it securely, not give them the option to configure it with a gaping security hole.
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?
A good example of how code should be stripped down like this is WireGuard vs the old VPNs. WireGuard came along with fresh cryptography, took all of the bells, whistles, and knobs away and now provides an in-kernel VPN in a fraction of the LOC of IPsec or OpenVPN. As a result, it can be proven to be significantly more secure, and it's more performant too.
> 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.
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.
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.
> 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.
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.
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.
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?
A good example of how code should be stripped down like this is WireGuard vs the old VPNs. WireGuard came along with fresh cryptography, took all of the bells, whistles, and knobs away and now provides an in-kernel VPN in a fraction of the LOC of IPsec or OpenVPN. As a result, it can be proven to be significantly more secure, and it's more performant too.