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?

3 Answers 3


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.

  • yes I agree with you about initial setup - you are going to need some way of getting in initially, that is fair enough. maybe it would be better to have some sort of setup process run after first root login to suggest using more secure settings - ofcourse that's something to bring up with the openssh people :)
    – jammypeach
    Apr 18, 2014 at 14:05

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.

  • True enough, there are probably plenty of security-focussed distros out there, however most of the popular ones in my experience do this (ubuntu, centos, debian). it was some time since I used debian though. I take your point about due diligence with new servers etc - the problem there is if SSH is your only access to the server (eg dedicated server from a hosting provider) then it's already running, with unsecure settings. also, not everybody will know these risks and may think they aren't taking any (!) - I learned the hard way.
    – jammypeach
    Apr 18, 2014 at 14:08

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.

  • Hi Gilles, you're right about all that - however I neglected to mention the distros I was seeing this on - they are Ubuntu, CentOS and some time ago Debian (may have changed). On CentOS certainly this was the case, I had to disable protocol 1 and the rest. Good advice to not pick a guessable password etc - and it is certainly possible to DDOS yourself however the software you get to do that (I use fail2ban) lets you whitelist an IP or list of IPs so you can always get in even if you ban yourself.
    – jammypeach
    Apr 21, 2014 at 10:16
  • Disabling root logins is a bad idea. Limit root logins to console is a good idea.
    – Joshua
    Oct 3, 2022 at 21:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .