SSH and the Ubuntu Server
hggdh2 at ubuntu.com
Thu Nov 18 19:05:46 UTC 2010
On 11/18/2010 09:49 AM, Marc Deslauriers wrote:
>>> 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.
I do not see this as a major issue: in corporate environments (where
you will usually find multiple network interfaces) a system is
installed in a protected area (either physically, or network-wise,
or both). It is not just installing the basic system, but all the
necessary configuration that needs to be done. Only after this
post-install configuration a system will be set in the
On the other hand, having SSH installed by default will help the
majority of corporate users: we go (either physically, or via a
serial console), install, and then happily use SSH to configure the
rest of the system (and get out of the -- usually -- lights-out and
cold environment, or off the bloody serial console).
>>> 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 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
I respectfully disagree. Password authentication should be disabled
by default. Downgrading security -- in corporate environments --
usually requires a formal risk acceptance process. Also, in every
audit I participated a system accepting SSH password authentication
would be flagged an audit finding, and documentation would be
required to justify it.
It strikes me as inconsistent that we allow a known risk as default.
It should be the other way: if I want to downgrade security, I have
to explicitly choose to do so.
Of course, in this discussion, having only PK-authentication would
require either the person installing to provide an out-of-band
public key, or the installer to have this option.
> 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.
Even more reason for us to provide a sensible -- and more secure --
default SSH configuration.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 900 bytes
Desc: OpenPGP digital signature
More information about the ubuntu-server