public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-user] user config provisioning
@ 2015-05-20 21:06 Stefan G. Weichinger
  2015-05-20 22:02 ` Alan McKinnon
  2015-05-21  8:49 ` Paul Tobias
  0 siblings, 2 replies; 9+ messages in thread
From: Stefan G. Weichinger @ 2015-05-20 21:06 UTC (permalink / raw
  To: gentoo-user


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.

;)


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-user] user config provisioning
  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  8:49 ` Paul Tobias
  1 sibling, 1 reply; 9+ messages in thread
From: Alan McKinnon @ 2015-05-20 22:02 UTC (permalink / raw
  To: gentoo-user

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@gmail.com



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-user] user config provisioning
  2015-05-20 21:06 [gentoo-user] user config provisioning Stefan G. Weichinger
  2015-05-20 22:02 ` Alan McKinnon
@ 2015-05-21  8:49 ` Paul Tobias
  2015-05-21 13:13   ` Stefan G. Weichinger
  1 sibling, 1 reply; 9+ messages in thread
From: Paul Tobias @ 2015-05-21  8:49 UTC (permalink / raw
  To: gentoo-user

On 20 May 2015 22:08, "Stefan G. Weichinger" <lists@xunil.at> wrote:
>
> alias abcd-server='ssh -p 51023 174.183.26.11'  # demo only

Instead of aliases,  you can put this into ~/. ssh/config:
Host abcd
  Port 51023
  Hostname 174.183.26.11

And then you can simply do this:
ssh abcd

As a bonus, the host abcd will work with scp and rsync too. You can
check man ssh_config for some other options to use, for example the
User is very useful too. Here are some more tricks:
https://blog.flameeyes.eu/2011/01/mostly-unknown-openssh-tricks

There is a package net-misc/keychain which is useful to add your keys
to the agent, and handles gpg keys too.

Also note that most ssh servers allow only 3-5 authentication
attempts, so if you have more than 2 keys in your agent, then
connecting to a server with password authentication might fail.

If you need to keep security boundaries but don't want to give up the
convenience of ssh agent forwarding then you can use ssh-ident, as
described here: http://rabexc.org/posts/pitfalls-of-ssh-agents
(unfortunately no gentoo package for that one, but it's just a single
python file).

Have a nice day,
Paul


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-user] user config provisioning
  2015-05-20 22:02 ` Alan McKinnon
@ 2015-05-21 11:28   ` Stefan G. Weichinger
  2015-05-21 13:10     ` Alan McKinnon
  0 siblings, 1 reply; 9+ messages in thread
From: Stefan G. Weichinger @ 2015-05-21 11:28 UTC (permalink / raw
  To: gentoo-user

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 ...



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-user] user config provisioning
  2015-05-21 11:28   ` Stefan G. Weichinger
@ 2015-05-21 13:10     ` Alan McKinnon
  2015-05-21 14:00       ` Stefan G. Weichinger
  0 siblings, 1 reply; 9+ messages in thread
From: Alan McKinnon @ 2015-05-21 13:10 UTC (permalink / raw
  To: gentoo-user

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-user] user config provisioning
  2015-05-21  8:49 ` Paul Tobias
@ 2015-05-21 13:13   ` Stefan G. Weichinger
  2015-05-21 15:04     ` Stefan G. Weichinger
  0 siblings, 1 reply; 9+ messages in thread
From: Stefan G. Weichinger @ 2015-05-21 13:13 UTC (permalink / raw
  To: gentoo-user

On 21.05.2015 10:49, Paul Tobias wrote:
> On 20 May 2015 22:08, "Stefan G. Weichinger" <lists@xunil.at> wrote:
>>
>> alias abcd-server='ssh -p 51023 174.183.26.11'  # demo only
> 
> Instead of aliases,  you can put this into ~/. ssh/config:
> Host abcd
>   Port 51023
>   Hostname 174.183.26.11
> 
> And then you can simply do this:
> ssh abcd
> 
> As a bonus, the host abcd will work with scp and rsync too. 

Yes, I knew of that.

I have to think what is better ... maybe really your suggested way of
doing it.

I just have to "convert" my aliases once ...

> You can
> check man ssh_config for some other options to use, for example the
> User is very useful too. Here are some more tricks:
> https://blog.flameeyes.eu/2011/01/mostly-unknown-openssh-tricks
> 
> There is a package net-misc/keychain which is useful to add your keys
> to the agent, and handles gpg keys too.

I have that on my systems, yes.

> Also note that most ssh servers allow only 3-5 authentication
> attempts, so if you have more than 2 keys in your agent, then
> connecting to a server with password authentication might fail.

ok, good to have that in mind, yes

> If you need to keep security boundaries but don't want to give up the
> convenience of ssh agent forwarding then you can use ssh-ident, as
> described here: http://rabexc.org/posts/pitfalls-of-ssh-agents
> (unfortunately no gentoo package for that one, but it's just a single
> python file).

thanks! nice hints ... I will take a closer look later when I fixed that
logjam-stuff on web and mailservers ....

nice day to you as well, Stefan



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-user] user config provisioning
  2015-05-21 13:10     ` Alan McKinnon
@ 2015-05-21 14:00       ` Stefan G. Weichinger
  0 siblings, 0 replies; 9+ messages in thread
From: Stefan G. Weichinger @ 2015-05-21 14:00 UTC (permalink / raw
  To: gentoo-user

On 21.05.2015 15:10, Alan McKinnon wrote:

> I didn't realize you want to deploy keys for root. Is that root on your
> local machine, or root on the remote machines?

both ... mixed and grown setup

> Either way, that part *does* need some thinking through.

yes! I knew it ;-)

> 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

hm. so much work all around.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-user] user config provisioning
  2015-05-21 13:13   ` Stefan G. Weichinger
@ 2015-05-21 15:04     ` Stefan G. Weichinger
  2015-05-21 15:41       ` Stefan G. Weichinger
  0 siblings, 1 reply; 9+ messages in thread
From: Stefan G. Weichinger @ 2015-05-21 15:04 UTC (permalink / raw
  To: gentoo-user

On 21.05.2015 15:13, Stefan G. Weichinger wrote:
> On 21.05.2015 10:49, Paul Tobias wrote:

>> Instead of aliases,  you can put this into ~/. ssh/config:
>> Host abcd
>>   Port 51023
>>   Hostname 174.183.26.11

> I have to think what is better ... maybe really your suggested way of
> doing it.
> 
> I just have to "convert" my aliases once ...

would be nice to somehow make use of ansibles inventory here as well.
Same content in my case.

Right now I edit through my new .ssh/config ;)



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-user] user config provisioning
  2015-05-21 15:04     ` Stefan G. Weichinger
@ 2015-05-21 15:41       ` Stefan G. Weichinger
  0 siblings, 0 replies; 9+ messages in thread
From: Stefan G. Weichinger @ 2015-05-21 15:41 UTC (permalink / raw
  To: gentoo-user


>> On 21.05.2015 10:49, Paul Tobias wrote:
> 
>>> Instead of aliases,  you can put this into ~/. ssh/config:
>>> Host abcd
>>>   Port 51023
>>>   Hostname 174.183.26.11

oh, yes, that is *much* better than my old aliases ... !

Thanks for the reminder, should have done that long ago.

The working scp really is a huge improvement (especially as I have a lot
of strange ports because of port-forwardings).




^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2015-05-21 15:41 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox