| 1 |
On 21.05.2015 00:02, Alan McKinnon wrote: |
| 2 |
> On 20/05/2015 23:06, Stefan G. Weichinger wrote: |
| 3 |
>> |
| 4 |
>> I am currently trying to slim down and minimize my own few machines. |
| 5 |
>> |
| 6 |
>> Way too much customer servers out there so I'd like to keep it simple in |
| 7 |
>> here at least. |
| 8 |
>> |
| 9 |
>> This lead me to configuring and provisioning my machines via ansible. |
| 10 |
>> |
| 11 |
>> The goals: |
| 12 |
>> |
| 13 |
>> * make sure that my user exists |
| 14 |
>> * roll out configs/dotfiles/git-repos/home-dir |
| 15 |
>> * maybe roll out some system-configs as well (systemd-units, timers) / |
| 16 |
>> ... separate ansible-role, OT here |
| 17 |
>> |
| 18 |
>> etc |
| 19 |
>> |
| 20 |
>> I have set up and maintained quite a list of bash-aliases to access my |
| 21 |
>> customer-servers in daily work. |
| 22 |
>> |
| 23 |
>> Something like: |
| 24 |
>> |
| 25 |
>> alias abcd-server='ssh -p 51023 174.183.26.11' # demo only |
| 26 |
>> |
| 27 |
>> This is based on ssh-pubkey-authentication, sure. |
| 28 |
>> |
| 29 |
>> My questions: |
| 30 |
>> |
| 31 |
>> * if I have a user X on each machine, should each userX@machine have its |
| 32 |
>> own ssh-pubkey? Or is it OK to roll out the same ~/.ssh to all machines? |
| 33 |
>> |
| 34 |
>> * same q for ~/.gnupg ... |
| 35 |
>> |
| 36 |
>> I can deploy the pubkeys to the servers via ansible, sure. |
| 37 |
>> But I would like to keep it simple. stupid. |
| 38 |
>> |
| 39 |
>> ;) |
| 40 |
>> |
| 41 |
> |
| 42 |
> |
| 43 |
> My opinion on this question is that it's irrelevant really. Whether you |
| 44 |
> have one or X key pairs really doesn't matter, as you effectively only |
| 45 |
> have one from a security POV. |
| 46 |
> |
| 47 |
> What do I mean by that? Well, all your private keys are likely in one |
| 48 |
> place, ~/.ssh on your own workstation, as it doesn't scale well to do it |
| 49 |
> any other way. You probably store the passphrase for all keys in the |
| 50 |
> same wallet, all protected by the same password. Let's be honest, we |
| 51 |
> *all* do it like this :-) |
| 52 |
> |
| 53 |
> So effectively we do not have X keys, we have 1 key as they are all |
| 54 |
> protected by the same thing. |
| 55 |
> |
| 56 |
> From a convenience POV, managing multiple keys is a huge PITA and |
| 57 |
> there's no fast, accurate simple way to tell them apart. You have to |
| 58 |
> store them in different places, or examine the trailing comment in each. |
| 59 |
> |
| 60 |
> My usual recommendation is to use the same key for everything, except |
| 61 |
> those servers where you have a very good reason not to. Examples might |
| 62 |
> be a customer contract where you agreed to deploy a unique key used |
| 63 |
> nowhere else, or an exceptional machine with exceptional security needs. |
| 64 |
> Or even an ancient machine that you can't update that can only use ssh-1 |
| 65 |
> keys :-) Limit the number of things you have to keep in your head, that |
| 66 |
> let's you focus on improving a smaller number of security aspects and is |
| 67 |
> also more convenient. |
| 68 |
> |
| 69 |
> Additionally, the simpler your policy rules, the easier it is to write |
| 70 |
> an ansible play to implement them. |
| 71 |
|
| 72 |
Thanks a lot for your statement, this is similar to what I think about |
| 73 |
it. I just want to avoid to run into a stupid mistake here. |
| 74 |
|
| 75 |
So I will take the ssh-keys of my main desktop, for my personal user sgw |
| 76 |
and for root and deploy them on my machines (2 thinkpads, one desktop). |
| 77 |
I can add that to my provisioning-role I currently work on. |
| 78 |
|
| 79 |
I already have an ansible playbook that rolls out ssh-pubkeys to all the |
| 80 |
customer servers I have to maintain. So far I pushed 7 separate keys out |
| 81 |
there ... |
Archives