9:57 a.m.
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
10:03 a.m.
On Mon, Oct 3, 2016 at 8:57 AM, Chris Murphy <lists(a)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...
--
Chris Murphy
10:38 a.m.
On 10/03/2016 11:03 AM, Chris Murphy wrote:
On Mon, Oct 3, 2016 at 8:57 AM, Chris Murphy
<lists(a)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.
2:16 a.m.
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.
10:47 a.m.
On Tue, Oct 4, 2016 at 1:16 AM, Lars Seipel <lars.seipel(a)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.
--
Chris Murphy
11:07 a.m.
On 10/04/2016 11:47 AM, Chris Murphy wrote:
On Tue, Oct 4, 2016 at 1:16 AM, Lars Seipel
<lars.seipel(a)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.
1 p.m.
On Tue, Oct 4, 2016 at 10:07 AM, Stephen Gallagher <sgallagh(a)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(a)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.
--
Chris Murphy
5:17 a.m.
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(a)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.
>
>
>
8:37 a.m.
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
9 a.m.
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.
9:43 a.m.
On Wed, Oct 5, 2016 at 8:00 AM, Stephen Gallagher <sgallagh(a)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.
--
Chris Murphy
9:56 a.m.
On 10/05/2016 10:43 AM, Chris Murphy wrote:
On Wed, Oct 5, 2016 at 8:00 AM, Stephen Gallagher
<sgallagh(a)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.
11:08 a.m.
On Wed, Oct 5, 2016 at 8:56 AM, Stephen Gallagher <sgallagh(a)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(a)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?
--
Chris Murphy
3:02 a.m.
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,
--
Jakub Jelen
Associate Software Engineer
Security Technologies
Red Hat
7:24 a.m.
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,
8:07 a.m.
On Thu, Oct 6, 2016 at 8:24 AM, Stephen Gallagher <sgallagh(a)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.
9:31 a.m.
On 6 October 2016 at 09:07, Jon Stanley <jonstanley(a)gmail.com> wrote:
On Thu, Oct 6, 2016 at 8:24 AM, Stephen Gallagher
<sgallagh(a)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.]
https://xkcd.com/1200/
_______________________________________________
server mailing list -- server(a)lists.fedoraproject.org
To unsubscribe send an email to server-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
10:10 a.m.
On Thu, Oct 6, 2016 at 8:07 AM, Jon Stanley <jonstanley(a)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).
11:06 a.m.
On 10/06/2016 11:10 AM, Vinny Valdez wrote:
On Thu, Oct 6, 2016 at 8:07 AM, Jon Stanley <jonstanley(a)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.
11:43 a.m.
On Thu, Oct 6, 2016 at 11:06 AM, Stephen Gallagher <sgallagh(a)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.
11:56 a.m.
On Thu, Oct 6, 2016 at 10:06 AM, Stephen Gallagher <sgallagh(a)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(a)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?
--
Chris Murphy
11:19 p.m.
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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to server-leave(a)lists.fedoraproject.org
2759
days inactive
2763
days old
server@lists.fedoraproject.org
21 comments
10 participants
participants (10)
-
Chris Murphy -
Jakub Jelen -
Jon Stanley -
Lars Seipel -
Mark Dean -
Martin Kolman -
Michael R. Davis -
Stephen Gallagher -
Stephen John Smoogen -
Vinny Valdez