Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple SSH Security

disknotifier.com

Post reply on HN
Print view View original

11–20 of 97 posts

Re: Simple SSH Security

#11

Post by qw3rty01 »

jimmygrapes wrote: post #6
teddyh wrote: post #3

See also: https://bettercrypto.org/#_openssh https://www.debian.org/doc/manuals/securing-debian-manual/se...

I have been asking this of colleagues informally for decades now, but I will do it again: why is it that, if the majority of best practices for security are identical (ie "disable these settings asap"), are the default settings the way they are? And what would it take to change them to be secure by default?

the problem is a lot of the "disable asap" steps require a step before that so the machine is still accessible afterwards (such as adding a non-root user before disabling root login, adding an authorized key before disabling password login, etc)

Re: Simple SSH Security

#13

Post by kiryin »

I belong to the camp that believes in using the defaults when it comes to ciphers. I am not an expert in cryptography, nor do I like copypasting stuff I don't fully understand. The openssh guys know this stuff better than I do and I think that's fine.

Re: Simple SSH Security

#15

Post by haarts »

kiryin wrote: post #13

I belong to the camp that believes in using the defaults when it comes to ciphers. I am not an expert in cryptography, nor do I like copypasting stuff I don't fully understand. The openssh guys know this stuff better than I do and I think that's fine.

I was long of that conviction too. But the default install optimizes for a different thing, compatibility. Or at least emphasizes is more than I would do.

For example I never use RSA keys. So these can go. Less cyphers => less attack surface.

But I do agree that I'm sure the defaults picked are sensible.

Re: Simple SSH Security

#16

Post by teddyh »

jimmygrapes wrote: post #6
teddyh wrote: post #3

See also: https://bettercrypto.org/#_openssh https://www.debian.org/doc/manuals/securing-debian-manual/se...

I have been asking this of colleagues informally for decades now, but I will do it again: why is it that, if the majority of best practices for security are identical (ie "disable these settings asap"), are the default settings the way they are? And what would it take to change them to be secure by default?

The software authors can’t change the default settings, since many users have config files where a setting isn’t specified, and these users would, when they upgrade, get an unasked-for change, which might break their workflow. The software authors can change the defaults in major version releases, but even that is frowned upon by those who would be affected by the change. Therefore, this usually does not happen until a real security issue is caused by the old state of things.

The downstream package maintainers for various operating systems or distributions have some more leeway in changing the defaults, but here, also, they have to bow to the impact which a change might have on real-world users. Indeed, since these package maintainers are closer to the actual affected end users, it has been known to happen that upstream authors have changed a default value to be more secure, but the real-world impact has been so large that the package maintainers have reverted this change in the packaged versions of the software, essentially making the software more insecure in the name of compatibility. So, package maintainers are more flexible, but are also more beholden to the wishes of users who might be adversely affected by any changes.

Re: Simple SSH Security

#17

Post by slaymaker1907 »

lousken wrote: post #10
jimmygrapes wrote: post #6

Earlier quoted context omitted.

I have been asking this of colleagues informally for decades now, but I will do it again: why is it that, if the majority of best practices for security are identical (ie "disable these settings asap"), are the default settings the way they are? And what would it take to change them to be secure by default?

Which ones aren't secure by default? When you install new OS like Debian those defaults will be correctly set (and depending on your organization, you may change some settings around to fit your needs). However, if you customized your config e.g. in debian 6 and updated to 11, you may wanna revisit those settings and change them

Not really SSH, but Kerberos on many distros allows extremely weak ciphers by default. And when I say weak, I mean these should have been disabled a decade ago. On Ubuntu 20.04 with the default setup, keytabs using DES are allowed...

Re: Simple SSH Security

#18

Post by haarts »

jimmygrapes wrote: post #6
teddyh wrote: post #3

See also: https://bettercrypto.org/#_openssh https://www.debian.org/doc/manuals/securing-debian-manual/se...

I have been asking this of colleagues informally for decades now, but I will do it again: why is it that, if the majority of best practices for security are identical (ie "disable these settings asap"), are the default settings the way they are? And what would it take to change them to be secure by default?

I don't think the defaults are bad. I think the defaults are generic. And I don't have a generic machine. Nobody has. Old SSH clients don't need access to my server. So I think it is a good idea to remove old cyphers.

Staying ahead of the pack.

Re: Simple SSH Security

#19

Post by haarts »

yjftsjthsd-h wrote: post #9
tialaramex wrote: post #7

Earlier quoted context omitted.

The algorithms used will be negotiated. So, unless your SSH client is unwilling to use any of the acceptable algorithms it just will work. For the server's proof of its identity, one gap in older SSH versions is that the client doesn't learn other host keys. So if your client is content with Archaic-host-key, even though the server has been telling anybody new about Shiny-modern-host-key, when the server finally remo…

You could also deal with updating host keys by signing them and just having clients trust the signing authority.

I liked this article about it: https://smallstep.com/blog/use-ssh-certificates/

Re: Simple SSH Security

#20

Post by tialaramex »

jimmygrapes wrote: post #6
teddyh wrote: post #3

See also: https://bettercrypto.org/#_openssh https://www.debian.org/doc/manuals/securing-debian-manual/se...

I have been asking this of colleagues informally for decades now, but I will do it again: why is it that, if the majority of best practices for security are identical (ie "disable these settings asap"), are the default settings the way they are? And what would it take to change them to be secure by default?

The defaults assume your appetite for security risk is much greater than your appetite for interop failure.

Imagine two products that could easily exist, almost the same features:

A by default works just fine, but there's a risk an adversary spends $10M to attack you. You can tweak the config and replace all the OmniCorp CheapDevices in your estate to get rid of that attack which is best practice.

B by default requires that you replace all the OmniCorp CheapDevices in your estate or it won't work. You can tweak the config and risk that an adversary spends $10M to attack you so that the OmniCorp CheapDevices still work.

Which one do you buy? You buy A of course. Nobody is going to sign off on the budget to replace all the OmniCorp CheapDevices. What's this nonsense about a $10M attack anyway?

At some point the risk is judged to be too high, and people flip the defaults for those risks. For example OpenSSH decided the risk for SHA1 authentication is now too high, like the Web PKI had years before, but despite SSH being a much less plausible target than the Web PKI for various reasons.

Post reply on HN