About sshd(8) remote root login feature & Anaconda UI support

[P J P]

Hello all,

Please see:
-> https://www.piratepad.ca/p/ssh-remoterootloigin
-> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
-> https://lists.fedoraproject.org/pipermail/devel/2015-January/206157.html

This is a F22 feature that proposes to restrict remote 'root' access via ssh,
by setting the "PermitRootLogin=without-password" option in default sshd(8)
configuration.

- As result, one would require at least one non-root user account to be
created at install time.

- And if a user does not want to create non-root account, a provision needs
to be made to enable remote root access by setting 'PermitRootLogin=Yes'
in the sshd(8) configuration.

- Additionally, one might wish to add the ssh keys at installation time.
It seems similar function is provided by cloud-init tool.

Though many agree that it is a useful change and usage of ssh keys for
authentication offers more long term benefits, major contention is that this
change would break user experience and should have support in Anaconda UI
to enable remote root access.

Could a CheckBox be added to the Anaconda installation workflow, which would
be used to enable remote root access, by setting PermitRootLogin='Yes'.
Something like:

===
sshd(8) server has restricted remote 'root' access via ssh keys
authentication only. This could potentially lock you out of the system,
unless you have created a non-root account or have configured ssh keys
for authentication. Would you like to enable remote 'root' access via
password authentication?

[] Enable remote root access via password.
===

This is one of the suggestion, the feature page lists few more workflow
changes that are deemed necessary. I'm not sure how easy or difficult it
is to implement these changes.

Could someone please help us with the implementation of these changes?
If so, should RFE bugs be filed for these changes?? I'm willing to
help in any way I could.

If you have any comments or suggestions about the proposed feature and/or
accompanying workflow changes, they are most welcome.

Thank you.
---
Regards
-Prasad
http://feedmug.com

[P J P]

Hello all,

Please see:
-> https://www.piratepad.ca/p/ssh-remoterootloigin
-> https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
-> https://lists.fedoraproject.org/pipermail/devel/2015-January/206157.html

This is a F22 feature that proposes to restrict remote 'root' access via ssh,
by setting the "PermitRootLogin=without-password" option in default sshd(8)
configuration.

- As result, one would require at least one non-root user account to be
created at install time.

- And if a user does not want to create non-root account, a provision needs
to be made to enable remote root access by setting 'PermitRootLogin=Yes'
in the sshd(8) configuration.

- Additionally, one might wish to add the ssh keys at installation time.
It seems similar function is provided by cloud-init tool.

Though many agree that it is a useful change and usage of ssh keys for
authentication offers more long term benefits, major contention is that this
change would break user experience and should have support in Anaconda UI
to enable remote root access.

Could a CheckBox be added to the Anaconda installation workflow, which would
be used to enable remote root access, by setting PermitRootLogin='Yes'.
Something like:

===
sshd(8) server has restricted remote 'root' access via ssh keys
authentication only. This could potentially lock you out of the system,
unless you have created a non-root account or have configured ssh keys
for authentication. Would you like to enable remote 'root' access via
password authentication?

[] Enable remote root access via password.
===

This is one of the suggestion, the feature page lists few more workflow
changes that are deemed necessary. I'm not sure how easy or difficult it
is to implement these changes.

Could someone please help us with the implementation of these changes?
If so, should RFE bugs be filed for these changes?? I'm willing to
help in any way I could.

If you have any comments or suggestions about the proposed feature and/or

accompanying workflow changes, they are most welcome.

Thank you.
---Regards
-Prasad
http://feedmug.com

[David Shea]

Post by P J P
Could a CheckBox be added

No. UI changes are not something that should be done casually, and UI
changes that requires a paragraph of text to explain are going to be
either not read or not understood by the majority of users.

The first question I have: do we really need to do anything at all? Do
we expect any use cases where someone does an interactive install and
will not have console access when they are done? If so, can we just turn
password-based root login on if no admin user is created during the install?

[P J P]

Hello David,

