-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 13 Jan 2015 04:53:43 +0000 (UTC)
P J P <pj.pandit(a)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-----