Hi,
I'm noticing even with cockpit-0.117 in Fedora 24 Server, that it supports ssh key assignment for users. Since it's possible to login to cockpit out of the box, and setup ssh keys via the web interface, is it now practical to set these by default in the F26/F27 time frame? And if not, what additional work needs to be done?
Disable root logins with ssh /etc/ssh/sshd_config PermitRootLogin no
Disable root entirely (sudo -i still works) usermod -p '!' root
Disable password login with ssh (key only) /etc/ssh/sshd_config PasswordAuthentication no
In my case I use all three as pretty much the first step for a new Fedora 24 Server installation.
On Mon, Oct 3, 2016 at 8:57 AM, Chris Murphy lists@colorremedies.com wrote:
Hi,
I'm noticing even with cockpit-0.117 in Fedora 24 Server, that it supports ssh key assignment for users. Since it's possible to login to cockpit out of the box, and setup ssh keys via the web interface, is it now practical to set these by default in the F26/F27 time frame? And if not, what additional work needs to be done?
Disable root logins with ssh /etc/ssh/sshd_config PermitRootLogin no
Disable root entirely (sudo -i still works) usermod -p '!' root
Disable password login with ssh (key only) /etc/ssh/sshd_config PasswordAuthentication no
In my case I use all three as pretty much the first step for a new Fedora 24 Server installation.
An alternative might be disabling sshd out of the box. It could be turned on via cockpit, and require no additional configuration to ssh login. That perhaps is a compromise between better out of the box security and usability.
The existing Fedora 24 documentation how to setup public key based authentication looks good to me. If there's a way to link to that, or even more concise documentation somewhere within Cockpit, does that alleviate usability concerns by configuring sshd by default to not accept password authentication?
https://docs.fedoraproject.org/en-US/Fedora/24/html/System_Administrators_Gu...
On 10/03/2016 11:03 AM, Chris Murphy wrote:
On Mon, Oct 3, 2016 at 8:57 AM, Chris Murphy lists@colorremedies.com wrote:
Hi,
I'm noticing even with cockpit-0.117 in Fedora 24 Server, that it supports ssh key assignment for users. Since it's possible to login to cockpit out of the box, and setup ssh keys via the web interface, is it now practical to set these by default in the F26/F27 time frame? And if not, what additional work needs to be done?
Disable root logins with ssh /etc/ssh/sshd_config PermitRootLogin no
Disable root entirely (sudo -i still works) usermod -p '!' root
Disable password login with ssh (key only) /etc/ssh/sshd_config PasswordAuthentication no
In my case I use all three as pretty much the first step for a new Fedora 24 Server installation.
An alternative might be disabling sshd out of the box. It could be turned on via cockpit, and require no additional configuration to ssh login. That perhaps is a compromise between better out of the box security and usability.
Unfortunately, there are two large problems with this approach: Cockpit and Ansible.
Cockpit relies on the SSH port being available if we want to use it to monitor/manage multiple systems. Similarly, if we want our systems to be manageable via Ansible out-of-the-box, they're going to need SSH running with some sort of a predictable, root-equivalent user at least.
On Mon, Oct 03, 2016 at 09:03:05AM -0600, Chris Murphy wrote:
An alternative might be disabling sshd out of the box. It could be turned on via cockpit, and require no additional configuration to ssh login. That perhaps is a compromise between better out of the box security and usability.
Having to manually log in to a web interface before you can use your server is a waste of time and an absolut non-solution.
Doesn't Cockpit allow password-based login just as well? Why do you consider it any more resistant to attack than OpenSSH sshd?
Of course, public-key-based auth would be the superior approach. But short of installing from a custom kickstart, you need a way to get your keys to the machine in the first place. Disabling sshd without solving the actual problem first is only going to annoy users.
If the officially supported install method for Server created customized images with integrated SSH keys, that would be the point where no one would mind the disabling of password logins.
On Tue, Oct 4, 2016 at 1:16 AM, Lars Seipel lars.seipel@gmail.com wrote:
On Mon, Oct 03, 2016 at 09:03:05AM -0600, Chris Murphy wrote:
An alternative might be disabling sshd out of the box. It could be turned on via cockpit, and require no additional configuration to ssh login. That perhaps is a compromise between better out of the box security and usability.
Having to manually log in to a web interface before you can use your server is a waste of time and an absolut non-solution.
OK.
Doesn't Cockpit allow password-based login just as well? Why do you consider it any more resistant to attack than OpenSSH sshd?
Most ssh attacks are initiated by bots. Could someone teach a bot how to iterate Cockpit logins? OK sure, and then teach the bot how to "navigate" and turn on services it wants to exploit, like ssh. Possible but pretty unlikely. Also I'd expect there's a much much longer time delay in between failed Cockpit logins compared to sshd.
Of course, public-key-based auth would be the superior approach. But short of installing from a custom kickstart, you need a way to get your keys to the machine in the first place. Disabling sshd without solving the actual problem first is only going to annoy users.
That's why I was suggesting adding the key via Cockpit. I'll buy that it's a hurdle or two to do that. But it's the same over on macOS and Windows - these services are not enabled out of the box even on their server equivalents. I'm all in favor of doing better than that. But the idea that it's untenable isn't convincing seeing as many people do exactly that and aren't super bothered by it.
If the officially supported install method for Server created customized images with integrated SSH keys, that would be the point where no one would mind the disabling of password logins.
Sounds like two parts: some method of transferring the client pub key to the install target, and a method for the installer to install it in the correct location. The install media doesn't enable ssh, and even if it were enabled, no user exists with a default password so it's not possible to scp.
Rudimentary idea: have the install media created with sshd enabled; when the sysadmin doing the OS installation creates the first (admin) user and password, use that not just for the installed system but also for the running installation environment; now it's possible to scp the public key to say /tmp where a post-install script puts it into the correct location once created.
On 10/04/2016 11:47 AM, Chris Murphy wrote:
On Tue, Oct 4, 2016 at 1:16 AM, Lars Seipel lars.seipel@gmail.com wrote:
On Mon, Oct 03, 2016 at 09:03:05AM -0600, Chris Murphy wrote:
An alternative might be disabling sshd out of the box. It could be turned on via cockpit, and require no additional configuration to ssh login. That perhaps is a compromise between better out of the box security and usability.
Having to manually log in to a web interface before you can use your server is a waste of time and an absolut non-solution.
OK.
Doesn't Cockpit allow password-based login just as well? Why do you consider it any more resistant to attack than OpenSSH sshd?
Most ssh attacks are initiated by bots. Could someone teach a bot how to iterate Cockpit logins? OK sure, and then teach the bot how to "navigate" and turn on services it wants to exploit, like ssh. Possible but pretty unlikely. Also I'd expect there's a much much longer time delay in between failed Cockpit logins compared to sshd.
Maybe from HTTP overhead, but otherwise they're ultimately going to use the same PAM stack (with whatever lockout policy we implement).
Of course, public-key-based auth would be the superior approach. But short of installing from a custom kickstart, you need a way to get your keys to the machine in the first place. Disabling sshd without solving the actual problem first is only going to annoy users.
That's why I was suggesting adding the key via Cockpit. I'll buy that it's a hurdle or two to do that. But it's the same over on macOS and Windows - these services are not enabled out of the box even on their server equivalents. I'm all in favor of doing better than that. But the idea that it's untenable isn't convincing seeing as many people do exactly that and aren't super bothered by it.
I mentioned in another reply that the problem with this approach is that Cockpit's communication between machines (when managing more than one) is via SSH as well, so this would make it very hard to initially get them running.
On Tue, Oct 4, 2016 at 10:07 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On 10/04/2016 11:47 AM, Chris Murphy wrote:
On Tue, Oct 4, 2016 at 1:16 AM, Lars Seipel lars.seipel@gmail.com wrote:
On Mon, Oct 03, 2016 at 09:03:05AM -0600, Chris Murphy wrote:
An alternative might be disabling sshd out of the box. It could be turned on via cockpit, and require no additional configuration to ssh login. That perhaps is a compromise between better out of the box security and usability.
Having to manually log in to a web interface before you can use your server is a waste of time and an absolut non-solution.
OK.
Doesn't Cockpit allow password-based login just as well? Why do you consider it any more resistant to attack than OpenSSH sshd?
Most ssh attacks are initiated by bots. Could someone teach a bot how to iterate Cockpit logins? OK sure, and then teach the bot how to "navigate" and turn on services it wants to exploit, like ssh. Possible but pretty unlikely. Also I'd expect there's a much much longer time delay in between failed Cockpit logins compared to sshd.
Maybe from HTTP overhead, but otherwise they're ultimately going to use the same PAM stack (with whatever lockout policy we implement).
Of course, public-key-based auth would be the superior approach. But short of installing from a custom kickstart, you need a way to get your keys to the machine in the first place. Disabling sshd without solving the actual problem first is only going to annoy users.
That's why I was suggesting adding the key via Cockpit. I'll buy that it's a hurdle or two to do that. But it's the same over on macOS and Windows - these services are not enabled out of the box even on their server equivalents. I'm all in favor of doing better than that. But the idea that it's untenable isn't convincing seeing as many people do exactly that and aren't super bothered by it.
I mentioned in another reply that the problem with this approach is that Cockpit's communication between machines (when managing more than one) is via SSH as well, so this would make it very hard to initially get them running.
Yes, the Ansible case will take something more clever. The rudimentary example doesn't scale.
On Tue, 2016-10-04 at 09:47 -0600, Chris Murphy wrote:
On Tue, Oct 4, 2016 at 1:16 AM, Lars Seipel lars.seipel@gmail.com wrote:
On Mon, Oct 03, 2016 at 09:03:05AM -0600, Chris Murphy wrote:
An alternative might be disabling sshd out of the box. It could be turned on via cockpit, and require no additional configuration to ssh login. That perhaps is a compromise between better out of the box security and usability.
Having to manually log in to a web interface before you can use your server is a waste of time and an absolut non-solution.
OK.
Doesn't Cockpit allow password-based login just as well? Why do you consider it any more resistant to attack than OpenSSH sshd?
Most ssh attacks are initiated by bots. Could someone teach a bot how to iterate Cockpit logins? OK sure, and then teach the bot how to "navigate" and turn on services it wants to exploit, like ssh. Possible but pretty unlikely. Also I'd expect there's a much much longer time delay in between failed Cockpit logins compared to sshd.
Of course, public-key-based auth would be the superior approach. But short of installing from a custom kickstart, you need a way to get your keys to the machine in the first place. Disabling sshd without solving the actual problem first is only going to annoy users.
That's why I was suggesting adding the key via Cockpit. I'll buy that it's a hurdle or two to do that. But it's the same over on macOS and Windows - these services are not enabled out of the box even on their server equivalents. I'm all in favor of doing better than that. But the idea that it's untenable isn't convincing seeing as many people do exactly that and aren't super bothered by it.
If the officially supported install method for Server created customized images with integrated SSH keys, that would be the point where no one would mind the disabling of password logins.
Sounds like two parts: some method of transferring the client pub key to the install target, and a method for the installer to install it in the correct location. The install media doesn't enable ssh,
Not by default, but it can be be enabled by a boot option: https://github.com/rhinstaller/anaconda/blob/master/docs/boot-options.r st#instsshd The SSH password for the installation environment can be set by kickstart: https://github.com/rhinstaller/pykickstart/blob/master/docs/kickstart-d ocs.rst#sshpw
and even if it were enabled, no user exists with a default password so it's not possible to scp.
Rudimentary idea: have the install media created with sshd enabled; when the sysadmin doing the OS installation creates the first (admin) user and password, use that not just for the installed system but also for the running installation environment; now it's possible to scp the public key to say /tmp where a post-install script puts it into the correct location once created.
An alternative might be disabling sshd out of the box
I have never understood why every daemon does not have it's own "-on" RPM. So, the RPM has all of the logic to do the right thing on how to enable it correctly. So, to enable sshd the user would install 'openssh-server-on' and be done. We would not be making a decision for the user. We would be enabling the user to make the decision for themselves. Also any service that required sshd to be on and running would simply require openssh-server-on in their RPM. Mike mrdvt92
On 10/05/2016 09:37 AM, Michael R. Davis wrote:
An alternative might be disabling sshd out of the box
I have never understood why every daemon does not have it's own "-on" RPM. So, the RPM has all of the logic to do the right thing on how to enable it correctly.
So, to enable sshd the user would install 'openssh-server-on' and be done. We would not be making a decision for the user. We would be enabling the user to make the decision for themselves.
How is this any better than just logging in to Cockpit and flipping the "enable" switch (or running `systemctl enable foo.service`)? Seems like having extra RPMs running around would be more trouble than it was worth.
Also, some RPMs provide more than one service, so now we have to have an extra -on RPM for every individual service in the packages? That starts growing the RPM metadata unreasonably and slows down updates-processing for everyone, particularly those on metered connections.
Also any service that required sshd to be on and running would simply require openssh-server-on in their RPM.
We already have that functionality built into systemd unit files, which is how we do it today. The RPM-based solution would just make everything *harder*, because now you'd have two different mechanisms for enablement interacting that you'd have to resolve.
On Wed, Oct 5, 2016 at 8:00 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On 10/05/2016 09:37 AM, Michael R. Davis wrote:
An alternative might be disabling sshd out of the box
I have never understood why every daemon does not have it's own "-on" RPM. So, the RPM has all of the logic to do the right thing on how to enable it correctly.
So, to enable sshd the user would install 'openssh-server-on' and be done. We would not be making a decision for the user. We would be enabling the user to make the decision for themselves.
How is this any better than just logging in to Cockpit and flipping the "enable" switch (or running `systemctl enable foo.service`)? Seems like having extra RPMs running around would be more trouble than it was worth.
I agree.
Also, some RPMs provide more than one service, so now we have to have an extra -on RPM for every individual service in the packages? That starts growing the RPM metadata unreasonably and slows down updates-processing for everyone, particularly those on metered connections.
Also any service that required sshd to be on and running would simply require openssh-server-on in their RPM.
We already have that functionality built into systemd unit files, which is how we do it today. The RPM-based solution would just make everything *harder*, because now you'd have two different mechanisms for enablement interacting that you'd have to resolve.
Right. 'systemctl enable' just creates symlinks, so why not have a toggle in the installer that creates or destroys the symlink? You can decide whether it should default on or off, but still have a user facing choice that at the very least informs them there's this service that'll be running.
On 10/05/2016 10:43 AM, Chris Murphy wrote:
On Wed, Oct 5, 2016 at 8:00 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On 10/05/2016 09:37 AM, Michael R. Davis wrote:
An alternative might be disabling sshd out of the box
I have never understood why every daemon does not have it's own "-on" RPM. So, the RPM has all of the logic to do the right thing on how to enable it correctly.
So, to enable sshd the user would install 'openssh-server-on' and be done. We would not be making a decision for the user. We would be enabling the user to make the decision for themselves.
How is this any better than just logging in to Cockpit and flipping the "enable" switch (or running `systemctl enable foo.service`)? Seems like having extra RPMs running around would be more trouble than it was worth.
I agree.
Also, some RPMs provide more than one service, so now we have to have an extra -on RPM for every individual service in the packages? That starts growing the RPM metadata unreasonably and slows down updates-processing for everyone, particularly those on metered connections.
Also any service that required sshd to be on and running would simply require openssh-server-on in their RPM.
We already have that functionality built into systemd unit files, which is how we do it today. The RPM-based solution would just make everything *harder*, because now you'd have two different mechanisms for enablement interacting that you'd have to resolve.
Right. 'systemctl enable' just creates symlinks, so why not have a toggle in the installer that creates or destroys the symlink? You can decide whether it should default on or off, but still have a user facing choice that at the very least informs them there's this service that'll be running.
Right, and we already have this. They're called "presets" and we have custom ones for each Fedora Edition.
On Wed, Oct 5, 2016 at 8:56 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On 10/05/2016 10:43 AM, Chris Murphy wrote:
On Wed, Oct 5, 2016 at 8:00 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On 10/05/2016 09:37 AM, Michael R. Davis wrote:
An alternative might be disabling sshd out of the box
I have never understood why every daemon does not have it's own "-on" RPM. So, the RPM has all of the logic to do the right thing on how to enable it correctly.
So, to enable sshd the user would install 'openssh-server-on' and be done. We would not be making a decision for the user. We would be enabling the user to make the decision for themselves.
How is this any better than just logging in to Cockpit and flipping the "enable" switch (or running `systemctl enable foo.service`)? Seems like having extra RPMs running around would be more trouble than it was worth.
I agree.
Also, some RPMs provide more than one service, so now we have to have an extra -on RPM for every individual service in the packages? That starts growing the RPM metadata unreasonably and slows down updates-processing for everyone, particularly those on metered connections.
Also any service that required sshd to be on and running would simply require openssh-server-on in their RPM.
We already have that functionality built into systemd unit files, which is how we do it today. The RPM-based solution would just make everything *harder*, because now you'd have two different mechanisms for enablement interacting that you'd have to resolve.
Right. 'systemctl enable' just creates symlinks, so why not have a toggle in the installer that creates or destroys the symlink? You can decide whether it should default on or off, but still have a user facing choice that at the very least informs them there's this service that'll be running.
Right, and we already have this. They're called "presets" and we have custom ones for each Fedora Edition.
We already have a visible toggle in the installer?
On 10/03/2016 04:57 PM, Chris Murphy wrote:
Hi,
I'm noticing even with cockpit-0.117 in Fedora 24 Server, that it supports ssh key assignment for users. Since it's possible to login to cockpit out of the box, and setup ssh keys via the web interface, is it now practical to set these by default in the F26/F27 time frame? And if not, what additional work needs to be done?
Disable root logins with ssh /etc/ssh/sshd_config PermitRootLogin no
Disable root entirely (sudo -i still works) usermod -p '!' root
Disable password login with ssh (key only) /etc/ssh/sshd_config PasswordAuthentication no
In my case I use all three as pretty much the first step for a new Fedora 24 Server installation.
We have the RFE [1] to disable root login in OpenSSH for years (namely 13). Upstream already did that and set default to "prohibit-password", which is quite sane default, if you are able to set up the public keys in the installer or create some sudo-user you are good.
From the comments, it looks like expected deployments are still quite dependent on allowed root login by default (Ansible, even remote cockpit ...). The change was again requested few years ago [2], but didn't made it through the FESCO (rejected by Server SIG) [3].
From my point of view, this is the way we should go, but it needs to be organized across all the dependent consumers that rely on the root account enabled in SSH. Before doing that, we need to find some alternative how to do things there.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=89216 [2] https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no [3] https://fedorahosted.org/fesco/ticket/1386
Regards,
On 10/06/2016 04:02 AM, Jakub Jelen wrote:
On 10/03/2016 04:57 PM, Chris Murphy wrote:
Hi,
I'm noticing even with cockpit-0.117 in Fedora 24 Server, that it supports ssh key assignment for users. Since it's possible to login to cockpit out of the box, and setup ssh keys via the web interface, is it now practical to set these by default in the F26/F27 time frame? And if not, what additional work needs to be done?
Disable root logins with ssh /etc/ssh/sshd_config PermitRootLogin no
Disable root entirely (sudo -i still works) usermod -p '!' root
Disable password login with ssh (key only) /etc/ssh/sshd_config PasswordAuthentication no
In my case I use all three as pretty much the first step for a new Fedora 24 Server installation.
We have the RFE [1] to disable root login in OpenSSH for years (namely 13). Upstream already did that and set default to "prohibit-password", which is quite sane default, if you are able to set up the public keys in the installer or create some sudo-user you are good.
From the comments, it looks like expected deployments are still quite dependent on allowed root login by default (Ansible, even remote cockpit ...). The change was again requested few years ago [2], but didn't made it through the FESCO (rejected by Server SIG) [3].
The problem is not that specifically "root" must be enabled as "a remote user login capable of administrative privileges must be present", which in the majority of real-world deployments is functionally equivalent to root.
We haven't come up with a way that disabling remote root login isn't a huge burden on bootstrapping a new deployment.
From my point of view, this is the way we should go, but it needs to be organized across all the dependent consumers that rely on the root account enabled in SSH. Before doing that, we need to find some alternative how to do things there.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=89216 [2] https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no [3] https://fedorahosted.org/fesco/ticket/1386
Regards,
On Thu, Oct 6, 2016 at 8:24 AM, Stephen Gallagher sgallagh@redhat.com wrote:
We haven't come up with a way that disabling remote root login isn't a huge burden on bootstrapping a new deployment.
I think there's one, and it's really quite simple and elegant I think.
First, we remove (or make very non-obvious) the ability to set a root password in the Anaconda GUI, and force the creation of an administrative user. Then to further bootstrap the machine, you MUST login with that user and use sudo. Ansible natively supports this (using 'become') and Cockpit also supports login by such a user.
Of course, users that needed the ability to set a root password for whatever reason could do so via kickstart.
On 6 October 2016 at 09:07, Jon Stanley jonstanley@gmail.com wrote:
On Thu, Oct 6, 2016 at 8:24 AM, Stephen Gallagher sgallagh@redhat.com wrote:
We haven't come up with a way that disabling remote root login isn't a huge burden on bootstrapping a new deployment.
I think there's one, and it's really quite simple and elegant I think.
First, we remove (or make very non-obvious) the ability to set a root password in the Anaconda GUI, and force the creation of an administrative user. Then to further bootstrap the machine, you MUST login with that user and use sudo. Ansible natively supports this (using 'become') and Cockpit also supports login by such a user.
Of course, users that needed the ability to set a root password for whatever reason could do so via kickstart.
Isn't this just shuffling the chairs on the titanic? Especially in preinstalled systems in a cloud or VPS? There has to be an account that someone needs to get into remotely that needs to become root. If we are worried about bad passwords we are going to have bad passwords in that user and we haven't fixed anything because once they have that user they can sudo and put the bad password they know in for that user. [I believe various ssh bots do this by default so it isn't a leap here.]
server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org
On Thu, Oct 6, 2016 at 8:07 AM, Jon Stanley jonstanley@gmail.com wrote:
I think there's one, and it's really quite simple and elegant I think.
First, we remove (or make very non-obvious) the ability to set a root password in the Anaconda GUI, and force the creation of an administrative user. Then to further bootstrap the machine, you MUST login with that user and use sudo. Ansible natively supports this (using 'become') and Cockpit also supports login by such a user.
What about adding a "paste public key" screen to the Anaconda GUI? Looks like there's already a --sshkey option for kickstart: https://bugzilla.redhat.com/show_bug.cgi?id=1274104 (though I haven't tried it myself).
On 10/06/2016 11:10 AM, Vinny Valdez wrote:
On Thu, Oct 6, 2016 at 8:07 AM, Jon Stanley <jonstanley@gmail.com mailto:jonstanley@gmail.com> wrote:
I think there's one, and it's really quite simple and elegant I think. First, we remove (or make very non-obvious) the ability to set a root password in the Anaconda GUI, and force the creation of an administrative user. Then to further bootstrap the machine, you MUST login with that user and use sudo. Ansible natively supports this (using 'become') and Cockpit also supports login by such a user.
What about adding a "paste public key" screen to the Anaconda GUI? Looks like there's already a --sshkey option for kickstart: https://bugzilla.redhat.com/show_bug.cgi?id=1274104 (though I haven't tried it myself).
Where would they copy it *from*? This is new hardware; I can see this *maybe* working in a VM (if they support copy-paste from the viewer host), but probably not on a physical box.
On Thu, Oct 6, 2016 at 11:06 AM, Stephen Gallagher sgallagh@redhat.com wrote:
Where would they copy it *from*? This is new hardware; I can see this *maybe* working in a VM (if they support copy-paste from the viewer host), but probably not on a physical box.
Good point, I should have said "import key" instead. Perhaps from a URL or USB key is what I was thinking, and possibly from a hardware token like a YubiKey which can be used to generate OpenPGP keys that can be used for SSH authentication, another possibility.
On Thu, Oct 6, 2016 at 10:06 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On 10/06/2016 11:10 AM, Vinny Valdez wrote:
On Thu, Oct 6, 2016 at 8:07 AM, Jon Stanley <jonstanley@gmail.com mailto:jonstanley@gmail.com> wrote:
I think there's one, and it's really quite simple and elegant I think. First, we remove (or make very non-obvious) the ability to set a root password in the Anaconda GUI, and force the creation of an administrative user. Then to further bootstrap the machine, you MUST login with that user and use sudo. Ansible natively supports this (using 'become') and Cockpit also supports login by such a user.
What about adding a "paste public key" screen to the Anaconda GUI? Looks like there's already a --sshkey option for kickstart: https://bugzilla.redhat.com/show_bug.cgi?id=1274104 (though I haven't tried it myself).
Where would they copy it *from*? This is new hardware; I can see this *maybe* working in a VM (if they support copy-paste from the viewer host), but probably not on a physical box.
Get Anaconda to use Apache Guacamole? Connect to the server installation GUI with a web browser instead of VNC?
Are you suggesting that Fedora should come with root logins disabled and as well as ssh via root turned off by default? If so, I'd not like that. If anything, I'd rather it be something that is a setup option so if someone wants to do that it can be done but deciding that for everyone is not the way to go.
On Mon, Oct 3, 2016 at 10:57 AM, Chris Murphy lists@colorremedies.com wrote:
Hi,
I'm noticing even with cockpit-0.117 in Fedora 24 Server, that it supports ssh key assignment for users. Since it's possible to login to cockpit out of the box, and setup ssh keys via the web interface, is it now practical to set these by default in the F26/F27 time frame? And if not, what additional work needs to be done?
Disable root logins with ssh /etc/ssh/sshd_config PermitRootLogin no
Disable root entirely (sudo -i still works) usermod -p '!' root
Disable password login with ssh (key only) /etc/ssh/sshd_config PasswordAuthentication no
In my case I use all three as pretty much the first step for a new Fedora 24 Server installation.
-- Chris Murphy _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@lists.fedoraproject.org
server@lists.fedoraproject.org