Post by David Shea
No. UI changes are not something that should be done casually, and UI
changes that requires a paragraph of text to explain are going to be
either not read or not understood by the majority of users.

Agreed. It was only meant to convey an idea. Actual UI design and text
could be different.

Post by David Shea
The first question I have: do we really need to do anything at all? Do
we expect any use cases where someone does an interactive install and
will not have console access when they are done?

Right, that seems unlikely, but there might be cases, I'm not sure. Given
below are the Server SIG meeting logs, wherein this topic was discussed
and the UI changes were suggested.

Please see:
-> http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-13/fedora-meeting-1.2015-01-13-16.00.log.html

Post by David Shea
If so, can we just turn password-based root login on if no admin user
is created during the install?

Not admin, but non-root user. It'll definitely help to enable password-based
root login, if no non-root user is created.

Either solution would serve the purpose. Main intention is that end user
should not get locked out of their freshly installed Fedora systems,
because of the proposed feature change.

Thank you.
---
Regards
-Prasad
http://feedmug.com

[Brian C. Lane]

Post by P J P
Hello David,

Post by David Shea
No. UI changes are not something that should be done casually, and UI
changes that requires a paragraph of text to explain are going to be
either not read or not understood by the majority of users.

Agreed. It was only meant to convey an idea. Actual UI design and text
could be different.

Post by David Shea
The first question I have: do we really need to do anything at all? Do
we expect any use cases where someone does an interactive install and
will not have console access when they are done?

That's certainly possible if they're using vnc to setup the system and
reboot before setting up keys manually. Most providers also offer
console access to systems these days, but it is certainly possible to
end with only ssh access to the box.

Post by P J P
Right, that seems unlikely, but there might be cases, I'm not sure. Given
below are the Server SIG meeting logs, wherein this topic was discussed
and the UI changes were suggested.
-> http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-13/fedora-meeting-1.2015-01-13-16.00.log.html

Post by David Shea
If so, can we just turn password-based root login on if no admin user
is created during the install?

Not admin, but non-root user. It'll definitely help to enable password-based
root login, if no non-root user is created.
Either solution would serve the purpose. Main intention is that end user
should not get locked out of their freshly installed Fedora systems,
because of the proposed feature change.

I don't like the idea of switching options in the background based on
what combination of users, checkboxes, etc. have been set. That's going
to end up confusing people or leaving the setup in an unexpected state.0

Switching root to key only really doesn't help much. All that does is
move the attack to the user account (assuming they are in wheel).
Disabling password login for all accounts is what would make it secure.

But the problem with that is that there is no good way to get the
authorized key onto the system if they do need to login via ssh. You can
now do this in kickstart using the new sshkey command.

A possible alternative is:

1. Stronger root password. We really should switch from a minimum length
of 6 to 8 anyway.

2. Don't allow weak root passwords at all. Remove the double done click
to bypass it. This will annoy me while installing vms repeatedly, but it
is an improvement while still allowing remote access.

3. And maybe drop root login completely and move to user+strong pw+wheel

This would increase security, a bit, and still let users connect to a
fresh system without console access.

[Dennis Gilmore]

On Thu, 15 Jan 2015 12:08:35 -0800

Post by Brian C. Lane

Post by P J P
Hello David,

Post by David Shea
No. UI changes are not something that should be done casually,
and UI changes that requires a paragraph of text to explain are
going to be either not read or not understood by the majority of
users.

Agreed. It was only meant to convey an idea. Actual UI design and
text could be different.

Post by David Shea
The first question I have: do we really need to do anything at
all? Do we expect any use cases where someone does an interactive
install and will not have console access when they are done?

That's certainly possible if they're using vnc to setup the system and
reboot before setting up keys manually. Most providers also offer
console access to systems these days, but it is certainly possible to
end with only ssh access to the box.

Post by P J P
Right, that seems unlikely, but there might be cases, I'm not
sure. Given below are the Server SIG meeting logs, wherein this
topic was discussed and the UI changes were suggested.
->
http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-13/fedora-meeting-1.2015-01-13-16.00.log.html

