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

P J P pj.pandit at yahoo.co.in
Mon Jan 12 13:05:45 UTC 2015


> On Monday, 12 January 2015 5:59 PM, Milan Keršláger wrote:

> You are (instead of completly mitigating), only raising complexity a
> little bit (ie not completly avoiding), which is what is "Security
> through obscurity" about (ie. by hiding source code, the attacker only
> solve more complex problem - debugging machine code).
>
> One more time: The system can be cracked by BF attack only if there is a
> weak (root) password.

  Sure. As guessed, you misunderstood the intention. The feature is _not_ a remedy against brute force attacks. But it is a remedy for keeping such attackers from gaining 'root' access on remote machines. The feature says,

  "...Disabling remote root login by setting PermitRootLogin=no would help to harden Fedora systems, moving it an inch closer towards 'secure by default' future. Users can have non-root accounts with weak passwords too, yet disabling remote root login keeps an attacker a step away from getting full control on a system..."

The feature helps to _harden_ Fedora systems. Same as filtering traffic via firewall or restricting undue access via SELinux etc.


> If you disable remote root login (bacause users are using weak crackable
> password), you are saying to the user: "Happily use simple password
> because you are safe even that!". And because when admin password could
> be simple then the user password will be more simpler (this is
> average-user-logic) and the BF against the system will succeed more
> easily (even the login name will need to be guessed or picked by another
> way). So your solution is potentionally more dangerous than current
> situation.

  That is a lot of speculation and hypothesis. In now way does this feature imply or indicate to users that they can use weak passwords.

> If you want to avoid the problem (ie avoid BF crack-in), disabling
> remote root login is not the right way, this is simply not enough, this
> does not solve the problem. There are better solutions I wrote about
> already (prefferrably to not expose SSH to the wild by default).


  Again, issue being addressed is not of brute force attacks. But that of such attacks resulting in gaining 'root' access to remote machines. They are two distinct issues.

---
Regards
   -Prasad
http://feedmug.com


More information about the devel mailing list