Install openssh-server with disabled password auth by default on servers

Bug #1576353 reported by Scott Moser on 2016-04-28
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu CD Images
Undecided
Unassigned
livecd-rootfs (Ubuntu)
Undecided
Unassigned
openssh (Ubuntu)
High
Unassigned
ubuntu-meta (Ubuntu)
Undecided
Unassigned

Bug Description

we want to remove 'cloud-image' seed and join it with 'server' seed.
openssh-server is one of the few (3) packages that are in cloud image and not in 'ubuntu-server'.

We'd like to have the server iso install openssh-server by default and prompt the user if they want to enable it or not.

Related branches

Steve Langasek (vorlon) wrote :

I don't believe this is a bug in the ubuntu-cdimage project. If you want a prompt on install of openssh-server for whether to enable it or not, this should be done in the openssh-server package.

I do wonder why we want to prompt at all. Is there a reason not to run ssh by default on a server install?

Scott Moser (smoser) wrote :

We want to have 'ubuntu-server' have the same set of packages everywhere.
Currently openssh-server is one package that differs between cloud image and default server iso install.

We can 'fix' that in any number of ways. Two that come to mind are:
a.) add openssh-server to 'server' seed and thus default install of server iso and leave it running and port 22 open
b.) add openssh-server to 'server' seed but prompt the user during installation if they want to run the service (or possibly I supposed prompt if they want to choose to not install it).

Either of the above is fine, but the goal is to have by-default the ubuntu-server iso install have the same content as a maas install or a cloud image.

Scott Moser (smoser) wrote :

Previously (at least in the 10.04 time frame) the security team was adverse to having the default server install have ssh installed. That was just general "secure by default" mentality. Thats why i suggested we would prompt.

Steve Langasek (vorlon) wrote :

Summarizing yesterday's discussion with the Security Team:
 - we would like password auth disabled by default on installation of openssh-server via the server image, just as via the cloud image
 - the admin can set up password auth post-install
 - (optional) this can be a debconf question, so that the admin can pre-seed enabling of password auth at install time.
 - with the above requirements met, the Security Team is ok with having openssh-server installed by default, and listening on port 22, on a server install as well as on a cloud image.
 - no requirements were expressed on the behavior of openssh-server if manually installed by the admin post installation.
 - (optional) ideally, the openssh-server systemd units would be adjusted for lazy socket-based activation, so that this is not an additional server process running (and taking up swap space / process table space) until asked for.

Opening a task on the openssh package.

Colin Watson (cjwatson) wrote :

I think I'm OK with adding a low-priority debconf question to disable password authentication. That's a much lower-maintenance solution from my point of view than the various things that have been proposed in the past for disabling the service entirely. The packaged default would be true (i.e. enable password auth), but the server image could preseed it to false.

Regarding socket activation, I'd like to draw your attention to this section from openssh-server's README.Debian file. The bit about MaxStartups explains why I'm unwilling to make this the default on servers:

Per-connection sshd instances with systemd
------------------------------------------

If you want to reconfigure systemd to listen on port 22 itself and launch an
instance of sshd for each connection (inetd-style socket activation), then
you can run:

  systemctl stop ssh.service
  systemctl start ssh.socket

To make this permanent:

  systemctl disable ssh.service
  systemctl enable ssh.socket

This may be appropriate in environments where minimal footprint is critical
(e.g. cloud guests). Be aware that this bypasses MaxStartups, and systemd's
MaxConnections cannot quite replace this as it cannot distinguish between
authenticated and unauthenticated connections; see
https://bugzilla.redhat.com/show_bug.cgi?id=963268 for more discussion.

The provided ssh.socket unit file sets ListenStream=22. If you need to have
it listen on a different address or port, then you will need to do this by
copying /lib/systemd/system/ssh.socket to /etc/systemd/system/ssh.socket and
modifying the ListenStream option. See systemd.socket(5) for details.

Changed in openssh (Ubuntu):
importance: Undecided → High
status: New → Triaged
summary: - install openssh-server by default, prompt for enabling it on server iso
- install
+ Install openssh-server with disabled password auth by default on servers
Colin Watson (cjwatson) wrote :

Incidentally, my reasoning for "true by default" in the package is basically the bootstrapping problem; I don't want this to be a nasty surprise for people with existing deployment strategies. Changing PermitRootLogin was controversy enough. But I don't mind what the setting of this on server images is.

Colin Watson (cjwatson) wrote :

I've sent the proposed text of a debconf template for review to the debian-l10n-english list.

On Sat, Apr 30, 2016 at 10:23:35AM -0000, Colin Watson wrote:
> Per-connection sshd instances with systemd
> ------------------------------------------

