Code review comment for lp:~vorlon/debian-cd/lp.1576353

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.