I'm +/- 0 here until the Change proposal includes a statement about buy-in from the Anaconda team about the changes they'll need to make to allow this to happen.

ping @mkolman @sbueno

I'm +/- 0 here until the Change proposal includes a statement about buy-in from the Anaconda team about the changes they'll need to make to allow this to happen.

@jjelen have you had any conversations with the Anaconda team about this?

So far only this short one on the github:

https://github.com/rhinstaller/anaconda/issues/1974

Now, I filled the following bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=1716282

To describe the current state a bit from installer perspective - at the moment during both interactive and kickstart installation we require either a root password to be set or admin user (member of wheel group) to be created. Without this requirement being fulfilled, the installation can't be completed.

(There is a slight exception on the Fedora Workstation live image, where no user can be created and no root password can be set, as both tasks are handled by Gnome Initial Setup after the installation.)

So if we assume that being reachable over SSH is one of the requirements of a default Fedora installation, then the "admin user only" case is safe but the "root account only" case is not, as it would not be possible to SSH to such system without manual intervention.

At the same time I guess there are valid cases where people want to install systems with only a root account (single-use machines/VMs, macines/VMs that will be further provisioned with Ansible or similar technology).

So it's apparent the current policies will have to be adjusted, possible solution that comes to my mind:
- if an admin user exists, no root account is required
- if only non-admin user exists, root account (you can ssh in and then switch to root account) is required or user must be made admin
- if only root account exists:
-> for kickstart installs, there needs to be a ssh key set for the root account or new option passed to rootpw command --allowssh, would need to be added to pykickstart
-> for interactive installs a new "allow SSH root login" would have to be ticked

A couple of questions/possible issues:

• I'm a bit worried if we will be able to reasonably represent the requirements in the UI. At the moment we are just requiring "at least one admin-level user needs to exist", while we will have to mix this with "and the system needs to be SSH accessible", which might potentially be confusing for some users.

• Adding SSH keys via UI has been mentioned as one of the possible solution, but I'm unconvinced this would be usable in real installation scenarios. SSH keys are long strings and I can'y really see users typing those in by hand in baremetal installations and even in VM & VNC based installs a working copy-paste is far from a given. Not to mention we can't really validate if a given key is correct, meaning a reinstall would be needed if there is a typo.

For the record, it's is already possible to set SSH keys via the "sshkey" kickstart command. As kickstarts are prepared externally the length of the SSH keys is not really an issue.

• If we decide to add an override to allow root login via SSH (in UI/kickstart or both), how do we set it ? I suspect via changing the ssh config file shipped in the sshd package ? Do we have to parse it, change the option and then write it out again ? Ideally we would like to avoid this ad rather use a different mechanism if possible (dropping a config snipped to a dropdir, calling some utility that would set the option, etc.).

Ad forgot to mention - feedback welcome! :)

This is really just a quick draft how I think it might work, there could still be edge cases I have not expected & better solutions.

SSH keys are long strings and I can'y really see users typing those in by hand in baremetal installations and even in VM & VNC based installs a working copy-paste is far from a given. [...]

Before all the issues from github were removed today, there was a feature request to import SSH key from github -- in that case, the only thing one needs to remember is the github username and pulling the keys from https://github.com/<Username>.keys is easy task. The original issue mentioned that debian installer already supports something like that.

If we decide to add an override to allow root login via SSH (in UI/kickstart or both), how do we set it ? I suspect via changing the ssh config file shipped in the sshd package ? Do we have to parse it, change the option and then write it out again ?

I would like to avoid changing the shipped configuration files. It never brought anything good. But it is pretty simple to add command-line arguments (-oPermitRootLogin=yes in your case) to the daemon from environment file of the unit, either through the /etc/sysconfig/sshd or through separate environment file, what would be more suitable.

Ideally we would like to avoid this ad rather use a different mechanism if possible (dropping a config snipped to a dropdir, calling some utility that would set the option, etc.).

Unfortunately, the drop-in configuration files are still not available in sshd_config so we should be able to get on with the above.

If we would be able to accomplish without the above, but with just some noisy warning if the root password is set, we could make all of that simpler and not advertise "the bad old habit" at all. Anyway, whoever installs the system using GUI, is probably not dependent on the ssh access.

Hope it helped. Let me know if there is something more unclear.

SSH keys are long strings and I can'y really see users typing those in by hand in baremetal installations and even in VM & VNC based installs a working copy-paste is far from a given. [...]

Before all the issues from github were removed today, there was a feature request to import SSH key from github -- in that case, the only thing one needs to remember is the github username and pulling the keys from https://github.com/<Username>.keys is easy task. The original issue mentioned that debian installer already supports something like that.
You that would be much more usable. Do others, such as Gitlab, support something similar as well ?

In any case I recomend opening a RFE for this in Bugzilla for the Anaconda component so we can track this now that the Github issue tracked has been deprecated.

