Merge lp:~vorlon/debian-cd/lp.1576353 into lp:~ubuntu-cdimage/debian-cd/ubun3

[Steve Langasek]

[Dimitri John Ledkov (xnox)]

How do we preseed this into netboot/base-installer d-i? and should we?

or is it ok to install openssh with password auth enabled by default in d-i case?

Also if one is using netconsole, it should toggle this back to yes? as during netconsole stage we only setup password auth.

[Dimitri John Ledkov (xnox)]

Talked to steve about things.
I think it is ok to leave netboot installs without a default pressed, and document that people need to add more keys to the pressed to get the desired behaviour there similar to a full server iso.

[Dimitri John Ledkov (xnox)]

I have tested this by installing amd64 d-i server iso, and selecting ssh task. First i did this with a pristine cosmic d-i server iso, and then again with a locally re-rolled iso with the proposed change to the preseed applied to it.

The original iso allowed password login, the re-rolled one did not. After generating and authorizing an ssh-key, I was able to ssh in. Thus key only authentication was setup correctly.

Please merge this change.

review: Approve

[Adam Conrad (adconrad)]

I had meant to circle around with the security team about if and why they even think this is necessary. We already restrict root password auth by virtue of disabling the root account entirely. We certainly don't disable user password auth by default, but I'm not convinced we want to either. "Please log in to your new machine with an SSH key you haven't configured on it yet using a password you aren't allowed to use" isn't the best UX.

And, of course, my biggest complaint about this is that the experience won't be remotely consistent. If you install from an Ubuntu ISO, you get this behaviour? If you "install" in a cloud, maybe you get this too, *but* clouds in such a state will pretty much always push an ssh key on bringup. If you install a desktop machine, then install openssh, the behaviour will be different. If we think password auth is such a gaping hole, surely we'd have pushed to protect desktop users (the hypothetical "non-technical user") long before we worried about sysadmins installing servers?

[Steve Langasek (vorlon)]

On Wed, Oct 03, 2018 at 07:24:59PM -0000, Adam Conrad wrote:

> I had meant to circle around with the security team about if and why they
> even think this is necessary. We already restrict root password auth by
> virtue of disabling the root account entirely. We certainly don't disable
> user password auth by default, but I'm not convinced we want to either.
> "Please log in to your new machine with an SSH key you haven't configured
> on it yet using a password you aren't allowed to use" isn't the best UX.

> And, of course, my biggest complaint about this is that the experience
> won't be remotely consistent. If you install from an Ubuntu ISO, you get
> this behaviour? If you "install" in a cloud, maybe you get this too,
> *but* clouds in such a state will pretty much always push an ssh key on
> bringup. If you install a desktop machine, then install openssh, the
> behaviour will be different. If we think password auth is such a gaping
> hole, surely we'd have pushed to protect desktop users (the hypothetical
> "non-technical user") long before we worried about sysadmins installing
> servers?

It would be inconsistent in terms of the default behavior of the openssh
package varying depending on how and when you get that package. But it's
consistent in the sense of remote, password-based access to the computer
being opt-in.

I think the latter is a valuable sort of consistency as well.

If we had a d-i change to go with this that caused the 'ssh server' tasksel
option to change from passwords: no to passwords: yes via debconf, would
this allay your concerns? That would maintain consistency with existing
preseeds used against previous Ubuntu releases.

[Adam Conrad (adconrad)]

I mean, maybe adding even more complexity to it would help with keeping consistency with previous releases, but I'm still pretty unconvinced about the whole thing. Either we think password access is actively harmful, or we don't. If we think it's so dire, it shouldn't be as easy as "apt install ssh" on a desktop to open that up.

