Rebuilding servers should not require --admin-pass

[sigmavirus24]

Before I switched to rack, I used rackspace-novaclient. When I rebuilt servers with that tool, I was not required to provide --admin-pass and it seems odd that I can only provide it on the command-line. In other words:

• is it possible to not require it or
• is it possible to provide just --admin-pass and have rack prompt me for the password similarly to python's getpass.getpass?

[sigmavirus24]

I've done some research. The closest thing to python's getpass.getpass is golang.org/x/crypto/ssh/terminal and you can use it like so:

package main

import (
    "fmt"
    "golang.org/x/crypto/ssh/terminal"
)

func main() {
    fmt.Printf("Provide password: ")
    password, _ := terminal.ReadPassword(1)
    fmt.Printf("\nProvided: %s\n", password)
}

[jrperritt]

When I rebuilt servers with that tool, I was not required to provide --admin-pass

True. If I'm remembering correctly, the current approach was done for 2 reasons:

1. Gophercloud (which rack uses to talk to Rackspace) had admin-pass as a required field because it was documented as such back when it was implemented in Gophercloud (I see now the field is optional),
2. rack is primarily targeted toward Rackspace customers, and we'd rather force users to provide a password than to lose access to their server.

is it possible to not require it

What would be the process for accessing the server in this case after it was rebuilt? Putting an SSH key on the server with --personality?

is it possible to provide just --admin-pass and have rack prompt me for the password

That's reasonable, and in fact what I've done for the config command for the in-development OpenStack CLI (upon which rack 2.0 is currently planned to be built). The only difference here is that we'd have to check that the command is coming from a terminal.

[sigmavirus24]

So if you already have a public SSH key on a server and you rebuild it, the SSH key that you used to build the server will still be there. So assuming you haven't changed your SSH key between when you uploaded your pubkey and when you rebuilt the server, you won't need a password to log in. I suspect most people rebuilding servers like that aren't using a password for root. I obviously have nothing but intuition to back that up though.

[jrperritt]

if you already have a public SSH key on a server and you rebuild it, the SSH key that you used to build the server will still be there

OK, that's good to know; I didn't know that.

I suspect most people rebuilding servers like that aren't using a password for root

Probably true. But what about users who don't have a public key on the server? Or who do but then had to change it without realizing (or remembering) it was their only way into the server?

For me, it comes down to minimizing the opportunity for problems that occur by accident. I'm OK with not requiring it if we have reasonable solutions for when things go wrong. Thinking out loud:

If a user is locked out of a server (or, more generally, has in their possession a server instance), can they make an image of the server and create a new server from that image along with a new SSH key and/or root password, thereby bypassing the credentials needed on the original server for authentication?

Or, coming at it from the other side, does there exist a scenario where a user can completely and irreversibly lock themselves out of their own server such that they can never again access the information on it? If not, then what prevents it?

[sigmavirus24]

For me, it comes down to minimizing the opportunity for problems that occur by accident.

You have an excellent point, so let me change my request.

What if we require one of --admin-pass and --generate-password where the latter generates a password that is then printed for the user's sake?

Some people would rather supply their own via --admin-pass while others (who don't actually need the password like myself) could use --generate-password. I suppose that --generate-password would be not very different from installing something that can generate passwords for you, but I'm not sure everyone would want to do that.

[jrperritt]

What if we require one of --admin-pass and --generate-password where the latter generates a password that is then printed for the user's sake?

Ah, right, but now we've come full-circle, because how would that be different than a user generating a random password and passing it to --admin-pass themselves?

[sigmavirus24]

For one, it doesn't get stored in their bash history. For another, we can generate one that would be safer than something "random" a user might come up with.

[jrperritt]

it doesn't get stored in their bash history

That's a choice. This, for example, wouldn't: rack servers instance rebuild --name myServer --admin-pass $(cat mypass.txt) --image-id 123456789

For another, we can generate one that would be safer than something "random" a user might come up with.

I think that's a valid point.

[jrperritt]

I think a generate-password flag is a good compromise. Will add.