Default to allowing password authentication on leaves users vulnerable

  • Open
  • quality assurance status badge
Details
10 participants
  • Dr. Arne Babenhauserheide
  • Carlo Zancanaro
  • Christopher Lemmer Webber
  • Leo Famulari
  • Ludovic Courtès
  • Maxim Cournoyer
  • Mark H Weaver
  • raid5atemyhomework
  • raingloom
  • Taylan Kammer
Owner
unassigned
Submitted by
Christopher Lemmer Webber
Severity
normal
C
C
Christopher Lemmer Webber wrote on 23 Nov 2020 00:20
(address . bug-guix@gnu.org)
878sat3rnn.fsf@dustycloud.org
Okay, I just realized I left a friend vulnerable by guiding them through
a Guix graphical install and telling them it would give them a decent
setup. They turned on openssh support.

Then I realized their config had password-authentication? on.

That's unacceptable. We need to change this default. This is known to
leave users open to attack, and selecting a password secure enough
against brute forcing is fairly difficult, much more difficult than only
allowing entry by keys. Plus, few distributions do what we're doing
anymore, precisely because of wanting to be secure by default.

Yes, I know some people want password authentication on as part of a
bootstrapping process. Fine... those users know to put it on. Let's
not leave our users open to attack by default though.

Happy to produce a patch and change the documentation, but I'd like to
hear that we have consensus to make this change. But we should, because
otherwise else I think we're going to hurt users.

- Chris
T
T
Taylan Kammer wrote on 23 Nov 2020 03:32
4383f179-8e3a-7ce6-0fc0-f4cefeaf613e@gmail.com
On 23.11.2020 00:20, Christopher Lemmer Webber wrote:
Toggle quote (20 lines)
> Okay, I just realized I left a friend vulnerable by guiding them through
> a Guix graphical install and telling them it would give them a decent
> setup. They turned on openssh support.
>
> Then I realized their config had password-authentication? on.
>
> That's unacceptable. We need to change this default. This is known to
> leave users open to attack, and selecting a password secure enough
> against brute forcing is fairly difficult, much more difficult than only
> allowing entry by keys. Plus, few distributions do what we're doing
> anymore, precisely because of wanting to be secure by default.
>
> Yes, I know some people want password authentication on as part of a
> bootstrapping process. Fine... those users know to put it on. Let's
> not leave our users open to attack by default though.
>
> Happy to produce a patch and change the documentation, but I'd like to
> hear that we have consensus to make this change. But we should, because
> otherwise else I think we're going to hurt users.

I think most ideal would be if the user is asked the following two
questions, with a short explanation of what each means:

- Allow root login via SSH?

- Allow password authentication in SSH?

(I think Debian does this.)

Because as you say, on one hand password authentication in SSH can be a
security risk. But on the other hand many machines never have their SSH
port exposed to the Internet, and the intranet is assumed to be safe.
In those cases it would be an annoyance to have to enable it manually.

Both points apply to direct root login as well I think.

Allowing password authentication but disabling root login might also be
considered safe enough on machines exposed to the Internet, because the
attacker needs to guess the username as well. Only presents a small
increase in complexity for the attacker though.


- Taylan
R
R
raingloom wrote on 23 Nov 2020 04:46
(address . bug-guix@gnu.org)
20201123044615.13cc0898@riseup.net
On Mon, 23 Nov 2020 03:32:08 +0100
Taylan Kammer <taylan.kammer@gmail.com> wrote:

Toggle quote (50 lines)
> On 23.11.2020 00:20, Christopher Lemmer Webber wrote:
> > Okay, I just realized I left a friend vulnerable by guiding them
> > through a Guix graphical install and telling them it would give
> > them a decent setup. They turned on openssh support.
> >
> > Then I realized their config had password-authentication? on.
> >
> > That's unacceptable. We need to change this default. This is
> > known to leave users open to attack, and selecting a password
> > secure enough against brute forcing is fairly difficult, much more
> > difficult than only allowing entry by keys. Plus, few
> > distributions do what we're doing anymore, precisely because of
> > wanting to be secure by default.
> >
> > Yes, I know some people want password authentication on as part of a
> > bootstrapping process. Fine... those users know to put it on.
> > Let's not leave our users open to attack by default though.
> >
> > Happy to produce a patch and change the documentation, but I'd like
> > to hear that we have consensus to make this change. But we should,
> > because otherwise else I think we're going to hurt users.
>
> I think most ideal would be if the user is asked the following two
> questions, with a short explanation of what each means:
>
> - Allow root login via SSH?
>
> - Allow password authentication in SSH?
>
> (I think Debian does this.)
>
> Because as you say, on one hand password authentication in SSH can be
> a security risk. But on the other hand many machines never have
> their SSH port exposed to the Internet, and the intranet is assumed
> to be safe. In those cases it would be an annoyance to have to enable
> it manually.
>
> Both points apply to direct root login as well I think.
>
> Allowing password authentication but disabling root login might also
> be considered safe enough on machines exposed to the Internet,
> because the attacker needs to guess the username as well. Only
> presents a small increase in complexity for the attacker though.
>
>
> - Taylan
>
>
>

Most people won't know why allowing password authentication is
unsecure. Either it should be worded differently, have a warning, or
not be an option.

Same goes doubly so for allowing root login.
C
C
Carlo Zancanaro wrote on 23 Nov 2020 04:57
(name . Christopher Lemmer Webber)(address . cwebber@dustycloud.org)(address . 44808@debbugs.gnu.org)
874klgybbs.fsf@zancanaro.id.au
Hey Chris!

On Mon, Nov 23 2020, Christopher Lemmer Webber wrote:
Toggle quote (3 lines)
> ... Plus, few distributions do what we're doing anymore,
> precisely because of wanting to be secure by default.