On the other hand, if "apt install ssh" should continue to do as it always has and we don't think that's a big deal (I don't), I don't see why a pre-installed ssh on a server should get special treatment. Yes, I get the concern about pre-installed in general, and the no-open-ports policy we've mostly managed to hang on to for 14 years, but if we're saying "people expect servers to have sshd" (probably a reasonable assumption these days), I'm not sure it follows that "people expect, and will know how to deal with, servers having ssh configured differently from their laptops."

[Dimitri John Ledkov (xnox)]

Case in point - it is expected that password auth is on; and sshd pre-installed; always on s390x - because its normal consoles are basic. Even with the proposed change here, this will stay the case.

The clouds - are all different, most do ssh-only, some do password only, and one ends up with whatever that specific cloud tells people to do usually.

lxd containers / self-downloaded cloud images - usually one has to inject/break into them, usually by means of ssh-import-id or metadata provided keys (and said metadata has toggles to enable password auth).

It almost feels like we want to bring ssh-import-id functionality to d-i, both interactive and pre-seedable. Because making key based auth by default, is awkward without allowing out-of-the-box adding ssh key.

It also feels like we want to pre-install sshd everywhere, and make it key only - and show d-i users a task called "Enable password based ssh login". And actually force a HIGH priority question asking them about enabling password based auth, with auto default No, if they did not preseed an ssh key.

I will double check, but imho subiquity should default to key only by default.

Desktop too, should default to keybased auth only. It is irresponsible to open up the system to `ubuntu:ubuntu` hacks, when one installs `ssh` instead of `openssh-client`.

On upgrades, we should obviously not change anything.

So i think it is time, to change the default in openssh package, and make it keybased auth by default. And then in d-i add ability to setup an ssh key; add an ability to enable password auth.

Because basically most of our products go out of their way to disable password auth way too many times. And indeed password auth should be something /harder/ to use than key based auth. If that is not the case, we have failed our users.

[Adam Conrad (adconrad)]

I don't disagree with most of xnox's points, except that I'll note there's a huge chicken-and-egg issue for anyone who doesn't have either an LP/git/whatever-we-integrate-with account to import an SSH ID from or an active internet connection (one of the more obvious use-cases for installing from an ISO in the first place).

If the only way to get a key on the system is to type it in by hand (lolz) or SSH in to the system post-install, it's a wonderful pain to discover you can't. Doubly-so if it was a headless system installed in a co-lo or something (note: not at all uncommon for co-lo providers to offer iLO booting of various distro ISOs to install machines).

With a critical prio debconf question (and equivalent machinery for subiquity) yelling about password auth and driving home the fact that, without it, you might be locked out of your new server and have to start all over again, I think I'd be okay with no-passwd-auth being the default everywhere. Maybe.

[Adam Conrad (adconrad)]

Regardless of which direction we go, I still fundamentally believe this MP is wrong, though. Changing the default for Server ISO installations, simply because sshd is installed by default, but not for desktops (or netinst, or, or) is non-sensical to me. We need to take a formal position on if we think password auth is or isn't "bad", and then act on it unilaterally, not pretend that "what happens during install" is somehow more important than "what happens 5 minutes after install when I manually install the exact same package".

[Marc Deslauriers (mdeslaur)]

While I do understand the desire to combine cloud and server images, I don't think this MP is the right approach.

The security team's position has always been that installing openssh should be opt-in, so that it is clear to the person performing the installation that ssh will be active, for the following reasons:

1- It uses password authentication by default, and it may not be obvious to someone installing a test server or a development VM that the weak password they chose at install time would expose it to attackers.
2- The openssh port will be open and vulnerable to any security issues before the proper security updates have been installed (this is part of the reasoning for our no open ports policy).

While enabling openssh by default but with password authentication disabled clearly solves #1, it does not solve #2, and comes with an important drawback: the chicken-and-egg problem of getting an ssh key to the box while a password can't be used. I think that drawback is important enough that changing the default will cause user irritation and affects openssh usability.

There is also the issue that this MP will result in a different behaviour between installing the ssh package on a desktop system and having it installed by default on a server. I believe this will cause confusion and is likely to again result in systems being exposed with insecure configurations. Having openssh installed by default on cloud images is different because it's generally the only way to access clouds, cloud installs are usually pre-configured, and there are IP limitations in place preventing arbitrary connections.

Most of these issues have been mentioned in the previous comments, but there doesn't seem to be an ideal solution that would pave the way forward.

For these reasons the security team wishes to NACK this MP and maintain the status quo of having the openssh package be an opt-in during server installation.

[Adam Conrad (adconrad)]

Based on my own opinions above, and the hard NACK from the security team, I'm declining this MP.

review: Disapprove

Unmerged revisions

1993. By Steve Langasek on 2018-06-16

Preseed disabling of password authentication for openssh.

This is a precondition of adding openssh-server to the server seed.

LP: #1576353

=== modified file 'data/cosmic/preseed/ubuntu-server/ubuntu-server.seed'
--- data/cosmic/preseed/ubuntu-server/ubuntu-server.seed	2018-05-02 21:44:19 +0000
+++ data/cosmic/preseed/ubuntu-server/ubuntu-server.seed	2018-06-16 00:37:48 +0000
@@ -18,3 +18,5 @@
 d-i	grub-installer/timeout	string 2
 # Add the network and tasks oem-config steps by default.
 oem-config	oem-config/steps	multiselect language, timezone, keyboard, user, network, tasks
+# for openssh to be included by default in the seed, must disable password auth by default
+openssh-server	openssh-server/password-authentication	boolean false