Always provide our known_hosts in addition to user known_hosts #1464
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
roberth
added a commit
to hercules-ci/nixops-aws
that referenced
this pull request
Aug 6, 2021
This was referenced Aug 6, 2021
roberth
force-pushed
the
internal-known-hosts-handling
branch
4 times, most recently
from
454bf40
to
ec0007f
Compare
This way, we don't have to rely on user configuration to include known_hosts entries for the deployments. It makes `nixops import --include-keys` unnecessary, unless you use those entries outside of nixops. Since recently we can get our deployment state from remote storage backends, but we didn't have a way to get configure the known_hosts yet. This is now largely unnecessary. This functionality requires some cooperation from the plugins. For instance, here's what ec2 needs to do: (pun intended) + def get_ssh_host_keys(self): + return self.private_ipv4 + " " + self.public_host_key + "\n" + self.public_ipv4 + " " + self.public_host_key + "\n"
roberth
force-pushed
the
internal-known-hosts-handling
branch
from
ec0007f
to
94a6884
Compare
roberth
added a commit
to hercules-ci/nixops-aws
that referenced
this pull request
Aug 6, 2021
Mic92
reviewed
Aug 28, 2021
Mic92
reviewed
Aug 28, 2021
Mic92
reviewed
Aug 28, 2021
Mic92
reviewed
Aug 28, 2021
Mic92
reviewed
Aug 28, 2021
Thanks Mic92!
|
Thanks @Mic92 that was very helpful! |
AmineChikhaoui
approved these changes
Aug 31, 2021
roberth
added a commit
to hercules-ci/nixops-gce
that referenced
this pull request
Nov 18, 2021
This will let NixOps provide the host keys directly to the ssh client, regardless of whether they've been saved to user dotfiles. It solves a problem where the host keys were not known on systems that retrieve the state from a remote state provider. See NixOS/nixops#1464
9 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Solves one of the problems from #1264 (comment)
It also solves a problem where multiple deployments to distinct private networks fight over the key for the same ip that occurs in both.
Prevously, you'd
With this pr, we don't have to rely on user configuration to include
known_hosts entries for the deployments.
It makes
nixops import --include-keysunnecessary, unless youuse those entries outside of nixops.
Since recently we can get our deployment state from remote storage
backends, but we didn't have a way to get configure the known_hosts
yet. This is now largely unnecessary.
This functionality requires some cooperation from the plugins. For
instance, here's what ec2 needs to do: (pun intended)
(NixOS/nixops-aws#141)