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 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
