Re: [gentoo-user] user config provisioning

[Alan McKinnon]

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
alan.mckinnon@×××××.com