openssh password-authentication? should be #f by default

OpenSubmitted by Christopher Allan Webber.
Details
5 participants
  • Chris Marusich
  • Christopher Allan Webber
  • Leo Famulari
  • Maxim Cournoyer
  • Marius Bakke
Owner
unassigned
Severity
normal
C
C
Christopher Allan Webber wrote on 28 Apr 2017 16:37
(address . bug-guix@gnu.org)
87k264tx8m.fsf@dustycloud.org
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.
M
M
Maxim Cournoyer wrote on 28 Apr 2017 18:09
01F8858C-D359-42CA-96A6-45F6C4A3B80C@gmail.com
On April 28, 2017 7:37:13 AM PDT, Christopher Allan Webber <cwebber@dustycloud.org> wrote:
Toggle quote (8 lines)
>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.
C
C
Christopher Allan Webber wrote on 28 Apr 2017 18:37
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 26695@debbugs.gnu.org)
87h9184heg.fsf@dustycloud.org
Maxim Cournoyer writes:

Toggle quote (4 lines)
> +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 :)
M
M
Maxim Cournoyer wrote on 28 Apr 2017 18:40
(name . Christopher Allan Webber)(address . cwebber@dustycloud.org)(address . 26695@debbugs.gnu.org)
579FDA43-57E9-434D-B563-A29D21A42338@gmail.com
On April 28, 2017 9:37:59 AM PDT, Christopher Allan Webber <cwebber@dustycloud.org> wrote:
Toggle quote (12 lines)
>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!
M
M
Marius Bakke wrote on 28 Apr 2017 19:23
(address . 26695@debbugs.gnu.org)
87efwcbg49.fsf@fastmail.com
Christopher Allan Webber <cwebber@dustycloud.org> writes:

Toggle quote (10 lines)
> 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'.


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 :)
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAlkDeqYACgkQoqBt8qM6
VPqQcggAsOZNTZCFhFeY2gD4IV//lSXmFI8fhzuoeB56JeDlzf+3+qQQHzsgii0r
ySF9Gv9jZXm4xppqXUoSZksRF+JACYUVp50Z/PwkekLbEmT+NVeVOjkNxWQvSyZr
giWQwalq+kNdRLQw+YIGECCuTTbudpJ7iwj+UxNka80JJmzRotWBkNyB5ABHeJRY
ElXI6gPK90lTiRcR3BVjTMSkbt5cD1Kbqvy+JsYhAsaBRx6NP4o6I524ec3V6AL0
dYGhUNJPowtu2FxGaG6xaEf43kUnqbcRFk7ORrxpemU55ofKV7WNW2TyXJNh/OAQ
qH85jFMfWp+g7erpE0clH1DoTVzU9Q==
=Hxbh
-----END PGP SIGNATURE-----

C
C
Christopher Allan Webber wrote on 28 Apr 2017 20:25
(name . Marius Bakke)(address . mbakke@fastmail.com)
87efwc4ceo.fsf@dustycloud.org
Marius Bakke writes:

Toggle quote (8 lines)
>> 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.
L
L
Leo Famulari wrote on 28 Apr 2017 21:28
(name . Christopher Allan Webber)(address . cwebber@dustycloud.org)(address . 26695@debbugs.gnu.org)
20170428192834.GB6736@jasmine
On Fri, Apr 28, 2017 at 09:37:13AM -0500, Christopher Allan Webber wrote:
Toggle quote (6 lines)
> 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.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlkDl+IACgkQJkb6MLrK
fwg11w//XrL4cjkmxk0s6TvE88/xQdXNbwLfkvzRJbjbyzo2JLmH/mng16O3e00p
WYCJ1U+dJOVj02KnjkwbVWC6NlaFDFUQoqilnlZhNIUz8Kp++5IEcLNC/DBInvZc
vXi0v+85uLIu8r+AvKgi66vfHHBNN+ZaNpr9SOg3yK4jxMaRr5Q9MdHI+AqZZqxV
Uuun6SjSjv2KOVkDyvcLR16Caa2G3TqnWXLWWomMb18vl5omxqb5TV33XVndUIk2
0HB4lxjlanukXX1Sbp9CItsGbLGDBNHRczDMjMDC4azJ43NmDPp1qN4oH6nKW9WP
2Y7C9KOX/SgjjqdKo0z+OxmRLFxRc2/7pik1G4DAsQ1+i4O1x5g2a1W35B3fJKRf
viW8K2zS4ad5voBPYtWuvpoeHLHu0V2hy1cT1NKrMDChYc+i3BycYcTBIiHo+IqA
1S1TzintiQ6fHwreZs67k4tw34q9W49cxrg2KR61YNvonL98w3edkvHPp/ICqqv8
ZXDJMWmLP1WRjpIwRI/XZD9VZfUWod8oy8WgChffxxTnetPE9hrmfbLaLtdbJjFn
Tc/K2GWetNj2U4v6bfr5zeM/eJ65Az4m9J/FrvV6R2lyyknMTap9LYSUnGn3uZFI
wViM5ADjxuCaaaAv2B9RA1Q5K9Esfq5FBe0MyIUDfITr1kspAO4=
=qlcz
-----END PGP SIGNATURE-----


C
C
Chris Marusich wrote on 30 Apr 2017 21:47
(name . Marius Bakke)(address . mbakke@fastmail.com)
87ziexfzjp.fsf@gmail.com
Marius Bakke <mbakke@fastmail.com> writes:

Toggle quote (16 lines)
> Christopher Allan Webber <cwebber@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.

Toggle quote (5 lines)
> 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:


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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlkGP0oACgkQ3UCaFdgi
Rp2esA/9EynXEf+d1ZILmFHnCLqhQxDV0tt8bk77NvfzSfIIDSJUFK67VrlvK0Ao
nQiJefk0oiS7/2amCr88tiwuz2n7F2Fq5quW+cd8qbrvQzV/A4+bkB/08lj+zuSB
XYzq3/6Gu27EEnEyrNlMjmGrgokBCxfjgiOPHQQnwa7jALjTE7S9sxQJkxeVPfE3
2uinXUGuRXWjjEdzaUA7K8QhfXWTft3A4W+XavtXYkeYksvJVTnwarE8GBwqucw0
Lqf2jMzs4KQGHQ7zkdbyjy4Sww0rBe6C+2oZMWOVKBAsp/dltacbNEK3IABKdl9b
CLKpSUjKMhzzyojJsKlCLqbGGpmarWWcnMUUlC541zwYpcEYxiuD4IEYMRdzFgzB
GyWZHT1oN9mvMN9Lm43kUlTXMxeSOLMew4DZQCVUS7whW1G4my6k80kEqj8si6SU
9bo+qVQWvdjsoG2am8oelG2CrTUlCipuPvVa4SXHheKk1Vtrncq/KYLuicShA2Qs
EP6AWRrV03LJnzyGo3XB3s9n16NyqhX3jSF9pWfMCUjnpwNMGUjq9Fw5OXawo9Vv
NjFxh1FvcYHhHOE6r8z4ojb+hHkopt1C7MPZC1Vwnzz+LG3Gv3rDaJSkPguaY+21
tNC1bNxy7wTFpDyKWigEHJGd1xcJu8nLUTC3bmw7JodypZ8VXbE=
=oGFT
-----END PGP SIGNATURE-----

?