Post by David Shea
If so, can we just turn password-based root login on if no admin
user is created during the install?

Not admin, but non-root user. It'll definitely help to enable
password-based root login, if no non-root user is created.
Either solution would serve the purpose. Main intention is that end
user should not get locked out of their freshly installed Fedora
systems, because of the proposed feature change.

I don't like the idea of switching options in the background based on
what combination of users, checkboxes, etc. have been set. That's
going to end up confusing people or leaving the setup in an
unexpected state.0
Switching root to key only really doesn't help much. All that does is
move the attack to the user account (assuming they are in wheel).
Disabling password login for all accounts is what would make it secure.
But the problem with that is that there is no good way to get the
authorized key onto the system if they do need to login via ssh. You
can now do this in kickstart using the new sshkey command.

This is good to know.

Post by Brian C. Lane
1. Stronger root password. We really should switch from a minimum
length of 6 to 8 anyway.

+1

Post by Brian C. Lane
2. Don't allow weak root passwords at all. Remove the double done
click to bypass it. This will annoy me while installing vms
repeatedly, but it is an improvement while still allowing remote
access.

while i will be annoyed on test machines I would accept this.

Post by Brian C. Lane
3. And maybe drop root login completely and move to user+strong pw+wheel

Many people, myself included never use local accounts and join a
machine to an ipa domain or some other sort of remote service. Having
security through obscurity is really not a effective way to implement.
and it will annoy users. I think we should just make root more secure.

Post by Brian C. Lane
This would increase security, a bit, and still let users connect to a
fresh system without console access.

Dennis

[Adam Williamson]

Post by Brian C. Lane
2. Don't allow weak root passwords at all. Remove the double done
click to bypass it. This will annoy me while installing vms
repeatedly, but it is an improvement while still allowing remote
access.

It will also make QA people hate our lives. srsly, sounds like a small
thing, but typing 'correcthorse' 25,674 times during a release cycle
will drive me freaking batty. if we go to onerous root pw
requirements, we're really gonna need a sekrit cmdline switch to
disable it or something.

[Chris Murphy]

On Thu, Jan 15, 2015 at 11:25 PM, Adam Williamson

Post by Adam Williamson

Post by Brian C. Lane
2. Don't allow weak root passwords at all. Remove the double done
click to bypass it. This will annoy me while installing vms
repeatedly, but it is an improvement while still allowing remote
access.

It will also make QA people hate our lives. srsly, sounds like a small
thing, but typing 'correcthorse' 25,674 times during a release cycle
will drive me freaking batty. if we go to onerous root pw
requirements, we're really gonna need a sekrit cmdline switch to
disable it or something.

I have to agree. I dislike this feature so much I'd rather read of
some small corner of the Internet burn because one of our users had
too much gin one night while configuring Fedora, used 12345 as their
root password, and the computer was made part of a giant botnet
overnight. I assume that's the sort of thing we're trying to prevent?
Preventing collateral damage? Because baby sitting users who can't be
bothered to set sufficiently strong passwords is really inappropriate.

[P J P]

Hello Brian,

Post by Brian C. Lane
Switching root to key only really doesn't help much. All that does is
move the attack to the user account (assuming they are in wheel).
Disabling password login for all accounts is what would make it secure.

Agreed. Though IMO we can not directly jump to that default,
when hardly few users know and use ssh keys for authentication.
Introducing it first for the 'root' account is a reasonable step
forward, which in future would evolve into key authentication for
all accounts.

Post by Brian C. Lane
But the problem with that is that there is no good way to get the
authorized key onto the system if they do need to login via ssh. You can
now do this in kickstart using the new sshkey command.

I see. Is it possible to have UI support for this command?(not sure if it is)

Post by Brian C. Lane
1. Stronger root password. We really should switch from a minimum length
of 6 to 8 anyway.

I think that should be for all accounts, no just 'root'. But as others
have expressed, it'd be bothersome when one has to type it repeatedly.

Post by Brian C. Lane
2. Don't allow weak root passwords at all. Remove the double done click
to bypass it. This will annoy me while installing vms repeatedly, but it
is an improvement while still allowing remote access.
3. And maybe drop root login completely and move to user+strong pw+wheel

I think this would prove more intrusive at this stage. IMO gradual, step
by step change is better than drastically shifting the norm.
Show message history

Post by Brian C. Lane
I don't like the idea of switching options in the background based on
what combination of users, checkboxes, etc. have been set. That's going
to end up confusing people or leaving the setup in an unexpected state.0

I understand. However, at this early stage, it may not be a very bad idea.
Today we only need to inform users that password based authentication for
'root' account is not available and that they need to use keys and/or non-root
accounts, as preferred. They need to get used to the idea of keys first.

Maybe sshd(8) daemon could also return an error message saying password
authentication for 'root' account is prohibited. When user attempts to
connect as 'root'.(just a thought)

Thank you.
---
Regards
-Prasad
http://feedmug.com

[David Shea]

Post by P J P
I see. Is it possible to have UI support for this command?(not sure if it is)

How would the key be delivered in this case? The kickstart command just
takes the key as a string, and obviously expecting the user to type in a
ssh key isn't going to work. Read from storage? Download from a URL?

[P J P]

Hello,

Post by David Shea
How would the key be delivered in this case? The kickstart command just
takes the key as a string, and obviously expecting the user to type in a
ssh key isn't going to work. Read from storage? Download from a URL?

Right, true; Reading from storage also sounds iffy, URL support could be good. To be honest, this is still an advance feature we can have in subsequent releases.

For now, first we need a provision so that users are not locked out of their freshly installed systems. Ie. enable remote root access('PermitRootLogin=Yes') if no non-root account is created OR let user make the choice.

Yesterday I installed F21 on my machine. In that, while creating a non-root account, Anaconda shows a CheckBox with caption about '..use password authentication...', maybe similar one could be added to the window for setting 'root' password. Only in that we prompt user if they wish to 'enable' remote root access via ssh(8). This CheckBox must be disabled by default.

Does that sound okay?
---
Regards
-Prasad
http://feedmug.com

[Adam Williamson]

Post by P J P
Hello,

Post by David Shea
How would the key be delivered in this case? The kickstart command
just takes the key as a string, and obviously expecting the user
to type in a
ssh key isn't going to work. Read from storage? Download from a URL?

Right, true; Reading from storage also sounds iffy, URL support
could be good. To be honest, this is still an advance feature we can
have in subsequent releases.
For now, first we need a provision so that users are not locked out
of their freshly installed systems. Ie. enable remote root
access('PermitRootLogin=Yes') if no non-root account is created OR
let user make the choice.
Yesterday I installed F21 on my machine. In that, while creating a
non-root account, Anaconda shows a CheckBox with caption about
'..use password authentication...', maybe similar one could be added
to the window for setting 'root' password. Only in that we prompt
user if they wish to 'enable' remote root access via ssh(8). This
CheckBox must be disabled by default.
Does that sound okay?

It's not really the same thing. The user account check box says
"Require a password to use this account". If you uncheck it, the
account is usable without one, basically a guest account. Notably,
anaconda doesn't need to know anything more than how to set up an
account, in that case.

Your checkbox gets anaconda into the business of knowing how to edit
the sshd configuration file, which seems like the kind of sprawl that
all else being equal it can live without. We don't live in a perfect
world and sometimes anaconda needs to be able to do stuff like that
(it can kick off realmd commands and configure the firewall and things
too), but it *is* more complicated than just a box which decides
whether it sets a password on an account at all.

[P J P]

Post by Adam Williamson
Your checkbox gets anaconda into the business of knowing how to edit
the sshd configuration file, which seems like the kind of sprawl that
all else being equal it can live without. We don't live in a perfect
world and sometimes anaconda needs to be able to do stuff like that
(it can kick off realmd commands and configure the firewall and things
too), but it *is* more complicated than just a box which decides
whether it sets a password on an account at all.

