4 ms·

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 attacke

by cedws 2y ago

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.

idunnoman1222 2y ago
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?
- cedws 2y ago
  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.
  - joshuaissac 2y ago
    In practice, this will just result in people and organisations using the last version of OpenSSH that supports password authentication.
- PhilipRoman 2y ago
  Last time I checked "apt install openssh-server" on debian still launched sshd with password login enabled
tedunangst 2y ago
That's a pretty weird summary of openbsd development.
dd_xplore 2y ago
OpenSSH is used in variety of platforms, enforcing secret key will prohibit it's usage in lot of places due to the added complexity.
- wkat4242 2y ago
  Indeed. And then someone will just fork it and the situation will be messier.
SoftTalker 2y ago
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?
- cedws 2y ago
  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.
  - adamrt 2y ago
    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.
    - cedws 2y ago
      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.
      - djao 2y ago
        You seem to be confusing "OpenSSH" with "OpenSSH Portable Release". As explained here: https://www.openssh.com/portable.html 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.
karmarepellent 2y ago
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/ https://tinyssh.org/
freedomben 2y ago
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.
- PhilipRoman 2y ago
  >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.
yjftsjthsd-h 2y ago
> 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.
- arp242 2y ago
  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.
adamrt 2y ago
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.

by cedws 2y ago

idunnoman1222 2y ago

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?

cedws 2y ago
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.
- joshuaissac 2y ago
  In practice, this will just result in people and organisations using the last version of OpenSSH that supports password authentication.
PhilipRoman 2y ago
Last time I checked "apt install openssh-server" on debian still launched sshd with password login enabled

tedunangst 2y ago

That's a pretty weird summary of openbsd development.

dd_xplore 2y ago

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

wkat4242 2y ago
Indeed. And then someone will just fork it and the situation will be messier.

SoftTalker 2y ago

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?

cedws 2y ago
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.
- adamrt 2y ago
  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.
  - cedws 2y ago
    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.
    - djao 2y ago
      You seem to be confusing "OpenSSH" with "OpenSSH Portable Release". As explained here: https://www.openssh.com/portable.html 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.

karmarepellent 2y ago

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/ https://tinyssh.org/

freedomben 2y ago

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.

PhilipRoman 2y ago
>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.

yjftsjthsd-h 2y ago

> 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.

arp242 2y ago
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.

adamrt 2y ago

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.