SSH and the Ubuntu Server

[Stephan Hermann]

Hi Nicolas,

On Thu, 2010-11-18 at 09:24 +0100, Nicolas Barcet wrote: 
> Hello Stephan,
> 
> On 11/18/2010 08:20 AM, Stephan Hermann wrote:
> >
> > First of all, I think for Ubuntu Server the SSHD service should be
> > enabled by default, eventually having a question on what IP interface
> > the service should be listening and eventually giving a possibility to
> > push a ssh public key to the box (please not via Launchpad or other web
> > based services). SSHD is (for me) an essential server service.
> >
> > Having SSHD not enabled by default on Servers is a bit of a strange
> > behaviour, regarding other enterprised based Distros.
> 
> I think everyone in Corporate Services agrees with your above statement
> that the default should be to include sshd.  However, what we are facing
> here is a rather major change in default behavior and, as such,
> justifies that users be properly informed about it.  Think about it this
> way: wouldn't you like to see a warning if at some point the desktop was
> not to install any graphical interface anymore?

Well, when I take the desktop install media, I would like to see a fully
working desktop after the installation up and running.
That's why I think someone installing from a server install media would
like to see a fully running server installation afterwards which is
accessable.

Now, we can discuss what a "fully running server installation" is?

I would say, that running Ubuntu server in a datacenter, is mostly
behind a secured network, where e.g. SSHD is listening on a special ip
interface, which is not accessible by everyone but only to a team of
admins with Godmode enabled. And yes, most of the time you have remote
insight boards etc. to access the machines.

On Amazon EC2 this is totally different. I don't actually know if you
can somehow access the xen vm without remote access from the public
(NATed) network of Amazon. 

When we are thinking now to enable a service by default, which wasn't
installed and enabled in the past, we need to inform the admin. Agreed.

But what is the best way? 
We don't want to have the admin stay as long as it takes at the console.
Most admins (at least those I know) do read documentations, and release
notes are at least one of the documentations every admin should read
(just think about the change of behaviour of the bonding interface
setups from jaunty -> karmic -> lucid).

> 
> > On Ubuntu Desktop this is different. The Desktop doesn't need an sshd
> > server, and there ist shouldn' be installed or when installed, it
> > shouldn't be enabled.
> > 
> > A newly introduced service which opens a port could be documented in the
> > release notes and other prominent places.
> 
> If, as Kees mentioned in another email, we are facing users that press
> next without looking, do you really think that the same users will take
> the time to read the release notes?

Really, this is difficult to answer.

Regarding the user base of non-technicians, comsuming-only desktop users
(please, don't interpretate it as all ubuntu users are non-technicians
and consuming only), I don't think that those users are reading a lot of
documentation. Seeing that from the Windows world, I think we can drop
documentation completely.

Regarding the Admin people, they do read documentation and especially
release notes, ChangeLogs etc. when they are in the field of Operating
System Deployment (again, at least the admins I do know and I'm
working/had worked with)



> 
> I think I fully understand the security team's concerns here, but given
> that:
> 
>  a/ Based on what I have heard at UDS, we are considering adding a post
> boot install phase for additional package installation, it would seems
> reasonable to make it available across the network.
> 
>  b/ Even if I have made my initial install with a CD or a USB stick, I
> do not know much admins that want to stay in front of their servers more
> than the strict minimum time.  Personally I generally hate myself when I
> have missed to check the sshd service on the tasksel screen, because it
> means that I'll have to wait in the noisy and cold server room an
> additional 5 mins (yes, despite our efforts to improve boot times,
> hardware manufacturer for servers still consider it a great idea to have
> various checks been done during boot, prior to the OS being loaded)

Actually I don't know any admin anymore who stands in front of a console
in a cold datacenter, mostly we are using ILOs and other remote console
access methods to get hands on the server (most of our servers don't
even have CD drives anymore, totally useless nowadays).

That's why I already think that we are discussing a matter which isn't
really one. What we are trying now is to deliver a better user
experience, for people trying out our server media.

> 
>  c/ Similarly to b, when I am installing a virtual machine, the less
> time I spend in the server screen emulation the better, as this is
> generally much slower and often much clumsier (think keyboard mapping
> for example) than accessing the same server over SSH.

Agreed, actually in todays virtual environments you already have a
template with a machine which is already installed with a good default
of packages you need. And dhcp does the rest.

> 
>  d/ If the version of sshd that is provided on a CD becomes compromised,
> we have seen in the past that it does not matter much whether it is
> installed by default or not, since most people will have installed it.
> It did not prevent us from re-spinning ISOs and it won't prevent people
> from not applying security updates if they are not used to do so.

Well, this is something we have to face anyways. IMHO it's only a matter
of delivering a better experience for people who are using our server
media for the first time for evaluation. And for those people we need to
find a good way to provide sane and safe defaults.

> 
>  e/ The biggest risk seems to be for people that would deploy a server
> that have a direct connection to the Internet with a CD containing a
> version of sshd that is compromised.  In this very case, we do however
> have the mean to pull from security.ubuntu.com during the install, as
> the machine is connected to the net, right?

Hmmm? Do we have any numbers how many people are doing exactly that? And
how many times we had compromised sshd on the CD media?

Mostly people (which are not sysadmins by nature and profession) are
buying root servers which are pre-installed with ubuntu server or
whatever distro someone likes. Those servers are directly connected to
the internet and have already sshd enabled. So I don't have any
reference to users who are installing ubuntu server via CD media and do
have a server which is directly connected to the internet. When there is
such a userbase, I think we need to invest more time in education. 

> 
> Because of the above points, and given our history and our wish to
> propose the best default possible for our users, I personally think that
> Dustin's proposal is the best middle ground we can find, and I fully
> support it, with the default set to yes.

I'm not proposing to not introduce sshd deployment by default, but we
shouldn't shock the people. Having a straight installation workflow,
where SSHd is integrated like "what is your username?" I think that's
more valuable. So having debconf questions like "which IP interface sshd
should listen on" and "please provide your public ssh key" are ok. 

The only problem I see here, that it totally fails our "less open
network ports" strategy. 

And of course, Kees is also correct, that many users are not reading
anything during installation or reading documentation, but I wonder if
we are really want to address those people, or if we want to address
serious people having more knowledge regarding servers.

Regards,

\sh

-- 
Stephan '\sh' Hermann
SysAdmin / Ubuntu Developer
xmpp: sh at sourcecode.de