Agreed; IMO that complexity is not a blocker kind. Besides, the CheckBox
solution is just a suggestion(ie. one of the option). If there is a better
solution, by all means we should go with that OR as said before if Anaconda
decides to do it by itself in the background, that is fine too. Intention
is to keep users from locking themselves out of their newly installed systems.


---
Regards
-Prasad
http://feedmug.com

[Leslie S Satenstein]

From: Adam Williamson <***@fedoraproject.org>
To: P J P <***@fedoraproject.org>; Discussion of Development and Customization of the Red Hat Linux Installer <anaconda-devel-***@redhat.com>
Sent: Saturday, January 17, 2015 12:27 AM
Subject: Re: About sshd(8) remote root login feature & Anaconda UI support

    Hello,

Post by David Shea
How would the key be delivered in this case? The kickstart command
just takes the key as a string, and obviously expecting the user
to type in a
ssh key isn't going to work. Read from storage? Download from a URL?

  Right, true; Reading from storage also sounds iffy, URL support
could be good. To be honest, this is still an advance feature we can
have in subsequent releases.
For now, first we need a provision so that users are not locked out
of their freshly installed systems. Ie. enable remote root
access('PermitRootLogin=Yes') if no non-root account is created OR
let user make the choice.
Yesterday I installed F21 on my machine. In that, while creating a
non-root account, Anaconda shows a CheckBox with caption about
'..use password authentication...', maybe similar one could be added
to the window for setting 'root' password. Only in that we prompt
user if they wish to 'enable' remote root access via ssh(8). This
CheckBox must be disabled by default.
Does that sound okay?

It's not really the same thing. The user account check box says
"Require a password to use this account". If you uncheck it, the
account is usable without one, basically a guest account. Notably,
anaconda doesn't need to know anything more than how to set up an
account, in that case.

Your checkbox gets anaconda into the business of knowing how to edit
the sshd configuration file, which seems like the kind of sprawl that
all else being equal it can live without. We don't live in a perfect
world and sometimes anaconda needs to be able to do stuff like that
(it can kick off realmd commands and configure the firewall and things
too), but it *is* more complicated than just a box which decides
whether it sets a password on an account at all.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net



I use the Canadian French Keyboard. From bitter experience, I learned never to use Eurosign€,¥, other non a-z characters for root password. If the keyboard fails to be properly setup, its repair flash drive and lost time. I choose something simple like abcd123$ and definitely replace that root password on the first reboot.
Please do not change this part of anaconda.   (off topic)If you do want something good for Fedora22. Choose a root desktop background that significantly different from the non root user default background.    Why?  There are times that I log into Gnome as root to perform some file maintenance. Nautilus is great for file maintenance (cut and paste, drag and drop, etc). The different desktop background that I always reset is used to remind me to not access the web browser while logged as root, and as well, to logoff immediately after completing the tasks. So far, never had an accidental rm -rf * or mv * command line error.   
 Regards
 Leslie
Mr. Leslie Satenstein
Montréal Québec, Canada

[P J P]

Post by P J P

Post by David Shea
How would the key be delivered in this case? The kickstart command just
takes the key as a string, and obviously expecting the user to type in a
ssh key isn't going to work. Read from storage? Download from a URL?

For now, first we need a provision so that users are not locked out of their
freshly installed systems. Ie. enable remote root
access('PermitRootLogin=Yes') if no non-root account is created OR let
user make the choice.
Yesterday I installed F21 on my machine. In that, while creating a non-root
account, Anaconda shows a CheckBox with caption about '..use password
authentication...', maybe similar one could be added to the window for
setting 'root' password. Only in that we prompt user if they wish to
'enable' remote root access via ssh(8). This CheckBox must be disabled
by default.
Does that sound okay?

@David...? @Brian..?



The feature has been deferred to F23 citing insufficient support in installer UI.
If we are to take a step towards non-password based authentication and safer defaults,
we need to find a solution for this glitch. Your inputs would be valuable in that.


