GNU bug report logs -
#26695
openssh password-authentication? should be #f by default
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26695 in the body.
You can then email your comments to 26695 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#26695
; Package
guix
.
(Fri, 28 Apr 2017 14:38:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Christopher Allan Webber <cwebber <at> dustycloud.org>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Fri, 28 Apr 2017 14:38:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Our default permits password authentication for the openssh service (and
the others it seems) by default in Guix. This is somewhat dangerous
because this is a much easier to break in this way, and some users might
not assume the default is reasonably safe. If users really want
password-authentication, they should turn it on explicitly.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#26695
; Package
guix
.
(Fri, 28 Apr 2017 16:10:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 26695 <at> debbugs.gnu.org (full text, mbox):
On April 28, 2017 7:37:13 AM PDT, Christopher Allan Webber <cwebber <at> dustycloud.org> wrote:
>Our default permits password authentication for the openssh service
>(and
>the others it seems) by default in Guix. This is somewhat dangerous
>because this is a much easier to break in this way, and some users
>might
>not assume the default is reasonably safe. If users really want
>password-authentication, they should turn it on explicitly.
+1. Although it means the keys will have to be copied by another mean than the "ssh-copy-id" script. Maybe the configuration could accept the public key? :) I haven't checked if this is already possible.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#26695
; Package
guix
.
(Fri, 28 Apr 2017 16:11:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#26695
; Package
guix
.
(Fri, 28 Apr 2017 16:39:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 26695 <at> debbugs.gnu.org (full text, mbox):
Maxim Cournoyer writes:
> +1. Although it means the keys will have to be copied by another mean
> than the "ssh-copy-id" script. Maybe the configuration could accept
> the public key? :) I haven't checked if this is already possible.
We have discussed in the past having some service that just copies some
static files on init. That would be enough to set up public keys
appropriately.
That's a different, but related bug :)
Information forwarded
to
bug-guix <at> gnu.org
:
bug#26695
; Package
guix
.
(Fri, 28 Apr 2017 16:41:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 26695 <at> debbugs.gnu.org (full text, mbox):
On April 28, 2017 9:37:59 AM PDT, Christopher Allan Webber <cwebber <at> dustycloud.org> wrote:
>Maxim Cournoyer writes:
>
>> +1. Although it means the keys will have to be copied by another mean
>> than the "ssh-copy-id" script. Maybe the configuration could accept
>> the public key? :) I haven't checked if this is already possible.
>
>We have discussed in the past having some service that just copies some
>static files on init. That would be enough to set up public keys
>appropriately.
>
>That's a different, but related bug :)
I see! Indeed, it seems it would solve the problem to have such service. Thanks for the reply!
Information forwarded
to
bug-guix <at> gnu.org
:
bug#26695
; Package
guix
.
(Fri, 28 Apr 2017 17:24:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 26695 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Christopher Allan Webber <cwebber <at> dustycloud.org> writes:
> Maxim Cournoyer writes:
>
>> +1. Although it means the keys will have to be copied by another mean
>> than the "ssh-copy-id" script. Maybe the configuration could accept
>> the public key? :) I haven't checked if this is already possible.
>
> We have discussed in the past having some service that just copies some
> static files on init. That would be enough to set up public keys
> appropriately.
I think that can already be done with 'special-file-service-type'.
https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00332.html
Another approach could be a small program that reads a configuration
file and can also pull from e.g. the ec2 metadata service which should
work with many "cloud" providers. Similar to "cloud-init" but Guile of
course :)
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#26695
; Package
guix
.
(Fri, 28 Apr 2017 18:26:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 26695 <at> debbugs.gnu.org (full text, mbox):
Marius Bakke writes:
>> We have discussed in the past having some service that just copies some
>> static files on init. That would be enough to set up public keys
>> appropriately.
>
> I think that can already be done with 'special-file-service-type'.
>
> https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00332.html
Interesting! I'll have to try this route.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#26695
; Package
guix
.
(Fri, 28 Apr 2017 19:29:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 26695 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Apr 28, 2017 at 09:37:13AM -0500, Christopher Allan Webber wrote:
> Our default permits password authentication for the openssh service (and
> the others it seems) by default in Guix. This is somewhat dangerous
> because this is a much easier to break in this way, and some users might
> not assume the default is reasonably safe. If users really want
> password-authentication, they should turn it on explicitly.
The upstream default is to allow password authentication (see
sshdconfig(5)).
With the current GuixSD defaults, my understanding is that nobody will
be able to login remotely to a new GuixSD system with the default
openssh-service, unless they make the effort to insert the user's
password in their GuixSD declaration. Remote root login and empty
password login is disabled by default.
So the current situation seems safe to me. Please let us know if you see
a hole.
Allowing passwords is not the best practice for securing sshd, but I
think it's a good default for the openssh-service until we have a better
way to deploy keys.
If we do change the password authentication default to #f, I think we
should do it in a new Guix release, since it will probably break GuixSD
provisioning scripts that people are using.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#26695
; Package
guix
.
(Sun, 30 Apr 2017 19:48:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 26695 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Marius Bakke <mbakke <at> fastmail.com> writes:
> Christopher Allan Webber <cwebber <at> dustycloud.org> writes:
>
>> Maxim Cournoyer writes:
>>
>>> +1. Although it means the keys will have to be copied by another mean
>>> than the "ssh-copy-id" script. Maybe the configuration could accept
>>> the public key? :) I haven't checked if this is already possible.
>>
>> We have discussed in the past having some service that just copies some
>> static files on init. That would be enough to set up public keys
>> appropriately.
>
> I think that can already be done with 'special-file-service-type'.
>
> https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00332.html
Will OpenSSH know where to look, in that case? I think a little more
work would be needed to tell OpenSSH where to look. For example, you
would have to customize the value of AuthorizedKeysFile in the OpenSSH
daemon's config file (see 'man opensshd_config' for details).
In any case, it would be better if we could hide all of that in the
abstraction we have for the OpenSSH service. For instance, it would be
nice if we could just specify the public keys in the operating system
configuration file, as part of the <openssh-configuration> record type.
> Another approach could be a small program that reads a configuration
> file and can also pull from e.g. the ec2 metadata service which should
> work with many "cloud" providers. Similar to "cloud-init" but Guile of
> course :)
This topic has come up before. Cloud-init (specifically, the idea of
pulling SSH credentials in at first boot via the EC2 metadata service)
is a useful hack for systems that cannot be declaratively defined, but
for GuixSD it should not be needed. See here for details:
https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00214.html
https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00757.html
https://lists.gnu.org/archive/html/help-guix/2016-11/msg00075.html
Somebody just needs to implement the changes to our OpenSSH service
abstraction so that we can declare the public keys in the operating
system configuration file. Of course, to deploy onto EC2 without manual
intervention would also require more changes, but that's a separate
issue from the issue of how to get credentials onto the host.
--
Chris
[signature.asc (application/pgp-signature, inline)]
Reply sent
to
Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
:
You have taken responsibility.
(Tue, 29 Aug 2023 03:26:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Christopher Allan Webber <cwebber <at> dustycloud.org>
:
bug acknowledged by developer.
(Tue, 29 Aug 2023 03:26:03 GMT)
Full text and
rfc822 format available.
Message #34 received at 26695-done <at> debbugs.gnu.org (full text, mbox):
Hi,
Leo Famulari <leo <at> famulari.name> writes:
> On Fri, Apr 28, 2017 at 09:37:13AM -0500, Christopher Allan Webber wrote:
>> Our default permits password authentication for the openssh service (and
>> the others it seems) by default in Guix. This is somewhat dangerous
>> because this is a much easier to break in this way, and some users might
>> not assume the default is reasonably safe. If users really want
>> password-authentication, they should turn it on explicitly.
>
> The upstream default is to allow password authentication (see
> sshdconfig(5)).
>
> With the current GuixSD defaults, my understanding is that nobody will
> be able to login remotely to a new GuixSD system with the default
> openssh-service, unless they make the effort to insert the user's
> password in their GuixSD declaration. Remote root login and empty
> password login is disabled by default.
>
> So the current situation seems safe to me. Please let us know if you see
> a hole.
I agree with your assessment. I think there's probably more hurt than
benefit in diverging from upstream's choice of defaults here.
I'm thus closing this old forgotten report.
--
Thanks,
Maxim
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 26 Sep 2023 11:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 227 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.