Abotu setting 'PermitRootLogin=no' in sshd_config

[Ian Malone]

On 12 January 2015 at 09:20, Milan Keršláger <milan.kerslager at pslib.cz> wrote:
>>     Hello,
>>

> 4) Blocking root access means forcing admins to log as normal user and
> then do su/sudo and providing root password, which is far less secure
> than disable root password authentication and allow login to root with
> SSH key only, because password could be easily stolen (private key is
> never send to the net so is more safe).

It is only more secure if you assume normal user password ssh is
allowed. It shouldn't be either, it should be ssh key. If you're
allowing password login on any account then you're less secure, even
without discussing sudo.

> 5) When a user provides login/password through ssh, the ssh know whats
> going on, so there is a padding (with nothing) included in the initial
> network communication to prevent spoofing on how the password "sounds
> like" (ie sniffing on password typing), but when the user is logged-in,
> the ssh has no clue what is going on so no padding could be inserted to
> the network communication and this is why there is possibility to attack
> (spoof) on password the user provides when doing su/sudo after
> succesfull login. See SSH protocol explanation and a lot of very good
> articles about this.
> 6) Because all I wrote above, disabling root login is "Security through
> obscurity" and THIS NOT IMPROVE SECURITY! See
> https://cs.wikipedia.org/wiki/Security_through_obscurity and 5) above

It's not really. Security through obscurity is design or
implementation (as outlined in the English version of that wikipedia
page). What this is is somewhere between security in layers and
security in extended keys. User account names can be discovered and
don't add many bytes compared to a secret key, on the other hand it
should be easy to spot brute force attempts on user name. And not
every user account on a system has sudo access, of course you can try
local exploits once you have a shell, but that is still better than
hanging direct root out as a big target to attack. Layers.

>
> There are possible solutions for this problem:
>
> A) do not allow any SSH connection (the user should enable SSH on its own)
> B) provide good blocking script as of 3) above by default [there are
> many out there]
> C) do not allow user to set weak root password at all
>
> As Fedora is focused as desktop, I wonder why SSH is enabled by default.
> RHEL/CentOS/SLES/whatever is focused as server and this sounds me
> reasonable to allow SSH by default.
>

In the past I've had to enable SSHD on Fedora, I don't know what the
current default is, but I don't think it's on by default. Fedora is
also used as a server (indeed there's now a specific 'server' version
and the 'desktop' product seems a bit niche). I've stayed out of this
discussion since, while I have particular things I always do with sshd
configuration, it's about defaults and the points about how the choice
of those defaults affect certain installation scenarios are really the
important thing.

-- 
imalone
http://ibmalone.blogspot.co.uk