"PermitRootLogin no" should not proceed with root login

[tot-to]

Steps to reproduce:
1) PermitRootLogin no in sshd_config
2) login with "root" user from other host

Present behaviour:
1) it asks for password 3 times and only then close the connection.
2) cpu consumption during bruteforce "attacks".

Expected behaviour:
Immediate disconnect/login fail

Workaround is to change ssh port, or ban IP after some login fails, or
limit IP that can connect to this port or number of connections per IP
per unit of time using firewall. All of them have disadvantages.

I use patched version 6.7_p1-r3 from Gentoo portage. But I guess it's
unlikely that this behaviour is affected by patches.

[Damien Miller]

Post by tot-to
1) PermitRootLogin no in sshd_config
2) login with "root" user from other host
1) it asks for password 3 times and only then close the connection.
2) cpu consumption during bruteforce "attacks".

This is intentional behaviour. The intention is to not give clues as
to which accounts may be valid for login.

Post by tot-to
Immediate disconnect/login fail

If you want this, then use:

Match user root
MaxAuthTries 0

[tot-to]

Hi Damien,

Thank you for the explanation and suggesting the option that does
exactly what I want.

The intention looks reasonable to me.

I aclually have a related question about the reasoning:
Why "PermitRootLogin no" is not a default option?
That would be much secure and would make such kind of bruteforce attacks
useless or at least much less effective for most of the users.

On Sun, 22 Feb 2015 08:02:11 +1100 (AEDT)

Post by Damien Miller

Post by tot-to
1) PermitRootLogin no in sshd_config
2) login with "root" user from other host
1) it asks for password 3 times and only then close the connection.
2) cpu consumption during bruteforce "attacks".

This is intentional behaviour. The intention is to not give clues as
to which accounts may be valid for login.

Post by tot-to
Immediate disconnect/login fail

Match user root
MaxAuthTries 0

[Philip Hands]

tot-to <tot-***@tot-to.com> writes:

...

Post by tot-to
Why "PermitRootLogin no" is not a default option?

"without-password" is the right default IMO, as suggested some time ago:

https://bugzilla.mindrot.org/show_bug.cgi?id=2164

(and considerably earlier in Debian circles ;-) )

I'm glad to say that the default for the Debian package has finally
switched to "without-pasword" for new installs in our upcoming release.

I'd suggest it is pretty irresponsible allowing the default to remain as
"yes" here upstream, especially given how popular brute-force attacks
are these days.

Given that nobody came up with any argument to maintain "Yes" as the
default in response to that bug it seems a bit of a shame that inertia
is apparently the controlling factor here.

Cheers, Phil.

[Christoph Anton Mitterer]

Post by Philip Hands
I'm glad to say that the default for the Debian package

Unfortunately, Debian overdid it quite a lot and also set a number of
not so smart (respectively security-critical) defaults:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765632

So it's like 1:1 ;-)


Cheers,
Chris.

[Philip Hands]

Post by Christoph Anton Mitterer

Post by Philip Hands
I'm glad to say that the default for the Debian package

Unfortunately, Debian overdid it quite a lot and also set a number of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765632
So it's like 1:1 ;-)

Having looked at the bug you mention, I have to agree that the
ForwardX11Trusted seems to have been misguided at the time it was
applied, and now (over a decade later) seems just plain wrong.

I've followed up on the bug to that effect, Cc-ing you, so you should
have seen that.

Cheers, Phil.

P.S. I take it that you were not trying to say that there's anything you
object to about the proposal to use "without-password" as the default?

[Christoph Anton Mitterer]

Post by Philip Hands
P.S. I take it that you were not trying to say that there's anything you
object to about the proposal to use "without-password" as the default?

Yes,... the upstream default should be either without-password or simply
no, actually, for security reasons I'd even prefer the later.

In the days of fully automated installation, puppet and Co. it can't be
so hard for sysadmins to change that value to something != no when this
is what they really want.


Distros, IMHO, can overwrite the defaults (if there's really good
reason),... but only in the config files, where everyone sees this.
Really changing the defaults in code is basically in most if not all
cases plain wrong (the only exceptions I could think of is, when
upstream would really set defaults which are horribly security critical
or may cause data corruption or things like that).


Cheers,
Chris.