Is this true? Debian defaults to passwords being allowed. I think
it even allows root login by default. At least, I have always had
to add "PermitRootLogin no" and "PasswordAuthentication no"
whenever I install openssh-server on debian.

I'm on board with what you're proposing, and I think Guix should
default to the more secure option, but I'm not sure that an
"average user" (whatever that means for Guix's demographic) would
expect that password authentication is disabled by default.

Carlo
C
C
Christopher Lemmer Webber wrote on 23 Nov 2020 17:15
(name . raingloom)(address . raingloom@riseup.net)
87r1ok2go9.fsf@dustycloud.org
raingloom writes:

Toggle quote (59 lines)
> On Mon, 23 Nov 2020 03:32:08 +0100
> Taylan Kammer <taylan.kammer@gmail.com> wrote:
>
>> On 23.11.2020 00:20, Christopher Lemmer Webber wrote:
>> > Okay, I just realized I left a friend vulnerable by guiding them
>> > through a Guix graphical install and telling them it would give
>> > them a decent setup. They turned on openssh support.
>> >
>> > Then I realized their config had password-authentication? on.
>> >
>> > That's unacceptable. We need to change this default. This is
>> > known to leave users open to attack, and selecting a password
>> > secure enough against brute forcing is fairly difficult, much more
>> > difficult than only allowing entry by keys. Plus, few
>> > distributions do what we're doing anymore, precisely because of
>> > wanting to be secure by default.
>> >
>> > Yes, I know some people want password authentication on as part of a
>> > bootstrapping process. Fine... those users know to put it on.
>> > Let's not leave our users open to attack by default though.
>> >
>> > Happy to produce a patch and change the documentation, but I'd like
>> > to hear that we have consensus to make this change. But we should,
>> > because otherwise else I think we're going to hurt users.
>>
>> I think most ideal would be if the user is asked the following two
>> questions, with a short explanation of what each means:
>>
>> - Allow root login via SSH?
>>
>> - Allow password authentication in SSH?
>>
>> (I think Debian does this.)
>>
>> Because as you say, on one hand password authentication in SSH can be
>> a security risk. But on the other hand many machines never have
>> their SSH port exposed to the Internet, and the intranet is assumed
>> to be safe. In those cases it would be an annoyance to have to enable
>> it manually.
>>
>> Both points apply to direct root login as well I think.
>>
>> Allowing password authentication but disabling root login might also
>> be considered safe enough on machines exposed to the Internet,
>> because the attacker needs to guess the username as well. Only
>> presents a small increase in complexity for the attacker though.
>>
>>
>> - Taylan
>>
>>
>>
>
> Most people won't know why allowing password authentication is
> unsecure. Either it should be worded differently, have a warning, or
> not be an option.
>
> Same goes doubly so for allowing root login.

Agreed on both counts.
C
C
Christopher Lemmer Webber wrote on 23 Nov 2020 17:17
(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)(address . 44808@debbugs.gnu.org)
87im9w2gjt.fsf@dustycloud.org
Carlo Zancanaro writes:

Toggle quote (11 lines)
> Hey Chris!
>
> On Mon, Nov 23 2020, Christopher Lemmer Webber wrote:
>> ... Plus, few distributions do what we're doing anymore, precisely
>> because of wanting to be secure by default.
>
> Is this true? Debian defaults to passwords being allowed. I think it
> even allows root login by default. At least, I have always had to add
> "PermitRootLogin no" and "PasswordAuthentication no" whenever I
> install openssh-server on debian.

Perhaps I'm wrong... I had thought that the last time I installed a
Debian server, password based access was off by default. But I could be
wrong.

Toggle quote (5 lines)
> I'm on board with what you're proposing, and I think Guix should
> default to the more secure option, but I'm not sure that an
> "average user" (whatever that means for Guix's demographic) would
> expect that password authentication is disabled by default.

That's fair... I think that
"[ ] Password authentication? (insecure)"
would be sufficient as an option. How do others feel?
M
M
Maxim Cournoyer wrote on 30 Nov 2020 04:58
(name . Christopher Lemmer Webber)(address . cwebber@dustycloud.org)
87im9nmr5u.fsf@gmail.com
Hello,

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

Toggle quote (17 lines)
> Carlo Zancanaro writes:
>
>> Hey Chris!
>>
>> On Mon, Nov 23 2020, Christopher Lemmer Webber wrote:
>>> ... Plus, few distributions do what we're doing anymore, precisely
>>> because of wanting to be secure by default.
>>
>> Is this true? Debian defaults to passwords being allowed. I think it
>> even allows root login by default. At least, I have always had to add
>> "PermitRootLogin no" and "PasswordAuthentication no" whenever I
>> install openssh-server on debian.
>
> Perhaps I'm wrong... I had thought that the last time I installed a
> Debian server, password based access was off by default. But I could be
> wrong.

I just tried with a Debian Buster VM; password access is enabled out of
the box.

Toggle quote (9 lines)
>> I'm on board with what you're proposing, and I think Guix should
>> default to the more secure option, but I'm not sure that an
>> "average user" (whatever that means for Guix's demographic) would
>> expect that password authentication is disabled by default.
>
> That's fair... I think that
> "[ ] Password authentication? (insecure)"
> would be sufficient as an option. How do others feel?

I'm +1 on disabling password access out of the box; especially since
Guix System makes it easy to authorize SSH keys at installation time.
We'd have to see if it breaks any of our system tests, but I doubt so.

Patch welcome!

Maxim
L
L
Ludovic Courtès wrote on 3 Dec 2020 18:05
control message for bug #44808
(address . control@debbugs.gnu.org)
875z5iddlo.fsf@gnu.org
tags 44808 + security
quit
L
L
Ludovic Courtès wrote on 5 Dec 2020 16:14
Re: bug#44808: Default to allowing password authentication on leaves users vulnerable
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87eek45lpg.fsf@gnu.org
Hi!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

Toggle quote (13 lines)
>>> I'm on board with what you're proposing, and I think Guix should
>>> default to the more secure option, but I'm not sure that an
>>> "average user" (whatever that means for Guix's demographic) would
>>> expect that password authentication is disabled by default.
>>
>> That's fair... I think that
>> "[ ] Password authentication? (insecure)"
>> would be sufficient as an option. How do others feel?
>
> I'm +1 on disabling password access out of the box; especially since
> Guix System makes it easy to authorize SSH keys at installation time.
> We'd have to see if it breaks any of our system tests, but I doubt so.

Agreed. There are several ways to do that:

1. Have the installer emit an ‘openssh-configuration’ that explicitly
disables password authentication.

2. Change the default value of the relevant field in
<openssh-configuration>.

#2 is more thorough but also more risky: people could find themselves
locked out of their server after reconfiguration, though this could be
mitigated by a news entry.

Thoughts?

Ludo’.
C
C
Christopher Lemmer Webber wrote on 5 Dec 2020 19:22
(name . Ludovic Courtès)(address . ludo@gnu.org)
87k0twkt9c.fsf@dustycloud.org
Ludovic Courtès writes:

Toggle quote (33 lines)
> Hi!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>>>> I'm on board with what you're proposing, and I think Guix should
>>>> default to the more secure option, but I'm not sure that an
>>>> "average user" (whatever that means for Guix's demographic) would
>>>> expect that password authentication is disabled by default.
>>>
>>> That's fair... I think that
>>> "[ ] Password authentication? (insecure)"
>>> would be sufficient as an option. How do others feel?
>>
>> I'm +1 on disabling password access out of the box; especially since
>> Guix System makes it easy to authorize SSH keys at installation time.
>> We'd have to see if it breaks any of our system tests, but I doubt so.
>
> Agreed. There are several ways to do that:
>
> 1. Have the installer emit an ‘openssh-configuration’ that explicitly
> disables password authentication.
>
> 2. Change the default value of the relevant field in
> <openssh-configuration>.
>
> #2 is more thorough but also more risky: people could find themselves
> locked out of their server after reconfiguration, though this could be
> mitigated by a news entry.
>
> Thoughts?
>
> Ludo’.

We could also do a combination of the above, as a transitional plan:
do #1 for now, but try to advertise that in the future, the default will
be changing... please explicitly set password access to #t if you need
this! Then in the *following* release, change the default.

This seems like a reasonable transition plan, kind of akin to a
deprecation process?
L
L
Ludovic Courtès wrote on 7 Dec 2020 12:51
(name . Christopher Lemmer Webber)(address . cwebber@dustycloud.org)
87sg8hzvdx.fsf@gnu.org
Hi Chris,

Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:

Toggle quote (2 lines)
> Ludovic Courtès writes:

[...]

Toggle quote (24 lines)
>> Agreed. There are several ways to do that:
>>
>> 1. Have the installer emit an ‘openssh-configuration’ that explicitly
>> disables password authentication.
>>
>> 2. Change the default value of the relevant field in
>> <openssh-configuration>.
>>
>> #2 is more thorough but also more risky: people could find themselves
>> locked out of their server after reconfiguration, though this could be
>> mitigated by a news entry.
>>
>> Thoughts?
>>
>> Ludo’.
>
> We could also do a combination of the above, as a transitional plan:
> do #1 for now, but try to advertise that in the future, the default will
> be changing... please explicitly set password access to #t if you need
> this! Then in the *following* release, change the default.
>
> This seems like a reasonable transition plan, kind of akin to a
> deprecation process?

Sounds like a plan. I went ahead and pushed
aecd2a13cbd8301d0fdeafcacbf69e12cc3f6138 which does this.

Thanks,
Ludo’.
D
D
Dr. Arne Babenhauserheide wrote on 7 Dec 2020 13:56
(name . Ludovic Courtès)(address . ludo@gnu.org)
87a6upepwb.fsf@web.de
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (6 lines)
>>> #2 is more thorough but also more risky: people could find themselves
>>> locked out of their server after reconfiguration, though this could be
>>> mitigated by a news entry.
>>>
>>> Thoughts?

My thoughts are that there is no mitigation for being locked out of a
pre-existing server. Keep in mind that that server might not actually be
accessible in any other way — it might be with a cheap hoster whose
support is practically non-existent, or it might be in a sealed
measurement container that can only be accessed via SSH without
disassembly.

Toggle quote (5 lines)
>> We could also do a combination of the above, as a transitional plan:
>> do #1 for now, but try to advertise that in the future, the default will
>> be changing... please explicitly set password access to #t if you need
>> this! Then in the *following* release, change the default.

This sounds like trying to retroactively fixing a problem at the wrong
place: If the installer creates a configuration which prevents
password-authentication, there is no problem for new systems and new
users who need password-authentication will explicitly see in the
config, that they have to change it, otherwise it won’t work. All the
while old systems will keep working.

I do need to access my system via password+ssh from time to time,
because I don’t want to have a key that can access my system on a
presentation-laptop that (due to being moved regularly) is much less
secure than the fixed system. If someone gets access to the laptop and
compromises my keys, they can run much more efficient attacks against
its ssh-keys' password than the attacks people can use to attack ssh via
internet.

Changing a default (an invisible setting) in a way that prevents access
is a serious disruption.

In short: please don’t break running systems on update.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl/OJmUQHGFybmVfYmFi
QHdlYi5kZQAKCRAT741FJAPD61kDEADEZc98uVkPR+pFPUf9RotGAMeF6awBwa/z
q3cGIVrelsiJulny84BWiR2PEd3j7Xbx7pSNsc1PNfye+M+gDSh1OdUsnh1xNGmH
CMYUKabyEeUUq//N0IDqXtZ0221BsxSiBA5bDBQlZxTR4MzkgWaCAmFFNoSqo+la
TcRsbzntfF1L9xSj/rGF1Q7xQ5uIYMnl2nteBidwAATkRhIUjKwmC9E2zC84mtA0
1z2n1SaQLmfBWzqfwu5ZZMZ7mwZcT30qz2MT4SRcY0jpZ978U0VkPxQbczFIxTel
EX9tYK6w7B/DHt256isVdid4oaip8Ei2umfY/HfAwmKk4Hq6FJAYYpiQnMNOb48W
UWV8VWfOc+IrAuOYoXJHhFMSSNTyNhT853K7FVAw5QFlFQO71PCYesluKuhS7DN2
xLqIoMmEAiOHn5hbBkd3ZZUkJ2nzWq9JhhRuaSDJTR7HHNjfTtHV0q8yV3KBqJHd
XqiehMDeJnsuW101dqvGEZBv9bYo0HEN3Lmuj+izNg2el8A3K/8vUOx7KYPtbhqd
0Tqek/VndIAPsJ5zlKSAUn+o8myhgDuM5eaFFvQAH+WNMnqiIh+kdc+dfDpcoEyz
JK+ExDuk0oLP1wJN3ZCFhXStYQJfgGqughGhSpF0Xg6fECPHEcNVFj3lj7ome7nU
dF0OcWd1KIjEBAEBCAAuFiEE3Si95tmHXKvOSosd3M8NswvBBUgFAl/OJmUQHGFy
bmVfYmFiQHdlYi5kZQAKCRDczw2zC8EFSAWmBACdm9rbbnnRsGmmixzxC0v0uSQe
apSAtCACFlLWreldBYHXj1VaHOuDFikEt+a4nL5B0l4XA398NMIy9TIPA2RdAotJ
dfKAYiKDCZ91aXpF+P2z6WCmzpLPQkRb9QlOWeN7y/pILtrEA6wYGL1mxNsXfmWK
QmQLZpWxRbx0CZ4Yeg==
=XUep
-----END PGP SIGNATURE-----

C
C
Christopher Lemmer Webber wrote on 7 Dec 2020 17:48
(name . Dr. Arne Babenhauserheide)(address . arne_bab@web.de)
87sg8hlfyu.fsf@dustycloud.org
Dr. Arne Babenhauserheide writes:

Toggle quote (43 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>
>>>> #2 is more thorough but also more risky: people could find themselves
>>>> locked out of their server after reconfiguration, though this could be
>>>> mitigated by a news entry.
>>>>
>>>> Thoughts?
>
> My thoughts are that there is no mitigation for being locked out of a
> pre-existing server. Keep in mind that that server might not actually be
> accessible in any other way — it might be with a cheap hoster whose
> support is practically non-existent, or it might be in a sealed
> measurement container that can only be accessed via SSH without
> disassembly.
>
>>> We could also do a combination of the above, as a transitional plan:
>>> do #1 for now, but try to advertise that in the future, the default will
>>> be changing... please explicitly set password access to #t if you need
>>> this! Then in the *following* release, change the default.
>
> This sounds like trying to retroactively fixing a problem at the wrong
> place: If the installer creates a configuration which prevents
> password-authentication, there is no problem for new systems and new
> users who need password-authentication will explicitly see in the
> config, that they have to change it, otherwise it won’t work. All the
> while old systems will keep working.
>
> I do need to access my system via password+ssh from time to time,
> because I don’t want to have a key that can access my system on a
> presentation-laptop that (due to being moved regularly) is much less
> secure than the fixed system. If someone gets access to the laptop and
> compromises my keys, they can run much more efficient attacks against
> its ssh-keys' password than the attacks people can use to attack ssh via
> internet.
>
> Changing a default (an invisible setting) in a way that prevents access
> is a serious disruption.
>
> In short: please don’t break running systems on update.
>
> Best wishes,
> Arne

It's a serious concern. We are left in a tough bind: leave users with
an insecure default but try to inform them as much as we can of a
changing default, or possibly lock them out if they don't notice.

Still, now feels like to me the ideal time to do it. The number of
people running GuixSD on servers is comparatively small. I expect that
to change. It would be better to make this change sooner than later.

I understand your concern though...
L
L
Leo Famulari wrote on 7 Dec 2020 20:40
(name . Christopher Lemmer Webber)(address . cwebber@dustycloud.org)
X86FH7Mt3353VRGL@jasmine.lan
On Sat, Dec 05, 2020 at 01:22:23PM -0500, Christopher Lemmer Webber wrote:
Toggle quote (7 lines)
> > 2. Change the default value of the relevant field in
> > <openssh-configuration>.
> >
> > #2 is more thorough but also more risky: people could find themselves
> > locked out of their server after reconfiguration, though this could be
> > mitigated by a news entry.

I do think we should avoid changing the default. I know that passphrases
are inherently riskier than keys — compromise is more likely than with a
key, but I think it's even more likely that people will lose access to
their servers if we change this default.

How bad is the risk, from a practical perspective? How many times per
second can a remote attacker attempt passphrase authentication? If the
number is high, we could petition OpenSSH to introduce a delay.
D
D
Dr. Arne Babenhauserheide wrote on 7 Dec 2020 20:53
(name . Christopher Lemmer Webber)(address . cwebber@dustycloud.org)
871rg1e6js.fsf@web.de
Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

Toggle quote (53 lines)
> Dr. Arne Babenhauserheide writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>>>> #2 is more thorough but also more risky: people could find themselves
>>>>> locked out of their server after reconfiguration, though this could be
>>>>> mitigated by a news entry.
>>>>>
>>>>> Thoughts?
>>
>> My thoughts are that there is no mitigation for being locked out of a
>> pre-existing server. Keep in mind that that server might not actually be
>> accessible in any other way — it might be with a cheap hoster whose
>> support is practically non-existent, or it might be in a sealed
>> measurement container that can only be accessed via SSH without
>> disassembly.
>>
>>>> We could also do a combination of the above, as a transitional plan:
>>>> do #1 for now, but try to advertise that in the future, the default will
>>>> be changing... please explicitly set password access to #t if you need
>>>> this! Then in the *following* release, change the default.
>>
>> This sounds like trying to retroactively fixing a problem at the wrong
>> place: If the installer creates a configuration which prevents
>> password-authentication, there is no problem for new systems and new
>> users who need password-authentication will explicitly see in the
>> config, that they have to change it, otherwise it won’t work. All the
>> while old systems will keep working.
>>
>> I do need to access my system via password+ssh from time to time,
>> because I don’t want to have a key that can access my system on a
>> presentation-laptop that (due to being moved regularly) is much less
>> secure than the fixed system. If someone gets access to the laptop and
>> compromises my keys, they can run much more efficient attacks against
>> its ssh-keys' password than the attacks people can use to attack ssh via
>> internet.
>>
>> Changing a default (an invisible setting) in a way that prevents access
>> is a serious disruption.
>>
>> In short: please don’t break running systems on update.
>>
>> Best wishes,
>> Arne
>
> It's a serious concern. We are left in a tough bind: leave users with
> an insecure default but try to inform them as much as we can of a
> changing default, or possibly lock them out if they don't notice.
>
> Still, now feels like to me the ideal time to do it. The number of
> people running GuixSD on servers is comparatively small. I expect that
> to change. It would be better to make this change sooner than later.

If the installer and the configuration examples are changed now, then
the number of people who unknowingly run Guix on an insecure
configuration should not rise.

To nudge them to secure their system, guix system reconfigure could emit
a warning that this is a potential security risk that requires setting
an explicit value (password yes or no) to silence.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl/OiFgQHGFybmVfYmFi
QHdlYi5kZQAKCRAT741FJAPD64uSEADMFUmtHqD0E5RLG1y3Fk8liw3awm/IeXQc
iT/dtdk+1+GmQJ2QMdt180dWjz77UJratQoNxbH0iSILVYV38a+rNONxLU/t60pX
I5ye0ID/Ts9K2a2Ih+7ASP6ElD3uPlJcCud5QoDE6LX7bUrWm1310FJTz6NbJEz1
Xiv1x4xl/cMdtVSa1OEeJ2E7mrxIs2dGtSKQ0uPdZsYeKX8M6KovSxB+MyV2TLIH
AtIwZDaKJH5N/nJi3u5XAtzRf6rFcwjoDoKPicKIMmKLzCW6M8kMLngCb6AXxZf5
/P/tV+oXpOP7GN8WS4w2ScP/yph0bibP9hbj0viKDTX4YrXKYgZT9RcAD4k+tykO
CgPVGEpbMw3f/Ah/0Xi+7zkWDJSxu7FUIPlTDiGGbDetnVKtw/yXeKgSwjBCeZVL
51AEk72KzAQvELS2Gg2yyJzyI03sZzdCbO6dsqWCbdiFdrlWvPIOyZlnOavijXVA
QFNKJ7NtM9hu15yitaH3Lk01MOMc1UdUEmnVyTJu2i77xJr6M0OfxiL3v/dAVgKw
qteyerPrMkelQ/J8q7pNPCQirL6nXi20rfaahX/1DKSOOnE6E9tXPzyHLfzZ1ZcI
AA8KrFnXr8SxLX9LqbMwEpRmZXz4ZaSu5U0b1Lto5/BfTUDbjcY8zkGgyapz3jVV
QpMRDrQdlojEBAEBCAAuFiEE3Si95tmHXKvOSosd3M8NswvBBUgFAl/OiFgQHGFy
bmVfYmFiQHdlYi5kZQAKCRDczw2zC8EFSJ9PA/9M0egTZgXt4RBUsE4pGZliYY3z
B1FL1IuEw/YFpmf53NVxqQxFrAZM1N1W/RZ5x/1cAXiEg2M4gYTDSf/ff+Mfprxd
tNeAqy0P4wPjUv/RjAWMxzOqlp6wZvNt7lLvEu1xxjy3Dd1lUW9h/+NiCEx+CiIf
/S9SDL0leN17AngDAw==
=I42Q
-----END PGP SIGNATURE-----

C
C
Christopher Lemmer Webber wrote on 7 Dec 2020 22:38
(name . Leo Famulari)(address . leo@famulari.name)
87eek1fg9u.fsf@dustycloud.org
Leo Famulari writes:

Toggle quote (17 lines)
> On Sat, Dec 05, 2020 at 01:22:23PM -0500, Christopher Lemmer Webber wrote:
>> > 2. Change the default value of the relevant field in
>> > <openssh-configuration>.
>> >
>> > #2 is more thorough but also more risky: people could find themselves
>> > locked out of their server after reconfiguration, though this could be
>> > mitigated by a news entry.
>
> I do think we should avoid changing the default. I know that passphrases
> are inherently riskier than keys — compromise is more likely than with a
> key, but I think it's even more likely that people will lose access to
> their servers if we change this default.
>
> How bad is the risk, from a practical perspective? How many times per
> second can a remote attacker attempt passphrase authentication? If the
> number is high, we could petition OpenSSH to introduce a delay.

Some servers try to protect against such systems with something such as
fail2ban. It can help a little, but origin-oriented systems have
serious problems. A simple example is that a botnet can be used to try
logging in from many origins. But origin-oriented designs also don't
hold up in general as one tends to move towards things like p2p
systems... consider if exposing ssh over a tor onion service just how
easy it is to generate lots of onion addresses.

Consider the following though: most users have fairly weak passwords.
Sad, but true... but in the case where that password only is affected by
someone trying to gain login from physical access, it also only affects
physical access brute forcing with the computer on.

A weak password doesn't hold up as well when any server anywhere can
start hammering on it.

Looking at my auth logs, such hammering is super common... most of the
servers I've dealt with tend to have logs filled with bots trying to get
in all the time, and that's in an untargeted case. A targeted case is
worse.

Maybe it's not a good idea to change the default, but yes, the problem
is serious.
M
M
Mark H Weaver wrote on 7 Dec 2020 23:57
87im9ddy0r.fsf@netris.org
Hi,

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
Toggle quote (4 lines)
> To nudge them to secure their system, guix system reconfigure could emit
> a warning that this is a potential security risk that requires setting
> an explicit value (password yes or no) to silence.

I think this is a good idea. Likewise, in the Guix installer, I would
favor asking the user whether or not to enable password authentication,
after warning them that it is a security risk.

I agree with Chris that password authentication is a significant
security risk, but I also worry that if we simply disable it, it will
catch some users by surprise and they may be quite unhappy about it.

Regards,
Mark
L
L
Ludovic Courtès wrote on 8 Dec 2020 11:36
(name . Mark H Weaver)(address . mhw@netris.org)
87wnxswpmk.fsf@gnu.org
Hi,

Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (13 lines)
> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>> To nudge them to secure their system, guix system reconfigure could emit
>> a warning that this is a potential security risk that requires setting
>> an explicit value (password yes or no) to silence.
>
> I think this is a good idea. Likewise, in the Guix installer, I would
> favor asking the user whether or not to enable password authentication,
> after warning them that it is a security risk.
>
> I agree with Chris that password authentication is a significant
> security risk, but I also worry that if we simply disable it, it will
> catch some users by surprise and they may be quite unhappy about it.

What do you think of the approach in

The default is unchanged but the warning could be kept say until the
next release, at which point we’d change the default.

Or are you suggesting keeping the default unchanged?

Ludo’.
C
C
Christopher Lemmer Webber wrote on 8 Dec 2020 14:48
(name . Mark H Weaver)(address . mhw@netris.org)
87ft4ge7d9.fsf@dustycloud.org
Mark H Weaver writes:

Toggle quote (18 lines)
> Hi,
>
> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>> To nudge them to secure their system, guix system reconfigure could emit
>> a warning that this is a potential security risk that requires setting
>> an explicit value (password yes or no) to silence.
>
> I think this is a good idea. Likewise, in the Guix installer, I would
> favor asking the user whether or not to enable password authentication,
> after warning them that it is a security risk.
>
> I agree with Chris that password authentication is a significant
> security risk, but I also worry that if we simply disable it, it will
> catch some users by surprise and they may be quite unhappy about it.
>
> Regards,
> Mark

It's clear that quite a few people are unhappy with switching the
default, fearing lockout. I'm fine with making the above compromise
given all that, personally.
M
M
Mark H Weaver wrote on 9 Dec 2020 02:31
(name . Ludovic Courtès)(address . ludo@gnu.org)
87lfe7ydc0.fsf@netris.org
Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (18 lines)
> Mark H Weaver <mhw@netris.org> skribis:
>
>> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>>> To nudge them to secure their system, guix system reconfigure could emit
>>> a warning that this is a potential security risk that requires setting
>>> an explicit value (password yes or no) to silence.
>>
>> I think this is a good idea. Likewise, in the Guix installer, I would
>> favor asking the user whether or not to enable password authentication,
>> after warning them that it is a security risk.
>>
>> I agree with Chris that password authentication is a significant
>> security risk, but I also worry that if we simply disable it, it will
>> catch some users by surprise and they may be quite unhappy about it.
>
> What do you think of the approach in
> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=aecd2a13cbd8301d0fdeafcacbf69e12cc3f6138>?

One problem, which I just discovered, is that it warns users even if
they don't have an 'openssh-service' in their system configuration.
(For that reason, I just reverted this commit on my private branch).

Toggle quote (5 lines)
> The default is unchanged but the warning could be kept say until the
> next release, at which point we’d change the default.
>
> Or are you suggesting keeping the default unchanged?

I don't feel strongly about what the default setting should be, as long
as we ensure that users are somehow made aware of the change before it
happens, and are given the opportunity (and preferably easy instructions
on how) to keep password authentication enabled if they wish.

I also think that the installer should explicitly ask the user what the
setting should be, so that we do not catch new users off guard who
expected to be able to ssh in to their newly-installed systems using
only a password.

If the plan is to change the default setting and issue warnings in the
meantime, it should be easy to silence those warnings, especially for
those of us who don't even use openssh-service :)

What do you think?

Regards,
Mark
L
L
Ludovic Courtès wrote on 10 Dec 2020 09:17
(name . Mark H Weaver)(address . mhw@netris.org)
87o8j29isw.fsf@gnu.org
Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (2 lines)
> Ludovic Courtès <ludo@gnu.org> writes:

[...]

Toggle quote (6 lines)
>> What do you think of the approach in
>> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=aecd2a13cbd8301d0fdeafcacbf69e12cc3f6138>?
>
> One problem, which I just discovered, is that it warns users even if
> they don't have an 'openssh-service' in their system configuration.

Could it be that you have a childhurd or some other service that uses
‘openssh-service-type’? What source code location is associated with
that warning?

Toggle quote (15 lines)
>> The default is unchanged but the warning could be kept say until the
>> next release, at which point we’d change the default.
>>
>> Or are you suggesting keeping the default unchanged?
>
> I don't feel strongly about what the default setting should be, as long
> as we ensure that users are somehow made aware of the change before it
> happens, and are given the opportunity (and preferably easy instructions
> on how) to keep password authentication enabled if they wish.
>
> I also think that the installer should explicitly ask the user what the
> setting should be, so that we do not catch new users off guard who
> expected to be able to ssh in to their newly-installed systems using
> only a password.

Yeah, we can do that; it’s a bit of extra complexity in the installer,
but perhaps that’ll be useful to configure other services as well.

Toggle quote (4 lines)
> If the plan is to change the default setting and issue warnings in the
> meantime, it should be easy to silence those warnings, especially for
> those of us who don't even use openssh-service :)

Agreed. :-) Normally, if you explicitly set the field, the warning
disappears.

Thanks,
Ludo’.
M
M
Mark H Weaver wrote on 11 Dec 2020 02:43
(name . Ludovic Courtès)(address . ludo@gnu.org)
87pn3h15hv.fsf@netris.org
Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (15 lines)
> Mark H Weaver <mhw@netris.org> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>> What do you think of the approach in
>>> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=aecd2a13cbd8301d0fdeafcacbf69e12cc3f6138>?
>>
>> One problem, which I just discovered, is that it warns users even if
>> they don't have an 'openssh-service' in their system configuration.
>
> Could it be that you have a childhurd or some other service that uses
> ‘openssh-service-type’?

I highly doubt it. In any case, there's certainly no ssh daemon
running. See below for my system configuration.

Toggle quote (2 lines)
> What source code location is associated with that warning?

Toggle snippet (7 lines)
mhw@jojen ~/guix$ ./pre-inst-env guix system build /etc/config.scm
gnu/services/ssh.scm:570:31: warning: The default value of the 'password-authentication?'
field of 'openssh-configuration' will change from #true to #false in the
future. Explicitly set it to #true to allow password authentication.
/gnu/store/v9ri5ya4xb1fxnmckg1j1qr2qki73w36-system

Could it be related to the fact that I always run Guix via
./pre-inst-env from a git checkout?

If this problem only affect me, due to the unusual way in which I use
Guix, feel free to disregard this issue. It's easy enough for me add
one more to my collection of reverted patches on my private branch :)

Thanks,
Mark


Toggle snippet (153 lines)
(use-modules (gnu) (gnu system nss) (srfi srfi-1) (guix packages))
(use-service-modules base desktop networking xorg dbus sound)
(use-package-modules certs gnome cryptsetup linux admin guile firmware xdisorg libusb suckless ratpoison wm vpn)

(operating-system
(host-name "jojen")
(timezone "right/US/Eastern")
(locale "en_US.utf8")

(bootloader (bootloader-configuration
(bootloader grub-bootloader)
(target "/dev/sda")))

(kernel linux-libre)
(kernel-arguments '("page_alloc.shuffle=1"))

(firmware (list ath9k-htc-firmware))
;;(firmware '())

(keyboard-layout (keyboard-layout "us" #:options '("ctrl:nocaps")))

;; Specify a mapped device for the encrypted root partition.
;; The UUID is that returned by 'cryptsetup luksUUID'.
(mapped-devices
(list (mapped-device
(source (uuid "a56c53e7-b345-4e24-a17b-6cf158dbc7d3"))
(target "jojen-root")
(type luks-device-mapping))))

(file-systems (cons* (file-system
;; FIXME: reference by the file system label?
(device "/dev/mapper/jojen-root")
(mount-point "/")
(type "btrfs")
(dependencies mapped-devices))
%base-file-systems))

(users (cons* (user-account
(name "mhw")
(uid 1000)
(group "mhw")
(supplementary-groups '("wheel" "users" "netdev"
"audio" "video" "dialout"))
(home-directory "/home/mhw"))
%base-user-accounts))

(groups (cons* (user-group
(name "mhw")
(id 1000))
%base-groups))

(setuid-programs
(list (file-append shadow "/bin/passwd")
(file-append inetutils "/bin/ping")))

;; This is where we specify system-wide packages.
(packages (cons* nss-certs ;for HTTPS access
gvfs ;for user mounts
cryptsetup
btrfs-progs
wpa-supplicant
network-manager
network-manager-applet
network-manager-openvpn
openvpn
ratpoison
i3-wm
dwm
(delete sudo %base-packages)))

(services (cons* (service gnome-desktop-service-type)
;;(service xfce-desktop-service-type)

(service gdm-service-type)
;;(service slim-service-type)
(screen-locker-service slock)
;;(screen-locker-service xlockmore "xlock")

;; Add udev rules for MTP devices so that non-root
;; users can access them.
(simple-service 'mtp udev-service-type (list libmtp))
;; Add udev rules for scanners.
(service sane-service-type)
;; Add polkit rules, so that non-root users in the
;; wheel group can perform administrative tasks
;; (similar to "sudo").
polkit-wheel-service

;; NetworkManager and its dependents.
(service network-manager-service-type)
(service wpa-supplicant-service-type)
;; (simple-service 'network-manager-applet
;; profile-service-type
;; (list network-manager-applet))
;; (service modem-manager-service-type)
;; (service usb-modeswitch-service-type)

;; The D-Bus clique.
;;(service avahi-service-type) ; I don't trust this
(udisks-service)
(service upower-service-type)
;;(accountsservice-service)
;;(service cups-pk-helper-service-type)
(service colord-service-type)
;;(geoclue-service) ; I don't want this
(service polkit-service-type)
(elogind-service)
(dbus-service)

;;(service ntp-service-type) ; I don't trust this

(service pulseaudio-service-type)
(service alsa-service-type)

;;;; Disabled for now
;;
;;(accountsservice-service)
;;(service cups-pk-helper-service-type)

;; TOR: The Onion Router
(service tor-service-type)

;; Optional OpenNTPd, below
#;
(service
openntpd-service-type
(openntpd-configuration
(listen-on '("127.0.0.1" "::1"))
;;(constraint-from '("www.gnu.org"))
(allow-large-adjustment? #t)))

x11-socket-directory-service

;;;; Disabled for now
;;
;;(service alsa-service-type)

(modify-services %base-services
;; I don't trust the build farm
(guix-service-type config =>
(guix-configuration
(inherit config)
(use-substitutes? #f)
(authorize-key? #f)
(authorized-keys '())
(substitute-urls '())
(extra-options '("--gc-keep-derivations=yes"
"--gc-keep-outputs=yes")))))))

;; Allow resolution of '.local' host names with mDNS.
;;(name-service-switch %mdns-host-lookup-nss) ; disabled for now
)
L
L
Ludovic Courtès wrote on 11 Dec 2020 19:10
(name . Mark H Weaver)(address . mhw@netris.org)
87eejw43k5.fsf@gnu.org
Hi,

Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (12 lines)
> gnu/services/ssh.scm:570:31, here:
>
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/ssh.scm?id=ec2eccbf3d1a6378c5ebf1e3d17ec72b4b2a4cd0#n570
>
> Here's what I see when I build a system:
>
> mhw@jojen ~/guix$ ./pre-inst-env guix system build /etc/config.scm
> gnu/services/ssh.scm:570:31: warning: The default value of the 'password-authentication?'
> field of 'openssh-configuration' will change from #true to #false in the
> future. Explicitly set it to #true to allow password authentication.
> /gnu/store/v9ri5ya4xb1fxnmckg1j1qr2qki73w36-system

I ended up reverting it in d8051557aee9fa252b015ff67cc15681e8540777
because it affects everyone, I couldn’t think of an easy way to address
that while still getting the warning when we want it, and it seems we
may have to discuss the issue a bit more (apologies for assuming we had
reached a consensus!).

Thanks,
Ludo’.
R
R
raid5atemyhomework wrote on 11 Feb 2021 08:46
Re: Default to allowing password authentication on leaves users vulnerable
(name . 44808@debbugs.gnu.org)(address . 44808@debbugs.gnu.org)
K_X9HqOU5KF89CVy-1kOJsxdnvm7QeBDtaYfHhbLhdlHUd4c-ZyvjgDKhTIb7gcYH2-On0ritgjJiZvnZ-QttsFMM9zaPwpKPjNyeKEcdUw=@protonmail.com
Hi guix users,

It strikes me that a better course of action here would be, rather than providing a warning that might not be noticed by the user, to remove the default and force people to explicitly put `password-authentication? #t` or `password-authentication? #f`.

That way if I have set up a headless server (possibly having a temporary keyboard/mouse/monitor during initial install, then forever logging in afterwards over intranet using my super secret password "raid5isnotagooddog"), with an existing `configuration.scm` that does not explicitly give the setting, I cannot accidentally lose access to my headless server by doing a random `guix pull && sudo guix system reconfigure configuration.scm` without noticing the warning.

Especially since there exists an `unattended-upgrades-service-type` which automates this `guix pull && sudo guix system reconfigure configuration.scm`, which makes changing this default ***VERY DANGEROUS*** in this use-case. I'd rather I noticeably error out in this case.

Then later after a year give a "sane" default, after people who have depended on the existing `password-authentication? #t` have already explicitly put the setting in their `configuration.scm`.

Thanks
raid5atemyhomework
L
L
Leo Famulari wrote on 11 Feb 2021 21:36
Re: bug#44808: Default to allowing password authentication on leaves users vulnerable
(name . raid5atemyhomework via Bug reports for GNU Guix)(address . bug-guix@gnu.org)(name . 44808@debbugs.gnu.org)(address . 44808@debbugs.gnu.org)
YCWVQRdK5U3OZxBV@jasmine.lan
On Thu, Feb 11, 2021 at 07:46:51AM +0000, raid5atemyhomework via Bug reports for GNU Guix wrote:
Toggle quote (4 lines)
> Hi guix users,
>
> It strikes me that a better course of action here would be, rather than providing a warning that might not be noticed by the user, to remove the default and force people to explicitly put `password-authentication? #t` or `password-authentication? #f`.

I like this idea.

Toggle quote (5 lines)
>
> That way if I have set up a headless server (possibly having a temporary keyboard/mouse/monitor during initial install, then forever logging in afterwards over intranet using my super secret password "raid5isnotagooddog"), with an existing `configuration.scm` that does not explicitly give the setting, I cannot accidentally lose access to my headless server by doing a random `guix pull && sudo guix system reconfigure configuration.scm` without noticing the warning.
>
> Especially since there exists an `unattended-upgrades-service-type` which automates this `guix pull && sudo guix system reconfigure configuration.scm`, which makes changing this default ***VERY DANGEROUS*** in this use-case. I'd rather I noticeably error out in this case.

I agree, changing the default will cause problems, and I'm not convinced
it's a serious problem that warrants changing anyways.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 44808@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 44808
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch