On 12 January 2015 at 09:20, Milan Keršláger <milan.kerslager(a)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