On 20/05/2015 23:06, Stefan G. Weichinger wrote: > > I am currently trying to slim down and minimize my own few machines. > > Way too much customer servers out there so I'd like to keep it simple in > here at least. > > This lead me to configuring and provisioning my machines via ansible. > > The goals: > > * make sure that my user exists > * roll out configs/dotfiles/git-repos/home-dir > * maybe roll out some system-configs as well (systemd-units, timers) / > ... separate ansible-role, OT here > > etc > > I have set up and maintained quite a list of bash-aliases to access my > customer-servers in daily work. > > Something like: > > alias abcd-server='ssh -p 51023 174.183.26.11' # demo only > > This is based on ssh-pubkey-authentication, sure. > > My questions: > > * if I have a user X on each machine, should each userX@machine have its > own ssh-pubkey? Or is it OK to roll out the same ~/.ssh to all machines? > > * same q for ~/.gnupg ... > > I can deploy the pubkeys to the servers via ansible, sure. > But I would like to keep it simple. stupid. > > ;) >
My opinion on this question is that it's irrelevant really. Whether you have one or X key pairs really doesn't matter, as you effectively only have one from a security POV. What do I mean by that? Well, all your private keys are likely in one place, ~/.ssh on your own workstation, as it doesn't scale well to do it any other way. You probably store the passphrase for all keys in the same wallet, all protected by the same password. Let's be honest, we *all* do it like this :-) So effectively we do not have X keys, we have 1 key as they are all protected by the same thing. >From a convenience POV, managing multiple keys is a huge PITA and there's no fast, accurate simple way to tell them apart. You have to store them in different places, or examine the trailing comment in each. My usual recommendation is to use the same key for everything, except those servers where you have a very good reason not to. Examples might be a customer contract where you agreed to deploy a unique key used nowhere else, or an exceptional machine with exceptional security needs. Or even an ancient machine that you can't update that can only use ssh-1 keys :-) Limit the number of things you have to keep in your head, that let's you focus on improving a smaller number of security aspects and is also more convenient. Additionally, the simpler your policy rules, the easier it is to write an ansible play to implement them. -- Alan McKinnon [email protected]
