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 firewalls/routers. 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. > > 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 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. Cheers, ..C..
signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel