Skip to content
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

Setting KnownHosts for SSH #2

Open
domenkozar opened this issue Mar 18, 2016 · 3 comments
Open

Setting KnownHosts for SSH #2

domenkozar opened this issue Mar 18, 2016 · 3 comments
Assignees

Comments

@domenkozar
Copy link
Contributor

Hydra queue runner doesn't automatically accept new hosts (due to default behavior in OpenSSH which is to ask for accepting the new host).

There are two ways to do that automatically:

  1. by setting sshPublicHostKey which should be base64 encoded fingerprint line (not documented, but see commit NixOS/hydra@2a7fbd5), I will push a commit to enable setting this in NixOS
  2. by setting programs.ssh.extraConfig = "StrictHostKeyChecking no"; in hydra-master

I chose the latter because it's a very low security tradeoff. SSH will still bail out if there is host mismatch, but it will automatically accept new hosts.

If hosts/key is hacked on first connection I think you're in trouble anyway.

@zimbatm
Copy link

zimbatm commented Mar 19, 2016

SSH also supports having a shared CA that can generate keys for all of your workers. Then you can configure the CA public key in your master an access all the workers automatically. It does add a step to generate the ssh keys and transmit them to the workers. I don't know how you start your new workers but if you use EC2 you could generate the key on your machine and then pass it to the cloud-init.

https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu

@domenkozar
Copy link
Contributor Author

@peti I think we should note this in the tutorial. I'd go with 2) option, but either way is fine.

@peti peti self-assigned this May 10, 2016
@expipiplus1
Copy link

expipiplus1 commented Jun 10, 2016

It's possible to avoid setting StrictHostKeyChecking no by setting the known hosts system wide with
programs.ssh.knownHosts

Here is an example courtesy of @cleverca22 https://gist.github.com/cleverca22/e2f674c4f8dc0057879e25b1c6a3ef50

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants