F22 System Wide Change: Set sshd(8) PermitRootLogin=no

[Paul Wouters]

On Mon, 12 Jan 2015, P J P wrote:

>  Agreed Paul, yet it does not mean cracking them would be as easy as slicing knife through butter. That too for every awkward joe trying their hands at it. It sounds like all one has to do is just guess the username, and it's game over.

Exactly! Then we are back at the level of "need to brutce force a
password" just like in the root case.

> There is user's password, and root account's password. Not every non-root user has sudo(1) access.  Besides when they use browser based mail clients, such information is less likely to be disclosed.

For most compromises, root is not needed. Most hacking attempts are
attempts for resources (cpu, bandwidth) not anything requiring root.

> As said before, few might be able to crack it, but others would _fail_ at it. And that failure is our net gain.

I understand the net gain (a factor of about 1000 for commonly used
usernames) in a botnet attack. In other words, a tiny tiny net gain.

Anyway. I'm not against blocking password root. I'm against blocking
root with ssh keys. Which has nothing to do with bruce forcing,
other than being collateral damage with PermitRootLogin=no.

> Secondly, this restriction would encourage people to use non-root user accounts and help spread awareness about having strong passwords.

What if I told you Neo, that there are no strong passwords?
Passwords are weak. Some are less weak than others. I'd rather
teach people to use ssh keys for remote access and only restrict
passwords to console/physical access. That would be a good
security lesson to teach.

> Thirdly, as said in another thread, if we resort to using keys based authentication for 'root' account, it would lead to people using same mechanism for other accounts too.

Excellent! even less password guessing possible!

> Overall in the long term, today's small change will have better cumulative returns.

And again, ignoring the collateral damage. As people suggested, keep ssh
key based root logins allowed.

>> Compared to the dictionary this does in fact not make the problem any harder at
>> all. However, you have made legitimate automated root logins much harder
>> now, like me calling rsync as root for backups, which are not easilly
>> done wrapped in sudo :P
>
>  I wonder why rsync needs root account?

Because it is making a backup of files, some of which are only readable
by root?

> If it's not easily done wrapped in sudo, why is brute forcing unknown username, its password and then root account relatively easier? (rhetorical questions, don't answer)

That's okay, I answered it twice already in this email :P

> Point is, if one must have to have only 'root' account in their set-up, they can always enable remote 'root' login by setting PermitRootLogin=yes. Just like how people flush firewall rules. There are various ways of doing that.

1) you want to disable password logins for root
2) you paint the bikeshed green
3) people tell you they can't get into the bikeshead
4) you say, but it's safer green!


> Let's try to figure out how we could facilitate that with more convenience, rather than looping over same arguments about how the feature improves security or not.

You can accomplish disabling password based remote root logins by
disabling password based remote root logins:

 	PermitRootLogin without-password

This matches exactly what the feature is supposed to protect against -
bruce forced password attacks against root. I have not heard anyone
in this thread yet saying this is unacceptable, except for your vague
claim of 'it would lead to people using same mechanism for other
accounts too' (which I interpret as good, not bad)

>> For malicious logins, once root access is obtained via password-less sudo,
>> the evidence is removed from the logs.
>
>  What..automatically? Or the assumption is that the attacker is the smartest soul on earth??

It's not my argument. You brought in the "sudo is superior over ssh
authenticated key logins for auditing reasons" argument. It's not mine.

Paul