---Regards
-Prasad
http://feedmug.com

[Brian C. Lane]

Post by P J P

Post by P J P

Post by David Shea
How would the key be delivered in this case? The kickstart command just
takes the key as a string, and obviously expecting the user to type in a
ssh key isn't going to work. Read from storage? Download from a URL?

For now, first we need a provision so that users are not locked out of their
freshly installed systems. Ie. enable remote root
access('PermitRootLogin=Yes') if no non-root account is created OR let
user make the choice.
Yesterday I installed F21 on my machine. In that, while creating a non-root
account, Anaconda shows a CheckBox with caption about '..use password
authentication...', maybe similar one could be added to the window for
setting 'root' password. Only in that we prompt user if they wish to
'enable' remote root access via ssh(8). This CheckBox must be disabled
by default.
Does that sound okay?

@David...? @Brian..?
The feature has been deferred to F23 citing insufficient support in installer UI.
If we are to take a step towards non-password based authentication and safer defaults,
we need to find a solution for this glitch. Your inputs would be valuable in that.

Sorry to take to long to follow up, I was trying to get enough time to
at least skim the fedora-devel thread.

I think the goal here is good. Better security is always a plus.

But I don't think mandating a sshd config change is the right way to do
it. Or adding checkboxes, or text entries for ssh keys in the installer.
This makes it harder for a significant number of users to setup their
systems and really only moves the problem into guessing the
username+password instead of just guessing root's password.

The installer already gives the users the tools to make their systems
secure:

In GUI mode if you create a normal user that is a member of wheel the
root account is locked, unless you also set a root password. This is
effectively the same as changing the config.

In kickstart we have the same ability, as well as the new sshkey
command so that you can set the ssh key for root or any other account
that is created.

Users who are concerned with security already know how to setup their
systems, use strong passwords, switch to key only logins, etc. They
aren't the ones who need help.

Instead I propose that we increase our minimum password length to 8
characters, and disallow weak passwords. The initial pain of creating a
throw-away password for your vm can be mitigated by running pwgen and
writing down a nice looking one on a sticky note :)

[Adam Williamson]

Post by Brian C. Lane
Instead I propose that we increase our minimum password length to 8
characters, and disallow weak passwords. The initial pain of
creating a throw-away password for your vm can be mitigated by
running pwgen and writing down a nice looking one on a sticky note :)

I've already said it once so I'll only say it once more, but this
change is horrible for QA. 'Secure' passwords are nothing but a major
pain in the ass when testing disposable installations in isolated
environments, which is what we do, over and over and over and over
again, for weeks.

[Adam Williamson]

Post by Brian C. Lane
Instead I propose that we increase our minimum password length to 8
characters, and disallow weak passwords. The initial pain of
creating a throw-away password for your vm can be mitigated by
running pwgen and writing down a nice looking one on a sticky note :)

I've already said it once so I'll only say it once more, but this
change is horrible for QA. 'Secure' passwords are nothing but a major
pain in the ass when testing disposable installations in isolated
environments, which is what we do, over and over and over and over
again, for weeks.

[P J P]

Hello Brian,

Post by Brian C. Lane
Sorry to take to long to follow up, I was trying to get enough time to
at least skim the fedora-devel thread.
I think the goal here is good. Better security is always a plus.

Thank you for going through the details, I appreciate it.

Post by Brian C. Lane
But I don't think mandating a sshd config change is the right way to do
it.

Well, intention is not to make it mandatory, but to make it default.

Post by Brian C. Lane
Or adding checkboxes, or text entries for ssh keys in the installer.
This makes it harder for a significant number of users to setup their
systems and really only moves the problem into guessing the
username+password instead of just guessing root's password.

The change is mostly seen as a remedy against brute-force attacks.
It is not. The feature aims to provide hardened defaults as precautionary
measure. It is similar to using SELinux or running services with non-root
account instead of root account. Having stronger defaults has much greater
impact than users selectively securing their systems.

