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

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 13 Jan 2015 04:53:43 +0000 (UTC)
P J P <pj.pandit at yahoo.co.in> wrote:

> > On Tuesday, 13 January 2015 3:06 AM, Miloslav Trmač wrote:
> > (The general theme of this mail: Being flexible is fine, and
> > establishing this through this discussion is great; however,
> > ultimately the Change proposal needs to document the _specific
> > outcome_ of that discussion.²)
> 
>   I understand, I'll do that.
> 
> > “Can be” or “will be”?  How?  It is vaguely worrying that the
> > Change proposal explicitly lists only the most trivial task to do
> > (change a sshd.conf option) and is only fairly generic about how
> > other parts of the OS and users need to and/or will adapt.
> 
>   Well, part of it was due to unknown use-cases of how users would be
> affected by this change. Otherwise, immediate straight forward effect
> is that users would have to create & use non-root accounts first.
> I've tried to collate more details
> 
>   here -> https://www.piratepad.ca/p/ssh-remoterootloigin
> 
> > “Could conditionally“…  With my FESCo hat on, during the Change
> > Checkpoints FESCo will need to know whether the Change is
> > sufficiently complete or whether to fall back to the contingency
> > plan.  Having a “Could conditionally” nailed down to yes or no
> > would prevent general unhappiness if the respective package
> > maintainers thought that they have done the right thing and FESCo
> > during review suddenly decided that the right thing is the opposite.
> 
>   Right, I understand. It's 'could conditionally' because it's still
> early stage proposed change in workflow.
> 
> > So this proposal only helps if we hope that a bot won’t try the
> > right user name; calling this security by obscurity is not too wide
> > off the mark.
> 
> 
>   I beg to differ here a little. Because nothing is stopping them
> from trying non-root accounts now and even with 'without-password'
> option, nothing changes for non-root accounts. The proposed change
> and use of 'PermitRootLogin' option is only to restrict remote 'root'
> access. IMO that's not obscurity.
> 
> So, we do seem to have consensus(at least no opposition) for
> 'PermitRootLogin=without-password' option. I'll update the feature
> page with it and details about the specific use-cases.

There is no consensus on that. I do not do enough installs that I use
kickstart so can not put a key in place. On a freshly installed system
I have to log in as root with a password to do configuration. I
strongly suspect that I am not alone here. You need to talk to the
anaconda team and work out a plan to deal with all the different
options. up to and including having the current defaults exist when
only a root account is configured with only a password for
authentication. I suspect that to properly support making changes here
it needs to be strongly tied into anaconda changes that manage the
initial sshd config file.

Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUtUkxAAoJEH7ltONmPFDRuo0QAKhPOBWtsbPVQwwiPbMG6IcU
rKFh3ItDN5MmTiomGfOiyTKNg9aiOq+nygeC+imMr8gmRIASey3kYNaUAGZsdO3Y
3nq5c3YJyv2rcesRJFCsvu6Odr5KhcOTSOJeMrbbCuT/WvOOK49NPBxIkA5DiDUY
UZlKt7FHEAKj5kEdstGgkRKtZrU89TLZd0LG0Ko/HJSkkA5QRopE28z5DOxzD0gr
1Jr5LLbXBVy2ZNYZQY3rUDmbz1w+qZfRz1mPKR+SVsy+BzxYkrCazM8Qd57aJsWz
lb+LAg24sLamax4wiTRJ2FG8XyQ9HmrofpKaYiuRM5xtZG8yHXr0JGKbxEjKJqUv
H8GsFmGnuRQpH/usb7uVTMnF7AAlcAo1YpUrOUuSlPtizXq86hu4rAm95JxrQetI
L31o0Bmf56JptO3hCAPVuqCiUKv4Qbzgj5x0Qljgm8tCdzaWhVIiuqg9WBGovGYT
ajlNNjSYLhLswPf37q6E1O2IkPd5a8VlJ/+oGXcm2YcVAlY2lhrufNEb8QmnebxM
5wnX+wB4tx6+7V5MypfDH66UrxGz4YkIJKFvEcy21bBO1f7savyzOgJA/0yk1UNJ
U6889pxdhjrrRYPD9YI9HMaGxuZxrCRmGhWwrPWm3fpLMFFh0Qvi320O+nWuvRd4
08m+hckd0KadFeFqwsE1
=3RoX
-----END PGP SIGNATURE-----