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