Post by Brian C. Lane
The installer already gives the users the tools to make their systems
In GUI mode if you create a normal user that is a member of wheel the
root account is locked, unless you also set a root password. This is
effectively the same as changing the config.

Exactly! Similarly it'll help if Anaconda could 'enable' remote
root access when no non-root account is created at install time.

Post by Brian C. Lane
Users who are concerned with security already know how to setup their
systems, use strong passwords, switch to key only logins, etc. They
aren't the ones who need help.

Very true! That is why we need to serve strong default configurations,
because they have much greater impact, than otherwise.

Post by Brian C. Lane
Instead I propose that we increase our minimum password length to 8
characters, and disallow weak passwords. The initial pain of creating a
throw-away password for your vm can be mitigated by running pwgen and
writing down a nice looking one on a sticky note :)

In principle I don't disagree with it; But IMO it can not be a replacement
to stronger defaults. And secondly, as Adam and many have said earlier,
it could adversely affect their daily routines. Especially when there is no
option to revert back to current defaults ie. 6 characters. Though I'm not sure
if it's that big of a pain to type 2 more characters once you are used to it.


Considering the options so far, IMHO Anaconda enabling remote root access,
when no non-root account is created at install time, is a good solution.
It is the minimalist change on Anaconda's side, which could unlock the greater
value of providing stronger defaults and introducing the key based authentication
to the wider audience. It would certainly prove to be a good move for Fedora.


...wdyt?

---
Regards
-Prasad
http://feedmug.com

[Adam Williamson]

Post by P J P

Post by Brian C. Lane
Instead I propose that we increase our minimum password length to
8characters, and disallow weak passwords. The initial pain of
creating a throw-away password for your vm can be mitigated by
running pwgen and writing down a nice looking one on a sticky note
:)

In principle I don't disagree with it; But IMO it can not be a replacement
to stronger defaults. And secondly, as Adam and many have said
earlier, it could adversely affect their daily routines. Especially
when there is no
option to revert back to current defaults ie. 6 characters. Though I'm not sure
if it's that big of a pain to type 2 more characters once you are used to it.

It's not the character count, it's the 'disallow weak passwords'. I
can deal with 11111111 instead of 111111, but correcthorse is more of a
pain (if libcrack or whatever still allows it, even).

It's also not consistent with other components, not that we've ever
managed to get them all entirely consistent. gnome-initial-setup
allows weak passwords with a small warning, and it creates an admin
user.

[P J P]

Post by Adam Williamson
It's not the character count, it's the 'disallow weak
passwords'. I can deal with 11111111 instead of 111111,
but correct horse is more of a pain (if libcrack or whatever
still allows it, even).

Right, I can understand. In general it seems that we are okay
with the stronger defaults as long as we have freedom to choose
weaker values as and when required. That I think is reasonable.


---
Regards
-Prasad
http://feedmug.com

[Bruno Wolff III]

On Tue, Jan 27, 2015 at 08:26:52 -0800,

Post by Adam Williamson
It's not the character count, it's the 'disallow weak passwords'. I
can deal with 11111111 instead of 111111, but correcthorse is more of a
pain (if libcrack or whatever still allows it, even).

Not that I am a big fan of the referenced change, but could yubikeys make
this tolerable?

[Pete Travis]

Post by David Shea

Post by P J P
Could a CheckBox be added

No. UI changes are not something that should be done casually, and UI

changes that requires a paragraph of text to explain are going to be either
not read or not understood by the majority of users.

Post by David Shea
The first question I have: do we really need to do anything at all? Do we

expect any use cases where someone does an interactive install and will not
have console access when they are done? If so, can we just turn
password-based root login on if no admin user is created during the install?

Post by David Shea
_______________________________________________

If there is interest in something like a "Remote Login with Keys Only"
element next to where the root password is set, and that blurb isn't
inherently informative enough, we can provide a help doc for it that
concisely explains meaning and application.

/me makes no claims about design expertise, but is willing to write the
help text...

--Pete