Use dedicated SSH keypair for "none" backend.

[aszlig]

This should make the "none" backend a bit more useful as we only need to provide a key or passphrase on machine creation and from thereon we only use the SSH keys within NixOps' state database.

If you have a large set of "none" machines and want to export/import them, this should no longer require to move around ssh_configs or even entries in your hosts file.

In addition, this fixes the situation where you need to build on the target machines and the none backend wasn't able to provide a private key for the to be generated nix.machines file.

VM test result: https://headcounter.org/hydra/job/nixops/none-improvements/tests.none_backend/latest
(also required fixing the VM tests)

This is related to #200 and after talking to @joelton on IRC it turned out he was on Darwin, so NixOps was trying to build on the target machine(s), which in turn requires explicitly specifying a private key. As we now have the keypair in our own db, this is no longer an issue.

[edolstra]

Why not use users.extraUsers.root.openssh.authorizedKeys to set the key? get_physical_spec can already emit it.

[aszlig]

At that point we can't deploy the machine yet (or at least only in a very complicated way), because this actually sets the key that's to be used for creating the machine in the first place.

[edolstra]

Creating the machine? It already exists, right?

[aszlig]

More or less it exists, yes. But you can't necessarily deploy to it, especially if you use password authentication.

[edolstra]

Well, you must be able to deploy to it, because otherwise you wouldn't be able to ssh to it to add the key.

BTW, there are also some security implications here. For instance, I currently use the none backend to manage machines from a machine that doesn't have their private keys, but instead uses the SSH agent. So a compromise of the central machine doesn't necessarily lead to a compromise of the others. But if you generate new private keys on the central machine, that's no longer the case.

[aszlig]

Well, the machine is "created" like this:

Of course the SSH private key resides in the deployment specification, but using plain ssh without relying on ssh_util does have the advantage that we don't need to rely on the configuration of the host and as said: We even can use password auth for the first step.

I'm not sure I understand what you exactly mean by security implications, but for example if you use SSH agent forwarding it indeed will cause the key from the agent to be detached from the deployment. But IIUC the other backends provide their own SSH keypairs as well, so someone getting access to the state database (s)he will have access to all the machines anyway. So if that's a concern we could also encrypt the state database file.

That aside, if all our backends internalize the SSH stuff entirely, we could remove quite a lot of the cruft from ssh_util, for example handling of host keys and other factors (like for example the mentioned remote builds) that could get in the way of SSH operations. And of course, in order to protect the database, we could still encrypt it and/or the user could use external programs to do that on his/her own.

In the end, what I'd expect from NixOps is that no matter which deployment someone imports, you shouldn't need to configure additional things ("Please import this, then configure x, then you need to set y and some z and something over there. Oh, you're on OS X or cygwin, well... then you need ...") just to get it working.

Another option would be to make this an entirely different backend and we leave none as-is.

[edolstra]

Okay, so I have two issues with this:

• I don't really understand why it's needed. For NixOps to connect to a machine via the none backend in the first place, it necessarily already has a key, so there is no need for NixOps to create a new one.
• We shouldn't add keys to /root/.ssh/authorized_keys but via users.extraUsers.root.openssh.authorizedKeys. The former is not declarative, and keys listed there tend to accumulate over time (e.g. causing people to have access to a machine who no longer should).

[aszlig]

For the first point: It's no longer needed to have a key with this approach, and as said, it makes export/import of deployments way easier if you don't have to move around private keys that you might even use for other machines outside of that deployment. Another reason to do this in the long term is to properly isolate SSH access inside NixOps so we don't stumble on issues related to the current users ssh_config or their installed OpenSSH version at any point.

However, I agree with the second point, though it would be needed to do it in two stages (one temporarily for creation and the second during deployment). Doing it temporarily would increase complexity here, because we have to modify authorized_keys for deleting the key. Any better idea on that?

[edolstra]

Yes, I agree in principle that deploying keys is a good thing, I just prefer not to have it done via authorized_keys.

I'm not really clear on the "creation" thing given that the none backend is intended for deployment to pre-existing NixOS machines. What is running on that machine and what needs to be created?

[pikajude]

Creation of the deployment? The first time the deployment is created, nixops won't know how to access the machine, will it?

[aszlig]

Well, it's not "creation" in the sense of "installing" a machine but just putting the SSH public key on it, so a better term would be "creating an initial machine state". The machine itself would be a preinstalled NixOS system.

[aszlig]

@edolstra: Now it's no longer adding a key to ~/.ssh/authorized_keys as you suggested.

[edolstra]

@aszlig This is giving a merge conflict in tests/none-backend.nix. Should #350 be merged first?

[aszlig]

@edolstra: You could merge #350 and I'll rebase this branch afterwards.

[aszlig]

@edolstra: Rebased against current master.