Okay. Out of interest, do you have any idea on how you would design a configuration management that works without root access to all of the machines you want to configure?

The problem isn't exactly with root (configuration management has root-like privileges), but push vs pull.

Both rely on the confidentiality of a private key on the master (the server identity if it is a pull, client identity if it is a push), but to fool a pull you also have to subvert the dns or the routing. Using ssh certificates that expire and are tied to the master's address would be a good first step making push safer against key interception.

If someone can find a way to write to your master change management repo, you're boned. (Is it sitting on NFS? If so, you may have a problem!) If someone roots the master box that you're pushing from or that your clients are pulling from, you're boned.

Technically you don't have to use root anywhere. You can push from a master box as an unpriviledged user and specify any user on the target machine to connect as, and ssh keys (along with an agent) will take care of the rest. The target machine doesn't need to be running your config management as root, you just need to set up a config management account with rights to the users/groups that your services are running. Your service may get compromised but root wouldn't - until they run a local priv escalation 0day.

I think you're confused. Since the tools are using either SSL or SSH these protocols (when properly implemented) prevent mitm or spoofing attacks on things like dns or routing protocols. Your key does not get intercepted, ever, because you're never sending a private key. But some machine, somewhere, has to have keys or you can't log in.

The only thing you have to worry about is someone getting both the keys AND access to a server that's running an agent that you've authed with. If you're super duper paranoid ssh-agent has an option to never cache a given key's authorization so it can ask you for the password for the key every time you use it. I'm pretty sure that would be super annoying, though, so better to just run one agent once for an entire batch push/deployment and kill it once your job is done.

In reply to your earlier comment, it's a configuration management precisely because it has root - not irrelevant!

That's a distraction though - gizzlon is right that it is extremely bad practice to recommend people keep unprotected keys to root accounts on a personal computer.

Using passphrases and ssh-agent is a good and widely accepted solution to this problem (along with gizzlon's advice of having someone peer-review the code, again very standard and obvious).

well, at first glance pull seems much safer: All the machines can log in as special (non-root) user at _one_ server and fetch commands to run.

If the master server is compromised, all the other servers might* be as well, but at least you're not spreading root@ ssh keys around.

* Maybe it's possible to predefine functions on the client and only ever run those. In practice that probably won't work because those functions will be either not powerful enough, or easy to misuse.