Improve handling of default root password on new autoinstalls

[Geoffrey Thomas]

Currently we create new autoinstalls with an empty root password, and only allow logins via the console server (which is Kerberos-acl'd). There are some potential improvements here, both in terms of UI -- discouraging people from using the console server -- and security -- we've had a security vulnerability in the past with the console server. Here are some approaches that come to mind:

1) Add a password field to the autoinstall creation form. Then we can automatically set up SSH, and recommend SSH in normal operation from the moment you start using the VM, and the console only as an emergency thing.

Potential downsides include browsers storing the password (which I think there's an HTML option to disable) and people using their Athena password (but we can kinit with it and yell at them if it works).

2) Acquire all the Kerberos keytabs for host/xvm-nnn.mit.edu, and set up Kerberized ssh by default with the appropriate .k5login copied from consolefs. This too allows us to recommend SSH from the beginning. Disable the root password, and tell people they're encouraged to set a root password of their choosing to make the emergency console useful.

Potential downsides include needing a Kerberized ssh client and tickets (but this is just bootstrapping, if you want to set a password you can), needing to store and keep up with a few hundred credentials, and the solution being extremely Athena-specific and probably not directly deployable outside XVM.

3) Generate a random root password and show it to the user on the website, and require them to change it the first time they log in using the appropriate option in /etc/shadow.

Potential downsides include the password being visible (given that it can only be used once, it's probably fine) and users changing the random password to a bad one. We could also just not require users to change it.

Thoughts? Other possibilities?

[Alex Dehnert (adehnert)]

4) Prompt the user for an ssh public key, and set that up by default. This too allows recommending SSH from the beginning. Unlike password auth, browsers storing the password, password reuse, and weak passwords aren't an issue. Unlike Kerberos, keytab management isn't an issue, and ssh key support is a bit more ubiquitous in ssh client than Kerberos is, I think.

[Geoffrey Thomas (geofft)]

Huh. I was going to say "nobody will know how to do that, the world isn't ready for that", but given that Github, Gerrit, etc. require that, maybe the world *is* ready for that -- and we wouldn't be too weird in pointing to documentation on how to create an SSH keypair and copy your public key. This is potentially the sanest idea; +1.