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

Francisco Alonso rs at revskills.cz
Mon Jan 12 10:48:12 UTC 2015


Hi,

That's not security through obscurity. It's a way to limit the exposure to
a brute force attack with an a privileged account.
Also this allows the user uses a different account so remote attacks that
user is unknown and can not be used to brute force delimiting more
exposure.
Most instances cloud providers do this basically, like EC2 where the normal
user for a predefined fedora cloud instance is 'fedora'  (
public key-based authentication).
Whenever possible need to limit remote access, and one of the most
important points are the privileges of these remote access.

It must be guaranteed a minimum of security for all users
(Desktop/Cloud/Whatever).
Should be the responsibility of the administrator to enable this remote
access.


-- 

Francisco Alonso.
http://twitter.com/revskills
PGP: 0xE2E64DCA
--

On Mon, Jan 12, 2015 at 10:40 AM, Milan Keršláger <milan.kerslager at pslib.cz>
wrote:

> No, this is not good idea as I wrote few minutes ago because it does not
> improve security, it just provide feeling of better security, see:
> https://en.wikipedia.org/wiki/Security_through_obscurity
>
> I wonder why no-one responded like me, because this was discussed many
> times ago. Well maybe many times since 1995 (when SSH was born) and
> maybe I'm a little bit old so I read it many times again and again.
>
> It seems like SSH does not make padding sufficiently, but this changes
> nothing on what I wrote.
>
> Disabling root loging does not solve the problem and it profides only
> false feeling of security.
>
> M.K.
>
> Dne 12.1.2015 v 09:56 P J P napsal(a):
> >   Hello,
> >
> >> On Sunday, 11 January 2015 2:27 PM, Peter Robinson wrote:
> >>>> Earlier in the discussions I was told that this is not really an
> issue: in
> >>>> production, about every server with remote access also has a KVM.
> >>> Often not the case in small business or third party hosted
> environments.
> >>> Without remote ssh, box is unmanageable.
> >>>
> >>> Even if you want to do key-based authentication rather than password,
> you
> >>> still need to use password initially to get the key onto the remote
> box.
> >> If you use cloud-init you can specify an initial public key that it
> >> inserts against, or even auto enrol it in a central auth system like
> >> IPA and hence not ever need a password.
> >   So, the major issue(or blocker should we say?) is the virtualized
> deployments. If there is no solution in sight, maybe last resort is to
> enable remote root login, possibly in the '%post' install section of the
> kick-start file.
> >
> > Does it seem like an appropriate solution?
> > ---
> > Regards
> >    -Prasad
> > http://feedmug.com
>
> --
>                             Milan Keršláger
>                             http://www.pslib.cz/ke/
>                             http://www.nti.tul.cz/wiki/Milan.Kerslager
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



-- 

Francisco Alonso.
http://twitter.com/revskills
PGP: 0xE2E64DCA
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150112/bfe6cba4/attachment-0001.html>


More information about the devel mailing list