Part of a system's security is to reduce the attack surface. Following this principle,
I want to see if I can switch from using regular salt minions for a saltstack managed
system set towards
salt-ssh. This would allow to do some system management over SSH
instead of ZeroMQ.
I'm not confident yet that this is a solid approach to take (as performance is also
important, which is greatly reduced with
salt-ssh), and the security exposure of the
salt minions over ZeroMQ is also not that insecure (especially not when a local firewall
ensures that only connections from the salt master are allowed). But playing doesn't hurt.
Using SSH agent forwarding
Anyway, I quickly got stuck with accessing minions over the SSH interface as it seemed that salt requires its own SSH keys (I don't enable password-only authentication, most of the systems use the AuthenticationMethods approach to chain both key and passwords). But first things first, the current target uses regular ssh key authentication (no chained approach, that's for later). But I don't want to assign such a powerful key to my salt master (especially not if it would later also document the passwords). I would like to use SSH agent forwarding.
Luckily, salt does support that, it just forgot to document
it. Basically, what you need to do is update the roster file with the
myminion: host: myminion.example.com priv: agent-forwarding
It will use the
known_hosts file of the currently logged on user (the one executing
salt-ssh command) so make sure that the system's key is already known.
~$ salt-ssh myminion test.ping myminion: True