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
On Tue, 10 Apr 2012 17:11:14 -0400 seth vidal skvidal@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:
- 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).
- have the root authorized_keys be available from
infrastructure.fedoraproject.org via http (restricted to the hosts we allow, of course)
- 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
On Tue, 10 Apr 2012 15:37:18 -0600 Kevin Fenzi kevin@scrye.com wrote:
...snip...
So, to be clear this is not replacing puppet or anything, simply making our re-install/installs more automated, right?
Not yet, no.
long term I would like to kill it with fire.
-sv
On Tue, Apr 10, 2012 at 05:11:14PM -0400, seth vidal wrote:
- 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
On Tue, 10 Apr 2012 23:38:30 +0200 Jan-Frode Myklebust janfrode@tanso.net wrote:
On Tue, Apr 10, 2012 at 05:11:14PM -0400, seth vidal wrote:
- 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
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
On Wed, 11 Apr 2012 05:54:16 +0200 Jan-Frode Myklebust janfrode@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
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:
- 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).
- have the root authorized_keys be available from
infrastructure.fedoraproject.org via http (restricted to the hosts we allow, of course)
- 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@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
On Tue, 10 Apr 2012 22:48:04 +0100 Tristan Santore tristan.santore@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
On 10 April 2012 15:48, Tristan Santore tristan.santore@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@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@fedoraproject.org _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
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@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@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@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@fedoraproject.org _______________________________________________ infrastructure mailing list infrastructure@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
infrastructure@lists.fedoraproject.org