> If you want to reconfigure systemd to listen on port 22 itself and launch an
> instance of sshd for each connection (inetd-style socket activation), then
> you can run:

> systemctl stop ssh.service
> systemctl start ssh.socket

> To make this permanent:

> systemctl disable ssh.service
> systemctl enable ssh.socket

> This may be appropriate in environments where minimal footprint is critical
> (e.g. cloud guests). Be aware that this bypasses MaxStartups, and systemd's
> MaxConnections cannot quite replace this as it cannot distinguish between
> authenticated and unauthenticated connections; see
> https://bugzilla.redhat.com/show_bug.cgi?id=963268 for more discussion.

> The provided ssh.socket unit file sets ListenStream=22. If you need to have
> it listen on a different address or port, then you will need to do this by
> copying /lib/systemd/system/ssh.socket to /etc/systemd/system/ssh.socket and
> modifying the ListenStream option. See systemd.socket(5) for details.

AIUI this should be fixable by patching openssh to use the systemd
socket-passing protocol (sd_listen_fds(3)) instead of relying on inetd-style
socket passing. In that case, openssh can apply whatever controls it wants
to the listen() socket.

Colin Watson (cjwatson) wrote :

I'm not sure how that would make any difference at all. The problem is
that it's hard for sshd to maintain the necessary state across multiple
invocations when it's being invoked once per connection rather than
having a master process that can trivially keep track of all the
inter-connection state it needs.

Persisting the necessary state in the filesystem somewhere would no
doubt be in principle possible, but would require careful locking and
such, and would add more code to the pre-authentication attack surface.
Upstream is in general very cautious about such changes, and I think
rightly so. AFAICS even Fedora doesn't do this yet, and one would
normally expect them to be enthusiastic about pushing for
systemd-specific enhancements.

Steve Langasek (vorlon) wrote :

On Mon, May 02, 2016 at 05:44:31PM -0000, Colin Watson wrote:
> I'm not sure how that would make any difference at all. The problem is
> that it's hard for sshd to maintain the necessary state across multiple
> invocations when it's being invoked once per connection rather than
> having a master process that can trivially keep track of all the
> inter-connection state it needs.

When using the sd_listen_fds(3) protocol, systemd is *not* calling accept()
on the service's behalf, and is not launching per-connection instances of
the service. The socket activation is merely lazy initialization, where
once a connection comes in, the normal ssh service is launched and manages
that socket from there on out. So there would be a master process keeping
track, unless I've overlooked something?

Steve Langasek (vorlon) wrote :

AIUI the required openssh piece of this is now done:

openssh (1:7.6p1-4) unstable; urgency=medium

  * Move VCS to salsa.debian.org.
  * Add a preseeding-only openssh-server/password-authentication debconf
    template that can be used to disable password authentication (closes:
    #878945).

Remaining pieces to be done:
 - set up the d-i server preseed
 - set this correctly in the server live image (subiquity)
 - add openssh-server to the server seed.

Changed in openssh (Ubuntu):
status: Triaged → Fix Released
Steve Langasek (vorlon) on 2018-06-16
Changed in ubuntu-cdimage:
status: New → In Progress
tags: added: id-5a4c19be676c7709fe6b2d20
Adam Conrad (adconrad) wrote :

See the comment on the linked debian-cd MP from Marc Deslauriers. Note that the goal of removing the cloud-image seed is still entirely reasonable and doable, openssh-server should just move to livecd-rootfs as something always added to cloud images. Done and done. There's no reason that one package needs to be represented in a seed/task any more than custom kernels or cloud agents are.

Dimitri John Ledkov (xnox) wrote :

This is won't fix at the moment, please see comments at https://code.launchpad.net/~vorlon/debian-cd/lp.1576353/+merge/348112

Changed in livecd-rootfs (Ubuntu):
status: New → Won't Fix
Changed in ubuntu-meta (Ubuntu):
status: New → Won't Fix
Adam Conrad (adconrad) on 2018-10-05
Changed in ubuntu-cdimage:
status: In Progress → Won't Fix
Scott Moser (smoser) wrote :

@Adam,

> See the comment on the linked debian-cd MP from Marc Deslauriers. Note
> that the goal of removing the cloud-image seed is still entirely
> reasonable and doable, openssh-server should just move to livecd-rootfs
> as something always added to cloud images. Done and done. There's no

Your argument can then be extended to indicate that we do not need *any*
seeds at all. We'll just hard code package lists that we install in
some arbitrary scripts on some server/git-repo. "Done and done."

That doesn't make sense. The point of 'Ubuntu Server' seed is that
having it implies "default ubuntu server". The user can expect certain
behaviors of a system that is "Ubuntu Server".

That is not consistent, user-friendly or "just works".

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.