If we decide to add an override to allow root login via SSH (in UI/kickstart or both), how do we set it ? I suspect via changing the ssh config file shipped in the sshd package ? Do we have to parse it, change the option and then write it out again ?

I would like to avoid changing the shipped configuration files. It never brought anything good. But it is pretty simple to add command-line arguments (-oPermitRootLogin=yes in your case) to the daemon from environment file of the unit, either through the /etc/sysconfig/sshd or through separate environment file, what would be more suitable.
Do you mean this mechanism ?

https://coreos.com/os/docs/latest/using-environment-variables-in-systemd-units.html

The separate environment file looks the best from the Anaconda PoV.

Ideally we would like to avoid this ad rather use a different mechanism if possible (dropping a config snipped to a dropdir, calling some utility that would set the option, etc.).

Unfortunately, the drop-in configuration files are still not available in sshd_config so we should be able to get on with the above.
If we would be able to accomplish without the above, but with just some noisy warning if the root password is set, we could make all of that simpler and not advertise "the bad old habit" at all. Anyway, whoever installs the system using GUI, is probably not dependent on the ssh access.
Hope it helped. Let me know if there is something more unclear.
The thing is that at the moment we are consistent with what we allow via both UI based interactive install and via automated kickstart installation.

This could very well be decoupled at the cost of some added complexity and confusion. Also, at the end of the installation Anaconda generates a kickstart file describing the installation and saves it into /root, with the intention being that you can use the same kickstart file to get the same system configuration.

While the are already some changes you might need to change in such generated kickstart file (generally related to passwords) before using it for an installation, this might add yet another thing that would need to be adjusted before the generated kickstart can be used.

In any case I recomend opening a RFE for this in Bugzilla for the Anaconda component so we can track this now that the Github issue tracked has been deprecated.

Filled here:

https://bugzilla.redhat.com/show_bug.cgi?id=1716551

For the environment file, see $ systemctl cat sshd and the lines EnvironmentFile. No problem to add one more and modify the openssh command-line to have also content from anaconda there if we decide this is the way to go.

On Mon, 2019-06-03 at 13:46 +0000, Jakub Jelen wrote:

Before all the issues from github were removed today, there was a
feature request to import SSH key from github -- in that case, the
only thing one needs to remember is the github username and pulling
the keys from https://github.com/<Username>.keys is easy task.

If we made it just a URL (with a strong warning on non-TLS links) then
it could allow the keys to be hosted anywhere.

On Mon, 2019-06-03 at 13:46 +0000, Jakub Jelen wrote:

Before all the issues from github were removed today, there was a
feature request to import SSH key from github -- in that case, the
only thing one needs to remember is the github username and pulling
the keys from https://github.com/<Username>.keys is easy task.

If we made it just a URL (with a strong warning on non-TLS links) then
it could allow the keys to be hosted anywhere.
While I like the idea of adding support for fetching keys from a URL, I don't think we have the capacity to implement this in the F31 timeframe. On the other hand we would certainly accept a well written pull request adding this.

Proposal: Let's defer this change until the technical issues are solved.

(I don't think a FESCo issue is a good place to have a discussion like this.)

Martin, please, lets follow up in https://bugzilla.redhat.com/show_bug.cgi?id=1716282
Can you summarize what would be acceptable solution for anaconda in that bug to start breaking it into pieces that need to be done and where after the initial clarification that happened in previous comments?

Leaving the bug #1716551 aside, I think the least painful thing would be now to have some checkbox in anaconda (which can be dropped later) to enable ssh root access by creating a drop-in environment file. Is this viable for F31?

Tagging with meeting since my proposal was mostly ignored here.

FYI, we updated the bug #1716282 with the next steps and things that need to be changed in anaconda. Please, let me know whether there is something you will need to clarify before or after the meeting.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1716282

Please update the Change page in wiki covering the dependencies work. While we have various conversations regarding this change happening in parallel in bugs and mailing lists, the page in wiki is our most authoritative resource.

I think for dependencies we should have notes like:

• Dependency on X, blocker, tracked in BZ#123, there is agreement with dependency maintainer to work on this in F31 cycle.

@bookwar The Anaconda bug that is a requirement for this change is in the change page for some time under the Scope section. Please, let me know whether it is enough or you need some more information in different sections. I would not call it a "dependency", but part of the work to the change target.

@bookwar The Anaconda bug that is a requirement for this change is in the change page for some time under the Scope section. Please, let me know whether it is enough or you need some more information in different sections. I would not call it a "dependency", but part of the work to the change target.

Sorry, missed it, my bad.

i'd like to see the proposal updated to include the anticipated Anaconda change - this will help in people understanding the change, in preparing release notes, etc..

AGREED: 31 System-Wide Change: Disable Root Password Login in SSH is
approved (+6,0,0) (jforbes, 15:18:14)

Thank you.

@otaylor I updated the actual changes needed in anaconda installer. Please, let me know whether this is enough or you would like to elaborate more in some of the places.