SSH and the Ubuntu Server

[Clint Byrum]

On Wed, 2010-11-17 at 15:38 -0600, Dustin Kirkland wrote:

> 
> 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

+1 for adding this prompt

>  3) the cursor highlights the affirmative (yes, please install SSH),
> but awaits the user's conscious decision
> 

-1 for having it default to Yes.

> 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.

Agreed completely.

>  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

I'd rather assume that those who do want SSH will be looking for the
option to enable it, and those who do not, won't be accidentally exposed
to any problems that it includes.

>  3) highlighting the "YES" option on this page is absolutely essential
> to addressing this usability issue

Side stepping the issue of "what is a default install", I would like to
delve into the usage of the term 'usability' in the above sentence.

I think setting it to No by default in the first iteration of this
prompt may be a little less controversial. If users are still
complaining that "I always have to stop at that point and hit tab,enter
to enable ssh" then I could see making a usability argument. However,
its also annoying that sudo times out and asks for the admin password
after a while, one could even argue it is less usable, but it is *far*
more secure as a default setting. Any more secure and it would be
unbearable. Any less, and it wouldn't help users much.

>     - and that selection is easily overridden by hitting <tab><enter>,
> or by experienced admins in preseed configurations
> 

The same is true if it is No, and can be changed to Yes. This is
precisely why I think this particular selection (default to yes, or
default to no) isn't really a usability issue, but a secure default
issue.

The usability issue arises when one says no. Then its not totally clear
after the install finishes how to enable SSH access so you can leave the
server room/closet/etc and go back to your desk to admin the darn thing.
However, I think its fair to also add this to the "first boot" motd,
something like "Looking for SSH? Install it with sudo aptitude install
openssh-server".

> 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.
> 

The default Amazon security group allows nothing from the internet:

"Firewall: Amazon EC2 provides a complete firewall solution; this
mandatory inbound firewall is configured in a default deny mode and the
Amazon EC2 customer must explicitly open any ports to allow inbound
traffic. The traffic may be restricted by protocol, by service port, as
well as by source IP address (individual IP or CIDR block)."[1]

I recall being puzzled the first time I spawned an EC2 node and not
being able to SSH to it, but soon finding it comforting that I could
only SSH to my instances from the class C that my home connection sits
on after adding that explicitly to the security group.

I don't know how Euca/UEC security zones are setup by default.

Also consider that there are plenty of servers built to do data
collection only, without ever being remotely managed. Yes, this is
probably less than 1% of installed servers, but I think its unfair to
characterize these systems as "not servers" because they do not allow
incoming connections or remote management. 

In the context of this discussion though, this actually suggests that
for these few "weird" systems, stopping to switch to "No", would seem
natural.

> 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.
> 

I agree with Kees, that settling the choice on Yes is, in fact, a
default. However, settling it on No is a fantastic idea and doesn't in
any way incite this question.

>  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,
> 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.
> 

Totally bypasses the value? I think you're discounting the value of
un-burying SSH from tasksel and removing the (rather cumbersome) tasksel
from the installer. That is such an awesome idea, I'd like to see it
happen no matter what.

>  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)
> 

I like the idea of recommendations and alerts altering peoples divergent
behavior, rather than a recommendation needing to alter the shortest
path. Its easier to tell the few ocean swimmers and surfers to stop
surfing for a few days while the beaches are cleaned up than it would be
to tell everybody to evacuate their neighborhoods while a sewage spill
is cleaned up.

Going by this principle means that upon needing to fix a problem like
this, the successful propagation of your recommendation is not the only
thing protecting users, but also their sloth in not stopping to change
"turn on SSH" to Yes.

>  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.
> 

I think this is beyond the scope of the proposed prompt. Ultimately,
adding all of the steps of ssh key gen would probably tip the scales a
little too far from usability toward security.

>  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).
> 
>  Q: Do we have to add another question to the Server installer to
> accomplish this?
>  A: Actually, we don't.  We could possibly simplify or remove a couple
> of other questions.  That discussion belongs in another thread,
> though.

I think we did reach a group consensus at UDS that if this question were
added, tasksel could be removed from the default server installer and
suggested as something to run in the "first login" motd.

--

[1] http://aws.amazon.com/articles/1697?_encoding=UTF8&jiveRedirect=1