4:11 p.m.
Hi all,
Need some feedback. Since I've been playing with/working on
ansible(http://ansible.github.com) it has raised some questions as to
what we will allow/not allow for setting up hosts.
Here's what I'd like to do:
1. allow lockbox01-only and ssh-key-only access, as root, via ssh to
our systems. This would be an ssh key only on lockbox and owned by root
(or possibly by sysadmin-main or other localgroup - like the private
git repo).
2. have the root authorized_keys be available from
infrastructure.fedoraproject.org via http (restricted to the hosts we
allow, of course)
3. setup our kickstart %post to suck down these keys.
This will enable me to streamline our installation process
considerably. Right now there are a number of manual steps in our
reinstall process. These manual steps are.... errorprone. I'd like to
eliminate them.
Right now we expose access to our systems via func - which is a daemon
running as root which auth's using the puppet ssl cert/keys from
lockbox01. The change to allowing ssh-in as root is not a considerably
larger attack surface. The only exception is that ssh is available to
various places for some of our systems, while func's ports are not.
I'd like to hear some thoughts on making this change. If no one objects
then I'll make this happen.
thanks,
-sv
4:37 p.m.
On Tue, 10 Apr 2012 17:11:14 -0400
seth vidal <skvidal(a)fedoraproject.org> wrote:
Hi all,
Need some feedback. Since I've been playing with/working on
ansible(http://ansible.github.com) it has raised some questions as to
what we will allow/not allow for setting up hosts.
Here's what I'd like to do:
1. allow lockbox01-only and ssh-key-only access, as root, via ssh to
our systems. This would be an ssh key only on lockbox and owned by
root (or possibly by sysadmin-main or other localgroup - like the
private git repo).
2. have the root authorized_keys be available from
infrastructure.fedoraproject.org via http (restricted to the hosts we
allow, of course)
3. setup our kickstart %post to suck down these keys.
This will enable me to streamline our installation process
considerably. Right now there are a number of manual steps in our
reinstall process. These manual steps are.... errorprone. I'd like to
eliminate them.
...snip...
So, to be clear this is not replacing puppet or anything, simply making
our re-install/installs more automated, right?
I'm ok with this. We should also make sure access using this is logged
and appears in our usual reports so we can keep an eye on it.
kevin
4:38 p.m.
On Tue, Apr 10, 2012 at 05:11:14PM -0400, seth vidal wrote:
1. allow lockbox01-only and ssh-key-only access, as root, via ssh to
our systems. This would be an ssh key only on lockbox and owned by root
I'm no fan of passphrase-less ssh-keys.. as they turn read-random-file
vulnerabilities into full root exploits.
Wouldn't it be better to have root's authorized_keys file contain the
pubkeys of each individual admin that should be allowed to ssh from
lockbox01 (prefixed with from=lockbox01 of course) ? Or is this too much
hassle to maintain?
-jf
10:25 p.m.
On Tue, 10 Apr 2012 23:38:30 +0200
Jan-Frode Myklebust <janfrode(a)tanso.net> wrote:
On Tue, Apr 10, 2012 at 05:11:14PM -0400, seth vidal wrote:
>
> 1. allow lockbox01-only and ssh-key-only access, as root, via ssh to
> our systems. This would be an ssh key only on lockbox and owned by
> root
I'm no fan of passphrase-less ssh-keys.. as they turn
read-random-file vulnerabilities into full root exploits.
Wouldn't it be better to have root's authorized_keys file contain the
pubkeys of each individual admin that should be allowed to ssh from
lockbox01 (prefixed with from=lockbox01 of course) ? Or is this too
much hassle to maintain?
I'm not sure how having and managing N-keys is better than having and
managing 1-Key.
Either way you have to manage/maintain the key(s). And instead of
having 1 key you have to protect from theft/compromise you have N-keys
to protect from theft/compromise.
-sv
10:54 p.m.
On Tue, Apr 10, 2012 at 11:25:46PM -0400, seth vidal wrote:
>
> Wouldn't it be better to have root's authorized_keys file contain the
> pubkeys of each individual admin that should be allowed to ssh from
> lockbox01 (prefixed with from=lockbox01 of course) ? Or is this too
> much hassle to maintain?
>
I'm not sure how having and managing N-keys is better than having and
managing 1-Key.
The N-keys are (according to policy,
http://lists.fedoraproject.org/pipermail/announce/2011-October/003005.html):
NEVER stored on a shared system.
ALWAYS using a strong passphrase
while the 1-key breaks these. The N-keys are already managed and
trusted. The 1-key is an addition that only loosens security.
Either way you have to manage/maintain the key(s). And instead of
having 1 key you have to protect from theft/compromise you have N-keys
to protect from theft/compromise.
The N-keys are already managed/maintained by your sysadmins. You only need
to additionally manage the public parts for the distributed authorized_keys.
-jf
11:14 p.m.
On Wed, 11 Apr 2012 05:54:16 +0200
Jan-Frode Myklebust <janfrode(a)tanso.net> wrote:
On Tue, Apr 10, 2012 at 11:25:46PM -0400, seth vidal wrote:
> >
> > Wouldn't it be better to have root's authorized_keys file contain
> > the pubkeys of each individual admin that should be allowed to
> > ssh from lockbox01 (prefixed with from=lockbox01 of course) ? Or
> > is this too much hassle to maintain?
> >
>
> I'm not sure how having and managing N-keys is better than having
> and managing 1-Key.
The N-keys are (according to policy,
http://lists.fedoraproject.org/pipermail/announce/2011-October/003005.html):
NEVER stored on a shared system.
ALWAYS using a strong passphrase
while the 1-key breaks these. The N-keys are already managed and
trusted. The 1-key is an addition that only loosens security.
> Either way you have to manage/maintain the key(s). And instead of
> having 1 key you have to protect from theft/compromise you have
> N-keys to protect from theft/compromise.
The N-keys are already managed/maintained by your sysadmins. You only
need to additionally manage the public parts for the distributed
authorized_keys.
okay - I think you've misunderstood me.
I would like to allow us to have a root ssh key.
This key would only exist on lockbox01.
This key would be protected.
so if an admin wanted to do something with this key they would need to:
1. login to bastion
2. login to lockbox
3. sudo as root to run the command
1 and 2 require their own key
3 requires their password and, potentially, the password to the
root key.
What does any of the above have to do with the policy about users ssh
keys?
-sv
4:48 p.m.
On 10/04/12 22:11, seth vidal wrote:
Hi all,
Need some feedback. Since I've been playing with/working on
ansible(http://ansible.github.com) it has raised some questions as to
what we will allow/not allow for setting up hosts.
Here's what I'd like to do:
1. allow lockbox01-only and ssh-key-only access, as root, via ssh to
our systems. This would be an ssh key only on lockbox and owned by root
(or possibly by sysadmin-main or other localgroup - like the private
git repo).
2. have the root authorized_keys be available from
infrastructure.fedoraproject.org via http (restricted to the hosts we
allow, of course)
3. setup our kickstart %post to suck down these keys.
This will enable me to streamline our installation process
considerably. Right now there are a number of manual steps in our
reinstall process. These manual steps are.... errorprone. I'd like to
eliminate them.
Right now we expose access to our systems via func - which is a daemon
running as root which auth's using the puppet ssl cert/keys from
lockbox01. The change to allowing ssh-in as root is not a considerably
larger attack surface. The only exception is that ssh is available to
various places for some of our systems, while func's ports are not.
I'd like to hear some thoughts on making this change. If no one objects
then I'll make this happen.
thanks,
-sv
_______________________________________________
infrastructure mailing list
infrastructure(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
I must say, ansible
does look interesting. Just the whole sshd thing
kinda is a put off. But I will look into this a bit more the next days.
But it does most certainly sound like a good effort (the start of).
And Michael is once again involved in a very interesting project, that
should turn out to be very useful indeed.
Thanks for bringing this to our attention.
Regards,
Tristan
--
Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile +44-78-55069812
Tristan.Santore(a)internexusconnect.net
Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)
For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org
5:20 p.m.
On Tue, 10 Apr 2012 22:48:04 +0100
Tristan Santore <tristan.santore(a)internexusconnect.net> wrote:
I must say, ansible does look interesting. Just the whole sshd thing
kinda is a put off. But I will look into this a bit more the next
days. But it does most certainly sound like a good effort (the start
of).
Why is sshd a put off? sshd makes sense if only for
provisioning/deployment b/c it is available for ever cloud instance
ever spun up - and for the overwhelming majority of systems I've ever
touched.
-sv
5:34 p.m.
On 10 April 2012 15:48, Tristan Santore
<tristan.santore(a)internexusconnect.net> wrote:
On 10/04/12 22:11, seth vidal wrote:
>
I must say, ansible does look interesting. Just the whole sshd thing
kinda is a put off. But I will look into this a bit more the next days.
But it does most certainly sound like a good effort (the start of).
And Michael is once again involved in a very interesting project, that
should turn out to be very useful indeed.
Coming from the old school.. I had this initial reaction.. I am
letting a root login from a system on the internet.. but then I
realized that in reality this does not seem any less secure than the
puppet or similar setups. If the ssh key is "gotten" it is no less a
problem than if the puppet ssl keys are gotten, and possibly less
likely to be auditable.
I think in this case a look at why you feel uncomfortable needs to be
written out a bit more to make sure if it is a "well we didn't think
of that scenario" or a "well for 10+ years I have made sure ssh wasn't
root loggable or autopassworded in and this makes me feel icky." type
feeling.
Thanks for bringing this to our attention.
Regards,
Tristan
--
Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile +44-78-55069812
Tristan.Santore(a)internexusconnect.net
Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)
For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org
_______________________________________________
infrastructure mailing list
infrastructure(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
6:26 p.m.
Hi,
some apprentice feedback!
I'm not a puppet user (except from fedora) but i use a similar logic product
(quattor). Of course the case of puppet ssl keys to be "gotten" has typically
the same results as a ssh key that provides root access to all nodes but the risk is not
always the same. Explaining myself, there are much more automated attacks that can use a
ssh key (i.e. combined with the hosts in authorized_keys) in no time, while using the
puppet way will most probably be a targeted attack (not saying though that fedora's
infrastructure doesn't qualify as target).
Haven't check the whole documentation yet but doesn't this thing allow usage of
ssh key agents? if so it would be much much better if the key is encrypted.
We use something similar (pdsh) for our fabric and practice revealed that following
additions to the authorized_keys made audit much easier:
a) have a "from=lockbox01" as Jan-Frode already mentioned
b) have a simple script in "command=" that will log remotely executed commands,
i use the following (logging directly to my mailbox):
command="echo Executed command: ${SSH_ORIGINAL_COMMAND:-$SHELL}| mail -s \"root
key usage at `hostname -f`\" my(a)e.mail && exec
${SSH_ORIGINAL_COMMAND:-$SHELL}"
This way even if the attacker manages to get the key AND the passphrase AND have access to
the node that is allowed to use it, his action will at least be logged.
Regards,
Christos
On Apr 11, 2012, at 1:34 AM, Stephen John Smoogen wrote:
On 10 April 2012 15:48, Tristan Santore
<tristan.santore(a)internexusconnect.net> wrote:
> On 10/04/12 22:11, seth vidal wrote:
>>
> I must say, ansible does look interesting. Just the whole sshd thing
> kinda is a put off. But I will look into this a bit more the next days.
> But it does most certainly sound like a good effort (the start of).
>
> And Michael is once again involved in a very interesting project, that
> should turn out to be very useful indeed.
Coming from the old school.. I had this initial reaction.. I am
letting a root login from a system on the internet.. but then I
realized that in reality this does not seem any less secure than the
puppet or similar setups. If the ssh key is "gotten" it is no less a
problem than if the puppet ssl keys are gotten, and possibly less
likely to be auditable.
I think in this case a look at why you feel uncomfortable needs to be
written out a bit more to make sure if it is a "well we didn't think
of that scenario" or a "well for 10+ years I have made sure ssh wasn't
root loggable or autopassworded in and this makes me feel icky." type
feeling.
> Thanks for bringing this to our attention.
>
> Regards,
>
> Tristan
>
> --
> Tristan Santore BSc MBCS
> TS4523-RIPE
> Network and Infrastructure Operations
> InterNexusConnect
> Mobile +44-78-55069812
> Tristan.Santore(a)internexusconnect.net
>
> Former Thawte Notary
> (Please note: Thawte has closed its WoT programme down,
> and I am therefore no longer able to accredit trust)
>
> For Fedora related issues, please email me at:
> TSantore(a)fedoraproject.org
> _______________________________________________
> infrastructure mailing list
> infrastructure(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/infrastructure
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
_______________________________________________
infrastructure mailing list
infrastructure(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
4408
days inactive
4409
days old
infrastructure@lists.fedoraproject.org
10 comments
6 participants
participants (6)
-
Christos Triantafyllidis -
Jan-Frode Myklebust -
Kevin Fenzi -
Seth Vidal -
Stephen John Smoogen -
Tristan Santore