7

I recently started playing around with Ansible and it seems very nice. I don't have much experience in DevOps stuff and never really had to handle any complex scenarios. I started creating my Ansible playbook to replace my current deployment tool - Deployer PHP. I'm stuck at cloning git repository unfortunately. Now, I know I need a public key added to enable access to git repository and here comes my question.

Should I be using SSH agent forwarding (this way I can use my local SSH keys) or should I store private SSH key (encrypted, added to source control) within my ansible project and copy it using Ansible to my target node? I know the question may be very broad, so what interests me is security implications of both approaches.

0

4 Answers 4

4

You can also consider to encrypt the file containing your private SSH key using Ansible Vault.

Some links:

http://docs.ansible.com/ansible/latest/playbooks_vault.html

https://therealmarv.com/ansible-vault-file-handling/

https://www.calazan.com/how-to-deploy-encrypted-copies-of-your-ssl-keys-and-other-files-with-ansible-and-openssl/

4

If your git repos is a private github, you can use github methods (deploy keys is very powerful).

If your repos are not hosted on github or they don't provide read-only deploy key feature, The two options you mentioned are both valuable.

Single DevOps guy

If you are the only person working on the project and Your machine/machines are the only you will run ansible from (no CD tools like jenkins and friends) you're good to go with the agent forwarding option: is likely less possible that you forget your private key unencrypted around.

Small Team

If you are a team of people working on the same Ansible playbook or multiple people that run the playbook then you have both options:

  • keep the agent-forwarding option; every teammate run the script from his machine.

  • create a deployer key-pair, upload the pub-key and encrypt the private with vault as suggested by Berlin. The key is encrypted and the scope of the private key is restricted to only 1 or few repos. The problem with this approach is that you have to rotate the vault password every time a teammate leave the team.

I would never put my personal private key, which has a wide scope, in any possibly unsafe place. Vault encryption is as good as the people that uses it and there's a lot of keys/passwords in cleartext out there :)

0
2

Should I be using SSH agent forwarding (this way I can use my local SSH keys)

Yes, that could be an option

should I store private SSH key (encrypted, added to source control) within my ansible project and copy it using Ansible to my target node?

no

https://serverfault.com/questions/823956/ansible-security-best-practices

For servers, don't allow root access via ssh at all. Many audits scoff at this.

For ansible, let every admin use their own personal account on each target server, and let them sudo with passwords. This way no password is shared between two people. You can check who did what on each server. It's up to you if personal accounts allow login on password, ssh key only, or require both.

In summary, use an ssh key with password. Let every user use their own ssh keys. Never allow sudo access via ssh.

1
  • hmm, I'm not sure if this applies to the context. I asked about SSH keys used to pull (read-only) code from repository when deploying an app. With SSH agent I need each public key (each user) to be added to repository as deployment key.
    – pzaj
    Sep 17, 2017 at 16:14
0

You can story your private key in one circumstance: if you configure your repository so that it only allows read access for that particular key, and you don't bother about the repository being publicly readable. In this case, you can easily store your private key - obviously make a throwaway key without passphrase. But as I said, only if you are fine with public access to that repository.

If that is not the case, then you are probably stuck with the SSH agent. It is not ideal, as root can take the socket, but if you are in a kind of benevolent environment (i.e., no attackable webserver anywhere near), then it should be OK.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.