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 forceattacksI 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? 
Why does SSH have unsecure defaults?
ssh;security
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.