I am currently automating the setup of a web server with Ansible. My two team mates should be able to run the Ansible playbook as well. Therefore, their public keys need to be added to the authorized_keys of the user that will execute the Ansible tasks on the target host.

Ansible has even built-in support for this with the ansible.posix.authorized_keys module.

However, I've one concern: What if those keys are accidentally copied to an unrelated server? In this case, my team mates would gain access to a machine they should not have access to.

I can easily imagine scenarios where this would be the case.

For example: What if the repository (with the Ansible playbook and the public keys) gets copied over to a new project as a starting point? You might forget removing the public keys from the new project and accidentally run the playbook. Then, those public keys would "silently" be added to the new host, thereby permitting access for unauthorized persons to the respective host.

Should I be concerned? Is it even a common cause of security incidents? If yes, how to deal with that?

I came up with these the two options until now:

  1. Ignore the public keys in git. Still, the repo could be copied locally. But it's less likely than the case of the repo being cloned from a central git server.
  2. Require the keys to be transferred to the server manually. This degrades automation a bit, but is possibly negligible in our situation with a team of three.
  • 1
    OpenSSH requires authorized_keys to be RW only by the user it belongs to. So, for you team mates to be able to add a key to such a file, either they are root (in which case, you already gave them full control) or they already have an interactive shell as a local user in the machine (in which case, you already gave them a login shell). If you are automating key distribution with Ansible, then you should look into a software that let you record users (and their keys) and hosts and that can be queried by Ansible. Commented Apr 24 at 7:10
  • 1
    Git doesn't seem the right tool and at the end of the day copying the wrong key means given an authorized access to a server. Also, there is probably a PAM module to manage user authentication centrally. Commented Apr 24 at 7:10
  • Thx @MargaretBloom, agree. What I've learned in the meantime is that something like HashiCorp Vault would be such a central piece of software.
    – rmoestl
    Commented Apr 24 at 9:09

3 Answers 3


Tampering with autorized_keys by insiders can be mitigated by switching to CA certification. SSH has built-in support for this.

  • "Tampering by insiders" implies malicious behavior, but that's a different story, imho. My concern is really the accidental case.
    – rmoestl
    Commented Apr 24 at 5:53
  • Have to revert my previous comment. Storing keys in a git repo also enables malicious activities. +1 for mentioning CA certification.
    – rmoestl
    Commented Apr 24 at 9:10

Yes, I am concerned, but not in the way you might htink.

I'm a big opponent of letting anybody log in as root, as it removes your audit trail. (I also recommend PermitRootLogin no in /etc/ssh/sshd_config to reduce your attack surface.) Instead, users should log in with their own unprivileged accounts and use sudo to escalate as needed. More sophisticated setups can ensure that only a handful of actions can be done as root and other actions are permitted by escalating to different accounts. This prevents users from creating backdoors for themselves.

By requiring users to log in as themselves, you must also propagate their accounts. If somebody accidentally grants those accounts to all systems, they'd also have to propagate the keys and the sudo permissions (be they by unix group or by sudoers file). This is far from "silent".

If that's still insufficient, you might want to implement a code review process for this sort of work.

  • The question doesn't imply they all log in as root, nor does it imply that PermitRootLogin no isn't used. Still, appreciate your answer @adam.
    – rmoestl
    Commented Apr 24 at 5:50
  • So then you're concerned with accidental propagation of accounts with sudo access and SSH keys? That's a pretty big accident. Require a code review process for changes.
    – Adam Katz
    Commented Apr 24 at 14:16
  • sudo is auditable for privileged tasks on Linux/Unix, su is not. wheel group members are authorized to use sudo in /etc/sudoers. Selinux staff_u users cannot use su. Commented Apr 24 at 16:48

You don't provide context. It is hard to say what are the risks.

Consider following:

  • Accounting: The reasons why particular user needs particular permissions for particular system should be documented.
  • Accounting: Who and when granted these permissions to the particular user.
  • Permissions should be time limited.
  • Only limited set of persons (administrators) should be able to manage permissions.

Your current approach does not meet any of these requirements. That's why your idea to install keys manually will improve that.

You need some system where permissions should be documented. They should be regularly reviewed. If there is no reason for permissions any more (e.g. user is working on other tasks or user doesn't work at the company any more), they should be removed. E.g. remove the key, remove the user from the group that is allowed to use SSH access.

  • Thanks, you're right with the considerations pointed out. Got a little bit more educated on that stuff and the problem I described can be summed up as secrets sprawl. At least that's how HashiCorp Vault calls it. So Vault is obviously a solution to my concerns.
    – rmoestl
    Commented Apr 24 at 9:06
  • Hashicorp Vault can nicely manage the SSH CA Certification for you. My answer was a bit concise. Commented Apr 24 at 16:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .