Why does SSH have unsecure defaults?

Question

Why does SSH come with such an unsecure default configuration?

to name what I consider unsecure defaults:

• root login enabled on SSH
• SSH protocol version 1 (which is vulnerable to MIM attacks) allowed

There also is no built in mechanism to handle brute forceattacks

I can understand that interoperability and compatibility are important for a new system, but putting a server on the web with these defaults is a major security concern. If someone didn't know about these configuration options, they could put a server live that is very vulnerable to being bruteforced and be ignorant of the problem long enough for someone to gain access.

The idea of bruteforcing root on SSH has been around a long time, and there is an ever-present 'background noise' of root login attempts on any server from bots and the like. It would make sense to ship SSH with some defaults that would help mitigate this threat.

What is the reason for these unsecure defaults?

Answer 1

In many systems, your only entry point into the system is via ssh. On a brand new install without having created a user account yet, the only account you may have is root.
Then even if you have multiple accounts, what if you are using external authentication, and your authentication system fails. You need to be able to get back in the box and fix it.

You could set PermitRootLogin to without-password so that only ssh keys will work, but to do this you have to log in at least once with a password to add the ssh key.

Aside from why it might be needed initially, I would argue that it's the package maintainer's duty to make the defaults reasonably secure, but still functional. Making it secure as possible would be things like disabling root, making it listen on a port other than 22, disabling password authentication, etc. Leaving root ssh with password enabled isn't a security hole by itself. It's only a security hole if root has a weak password.
I would liken this to a firewall policy. Most distributions ship without any iptables rules enabled, or sysctl customization. Putting a server on the internet without customization of either is a significant risk. It is up to the server owner to implement a security policy that suits the purpose of the server.

Answer 2

Your distribution is the most likely cause for these insecure default values. Different distributions ship different default configurations.

On the other hand it might be a bad idea to start a network service without prior configuration. Admins tend to have their special needs and at least take a look at the configuration after installation if not shipping their own scripts.

Brute force attacks: There are other means of detecting such attacks. Such as ipsets and firewalls or even intrusion detection systems. No need for ssh to invent its own solution.

Answer 3

SSH does not have insecure defaults (at least not the ones you mention).

Protocol 1 has been disabled by default since OpenBSD 4.7 (released in 2010). Even when Protocol 1 was still enabled by default, it would only have been used if the client requested it, and the client (like I think all clients that support protocol version 2) uses protocol version 2 unless the server doesn't support it or the user explicitly requested version 1 (and since OpenBSD 4.7, the OpenSSH client doesn't fall back to protocol version 1 explicitly).

Allowing root login from SSH is not a security concern. If it allows an attack path, it means the server administrator has done a bad job. Don't pick a guessable root password! Disabling root logins is hardening — it's security in depth. It increases security by adding a layer of protection in case the user makes a mistake. It's a good thing, but it is not required.

If you don't choose stupidly guessable passwords, then the only threat that the incessant login attempts¹ pose is to fill your log partition.

Throttling the rate of login attempts is a double-edged sword. On the one hand, it reduces the risk that attackers will guess a too-simple password, and reduces the bandwidth that they consume. On the other hand, if you happen to need to log in to your server from the same network neighborhood as an attacker and you've put in stringent limits, you'll have DoS'ed yourself.

¹ _{Not just root login attempts, by the way. Also common first names, and common system account names such as admin, webmaster, etc.}