SSH and the Ubuntu Server

[Marc Deslauriers]

Hello,

On Thu, 2010-11-18 at 08:00 -0600, Dustin Kirkland wrote:
> >  ----------------------------------------------------------
> > |  If you need a secure connection to this
> > |  server remotely, you may wish to install
> > |  the openssh-server package.  Note that
> > |  this service will open TCP port 22 on
> > |  your system, and you should use a very
> > |  strong password.
> > |
> > |  Do you want to install the SSH service?
> > |
> > |        [[YES]]        [no]
> >  ----------------------------------------------------------
> >
> > Rest assured that the exact text will be word-smithed by an
> > appropriate committee to hash out an optimum verbiage.

I think this screen is a good idea if in fact tasksel is moved to after
the first boot.

We would need to change the wording though as using ssh with password
authentication is insecure and should not be something we recommend. A
lot of users who come to #ubuntu-hardened trying to figure out why their
server was compromised end up discovering that ssh password
brute-forcing was the cause.

> >
> > This proposal requests that:
> >  1) a new prompt be added to the Ubuntu Server installer
> >  2) this prompt be dedicated to the boolean installation, or
> > non-installation, of the SSH service, as an essential facet of a
> > typical server
> >  3) the cursor highlights the affirmative (yes, please install SSH),
> > but awaits the user's conscious decision

This is where I disagree. Dangerous actions should not be the default
choice. 

I've seen numerous corporate environments where the default/generic
account used during server installation was still enabled when the
server went into production.

I want the person installing the server to actually make the choice to
install ssh in order to realize that doing so may have consequences. ie:
"Oh wait, If I install ssh now, I should unplug the server from the
network and configure ssh properly before hooking it back up..."

Making the cursor default to "yes" means people who install the server
and don't know the impact of answering yes will get something dangerous
installed that they weren't counting on.


> >
> > These key points map to the following considerations:
> >  1) the current option to install SSH on Ubuntu servers is buried in
> > the tasksel menu
> >    - SSH is more fundamental to a server than the higher level
> > profile selections for:
> >      DNS Server, Mail Server, LAMP Stack, Virtualization Host, etc.
> >  2) users of the installation ISO will have the option to not install
> > SSH, as they so desire
> >    - it is quite well understood that some users may not want SSH
> > installed on their server

Corporate environments don't typically allow ssh access to servers from
the main network for security and conformance reasons. Remote management
cards and IP KVMs are often used from an isolated administrative
network, or SSH is configured to listen only to a specific network
interface. Contrary to what some people have suggested, pre-seeding
isn't used in a lot of these cases.

This is one of the reasons I like having SSH as a choice during install,
and not simply installed by default.

> >  3) highlighting the "YES" option on this page is absolutely essential
> > to addressing this usability issue
> >    - and that selection is easily overridden by hitting <tab><enter>,
> > or by experienced admins in preseed configurations

SSH can just as easily be enabled by hitting <tab><enter> also.

> >
> > Please consider that the very definition of a "server" implies that
> > the system is running a "service".  Moreover, our official Ubuntu
> > Server images as published for the Amazon EC2 cloud are, in fact,
> > running SSH by default listening on port 22 on the unrestricted
> > Internet (the 'ubuntu' has no password), and the Ubuntu Enterprise
> > Cloud installation by the very same ISO installs SSH on every every
> > UEC system deployed.  This is not unprecedented.

As far as I recall, EC2 opens the ssh port from your ip address only,
and authenticates using certificates and not passwords.

Actually, now that you mention it, we should probably disable SSH
password authentication by default in the EC2 images...

As for UEC, I don't think that's a "default installation" as the person
installing is selecting to install a bunch of software that opens a
bunch of ports, including SSH.

> >
> > Having discussed the proposal with a subset of this audience (at UDS
> > and in IRC), here are some known FAQs:
> >
> >  Q: WTF?!?  Ubuntu has no open ports by default!
> >  A: That depends on which "Ubuntu" you mean.  Ubuntu-in-the-cloud runs
> > SSH.  Ubuntu-as-the-cloud runs SSH.  Ubuntu desktops run avahi.  Most
> > importantly, this is not a "run by default" proposal.  We have already
> > compromised on that subject, culminating in this proposal, which is
> > simply about providing Server users with an obvious way to install the
> > typically essential SSH service.
> >
> >  Q: Why not default the cursor on that question to "No", instead of "Yes"?
> >  A: That totally bypasses the value of this proposal, and is only
> > microscopically better than what we currently have, where Ubuntu
> > Server users must go out of their way to add one of the most
> > fundamental packages to almost any server installation.  The proposal,

I don't think hitting the spacebar next to "OpenSSH Server" is making
people "go out of their way" or is a usability issue. I certainly don't
think making them hit <tab> before <enter> to highlight "yes" would be
making them go out of their way.

> > as it stands, is already a compromise from the original suggestion at
> > UDS; which was, "if you're installing a server, you're expecting to
> > run a service, so let's just install SSH by default".  That idea is
> > entirely out of scope now.  We are proposing this installer question
> > as a reasonable compromise.
> >
> >  Q: What if the openssh-server package is compromised on the ISO?
> >  A: Although this has happened before, it is relatively rare over the
> > history of Ubuntu.  If/when this happens again, we would need to:
> >    a) recommend that people choose "no" when prompted, and install
> > SSH post-installation from the security archive (same as we would do
> > now, actually)
> >    b) and probably respin the ISOs (also been done before)

This isn't the only reason to not have SSH by default. My point was not
having SSH installed by default before the administrator can properly
secure a server, including installing security updates, and configuring
ssh to respond to a particular network interface with password
authentication disabled.

> >
> >  Q: Why don't we disable password authentication?
> >  A: We could do this, and ask users to provide a public SSH key (or
> > even just a simple Launchpad userid whose public key we could securely
> > import).  This would probably involve adding another page to the
> > installer, public SSH keys are hard to memorize, while others will
> > almost certainly object to even optionally tying their Launchpad ID to
> > Ubuntu installations.  Most importantly, Ubuntu does not set a root
> > password, so an attacker would need to guess BOTH the username AND
> > password.

Password authentication should definitely be disabled when SSH servers
are exposed to untrusted networks. But in a lot of cases though, SSH
password authentication is acceptable, such as on my home network, or in
a corporate environment where the SSH port is restricted behind a
firewall.

I don't think disabling SSH password authentication is something that
can realistically be done by default for now.

> >  Q: What if I want a different sshd configuration than what's shipped
> > by default in Ubuntu, before running sshd?
> >  A: You sound like an advanced user; please preseed your installation,
> > or add SSH after the initial install (as you would do now).

Securing your ssh installation is mentioned in every single security
checklist I've seen. This isn't something only advanced users need to
do. Making novice users install SSH without knowing the impact of doing
so is not something we should be recommending.

Marc.