New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it possible to use Nixops without automatic SSH key provisioning #1247
Conversation
897f04b
to
7060b92
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking pretty cool so far :)
You and I were talking about this a few days ago, and this is what I wrote up then. I wonder if there is a way to author this PR in a way way to build out support for the other use cases?
example use cases we might want...
what we do now, but more explicit:
{
defaults = { resources, ... }: {
deployment.sshKey = resources.sshKeyPairs.management-key;
};
resources.sshKeyPairs.management-key = {};
}
create an SSH key per machine, automatically:
{
defaults = { machine_uuid, resources, ... }: {
deployment.sshKey = resources.sshKeyPairs."${machine_uid}"; # implicitly create an SSH key per host
};
}
use a yubikey or other PKCS11-compatible device for SSH:
{
defaults = { machine_uuid, resources, ... }: {
deployment.sshKey = resources.sshKeyPairs.adams-yubikey;
};
resources.sshKeyPairs.adams-yubikey = {
provider = "pkcs11";
keyId = "abc123";
};
}
get an automatically provisioned SSH key from Vault:
{
defaults = { machine_uuid, resources, ... }: {
deployment.sshKey = resources.sshKeyPairs.vault-deploykey;
};
resources.sshKeyPairs.vault-deploykey = {
provider = "vault";
server = "https://127.0.0.1:8200";
secretEngine = "ssh-keys";
role = "nixops-deploy";
};
}
use your SSH agent, and using a defined SSH public key for provisioning:
{
defaults = { machine_uuid, resources, ... }: {
deployment.sshKey = resources.sshKeyPairs.agent;
};
resources.sshKeyPairs.agent = {
provider = "ssh-agent";
publicKey = "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDUy2CGT6P3q2kApZEuyCHsuCruwdRzeWMdQe/WjdCak grahamc@Petunia"; # needed to copy to the target during provisioning
};
}
7060b92
to
b4c38df
Compare
db4546b
to
aa91367
Compare
I actually think we end up with more flexibility by not supporting each use case explicitly. By doing this we automatically support most use cases that supports SSH agent. I don't know about using Vault, that may require explicit support from Nixops. |
aa91367
to
03a9e0d
Compare
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
03a9e0d
to
f703400
Compare
Rebased on latest master |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking forward to this!
While working on a similar problem recently, I realized that accepting and/or generating an entire openssh config file is a really flexible option! In my utility, I was able to clean up all my ssh invocations this way (simply (This is not a recommendation for this PR, just a note!) |
This has been somewhat addressed in #1270 with the addition of |
1fcaaef
to
cf6069e
Compare
1083a18
to
b28fcb9
Compare
679d98f
to
5e7d3a9
Compare
5e7d3a9
to
600d036
Compare
60bd470
to
a58a7b1
Compare
a58a7b1
to
f2f50af
Compare
This line has been a constant source of annoyance when adding/removing options. This may look ugly but optimises for "diffability".
f2f50af
to
a8e70ee
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
No description provided.