From: Alan McKinnon <alan.mckinnon@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] user config provisioning
Date: Thu, 21 May 2015 15:10:53 +0200 [thread overview]
Message-ID: <555DD95D.2070603@gmail.com> (raw)
In-Reply-To: <555DC141.2030200@xunil.at>
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
alan.mckinnon@gmail.com
next prev parent reply other threads:[~2015-05-21 13:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 21:06 [gentoo-user] user config provisioning Stefan G. Weichinger
2015-05-20 22:02 ` Alan McKinnon
2015-05-21 11:28 ` Stefan G. Weichinger
2015-05-21 13:10 ` Alan McKinnon [this message]
2015-05-21 14:00 ` Stefan G. Weichinger
2015-05-21 8:49 ` Paul Tobias
2015-05-21 13:13 ` Stefan G. Weichinger
2015-05-21 15:04 ` Stefan G. Weichinger
2015-05-21 15:41 ` Stefan G. Weichinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=555DD95D.2070603@gmail.com \
--to=alan.mckinnon@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox