On 21/05/2015 13:28, Stefan G. Weichinger wrote: > On 21.05.2015 00:02, Alan McKinnon wrote: >> 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. > > Thanks a lot for your statement, this is similar to what I think about > it. I just want to avoid to run into a stupid mistake here. > > So I will take the ssh-keys of my main desktop, for my personal user sgw > and for root and deploy them on my machines (2 thinkpads, one desktop). > I can add that to my provisioning-role I currently work on. > > I already have an ansible playbook that rolls out ssh-pubkeys to all the > customer servers I have to maintain. So far I pushed 7 separate keys out > there ... > >
I didn't realize you want to deploy keys for root. Is that root on your local machine, or root on the remote machines? Either way, that part *does* need some thinking through. For automation involving root permissions, I prefer to use a remote system (non-root) account and give it the needed permissions in /etc/sudoers, being careful to disallow sudo -i, sudo su, and friends -- Alan McKinnon [email protected]
