12:41 p.m.
On Wed, 12 Oct 2011 13:30:19 -0400
Jeff Layton <jlayton(a)redhat.com> wrote:
I have a question not covered here: I just changed my ssh key a week
or two ago in the wake of the kernel.org compromise...
Is my new key sufficient? I really don't want to have to re-distribute
my key to all of the various servers again.
Well, we talked about this some, but we don't have fingerprints from
several weeks ago to check people against to confirm they uploaded a
new key.
Would it be possible for you to just make a new fedora only key?
Then you only need to upload that to fedora and set your .ssh/config to
use that key for *.fedoraproject.org/fedorapeople.org.
kevin
12:45 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 11:41 -0600, Kevin Fenzi wrote:
On Wed, 12 Oct 2011 13:30:19 -0400
Jeff Layton <jlayton(a)redhat.com> wrote:
> I have a question not covered here: I just changed my ssh key a week
> or two ago in the wake of the kernel.org compromise...
>
> Is my new key sufficient? I really don't want to have to re-distribute
> my key to all of the various servers again.
Well, we talked about this some, but we don't have fingerprints from
several weeks ago to check people against to confirm they uploaded a
new key.
Would it be possible for you to just make a new fedora only key?
Can you stop asking useless security theater measures instead ?
My ssh keys are fine and I see no reason to change them for you.
If all projects I participate in were to ask me to change my keys I
would end up with a mess of different keys for absolutely no reason.
I have no problem with changing the password, but leave my ssh keys
alone, unless there is a real reason to ask people to change them.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
12:53 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 13:45 -0400, Simo Sorce wrote:
I have no problem with changing the password, but leave my ssh keys
alone, unless there is a real reason to ask people to change them.
Reading between the lines of recent attacks, it seems likely that
private keys compromised in some of the attacks were used to perform
others. (No-one's come out and officially said this yet but it seems
pretty obvious from the subtext of some of the reports; I'm thinking
kernel.org / linux.com, for e.g.) It doesn't seem at all unlikely that
some people may have used the same identities on some of the other
compromised systems as they are using on FAS, and hence it seems pretty
reasonable to require this change.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:01 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, Oct 12, 2011 at 7:53 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Wed, 2011-10-12 at 13:45 -0400, Simo Sorce wrote:
> I have no problem with changing the password, but leave my ssh keys
> alone, unless there is a real reason to ask people to change them.
Reading between the lines of recent attacks, it seems likely that
private keys compromised in some of the attacks were used to perform
others. (No-one's come out and officially said this yet but it seems
pretty obvious from the subtext of some of the reports; I'm thinking
kernel.org / linux.com, for e.g.) It doesn't seem at all unlikely that
some people may have used the same identities on some of the other
compromised systems as they are using on FAS, and hence it seems pretty
reasonable to require this change.
Not really unless there is any evidence pointing towards that
direction it is just paranoia.
Given the number of FAS account you can pretty much always assume that
some account may be compromised but that's not enough to warrant any
action. By that logic we should be changing keys daily ....
1:12 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, Oct 12, 2011 at 7:01 PM, drago01 <drago01(a)gmail.com> wrote:
On Wed, Oct 12, 2011 at 7:53 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> On Wed, 2011-10-12 at 13:45 -0400, Simo Sorce wrote:
>
>> I have no problem with changing the password, but leave my ssh keys
>> alone, unless there is a real reason to ask people to change them.
>
> Reading between the lines of recent attacks, it seems likely that
> private keys compromised in some of the attacks were used to perform
> others. (No-one's come out and officially said this yet but it seems
> pretty obvious from the subtext of some of the reports; I'm thinking
> kernel.org / linux.com, for e.g.) It doesn't seem at all unlikely that
> some people may have used the same identities on some of the other
> compromised systems as they are using on FAS, and hence it seems pretty
> reasonable to require this change.
Not really unless there is any evidence pointing towards that
direction it is just paranoia.
Given the number of FAS account you can pretty much always assume that
some account may be compromised but that's not enough to warrant any
action. By that logic we should be changing keys daily ....
And people are complaining about the fact that the last time it
happened was 3 years ago. At work I have to do it every 60 days.
Peter
1:24 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 20:01 +0200, drago01 wrote:
On Wed, Oct 12, 2011 at 7:53 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> On Wed, 2011-10-12 at 13:45 -0400, Simo Sorce wrote:
>
>> I have no problem with changing the password, but leave my ssh keys
>> alone, unless there is a real reason to ask people to change them.
>
> Reading between the lines of recent attacks, it seems likely that
> private keys compromised in some of the attacks were used to perform
> others. (No-one's come out and officially said this yet but it seems
> pretty obvious from the subtext of some of the reports; I'm thinking
> kernel.org / linux.com, for e.g.) It doesn't seem at all unlikely that
> some people may have used the same identities on some of the other
> compromised systems as they are using on FAS, and hence it seems pretty
> reasonable to require this change.
Not really unless there is any evidence pointing towards that
direction it is just paranoia.
Given the number of FAS account you can pretty much always assume that
some account may be compromised but that's not enough to warrant any
action. By that logic we should be changing keys daily ....
There's rather fewer FAS accounts with keys than there are total FAS
accounts. You only need to upload a key if you're a packager, really.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:26 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, Oct 12, 2011 at 8:24 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Wed, 2011-10-12 at 20:01 +0200, drago01 wrote:
> On Wed, Oct 12, 2011 at 7:53 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
> > On Wed, 2011-10-12 at 13:45 -0400, Simo Sorce wrote:
> >
> >> I have no problem with changing the password, but leave my ssh keys
> >> alone, unless there is a real reason to ask people to change them.
> >
> > Reading between the lines of recent attacks, it seems likely that
> > private keys compromised in some of the attacks were used to perform
> > others. (No-one's come out and officially said this yet but it seems
> > pretty obvious from the subtext of some of the reports; I'm thinking
> > kernel.org / linux.com, for e.g.) It doesn't seem at all unlikely that
> > some people may have used the same identities on some of the other
> > compromised systems as they are using on FAS, and hence it seems pretty
> > reasonable to require this change.
>
> Not really unless there is any evidence pointing towards that
> direction it is just paranoia.
> Given the number of FAS account you can pretty much always assume that
> some account may be compromised but that's not enough to warrant any
> action. By that logic we should be changing keys daily ....
There's rather fewer FAS accounts with keys than there are total FAS
accounts. You only need to upload a key if you're a packager, really.
... s/FAS/packager/ ... that wasn't the point.
1:11 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 10:53 -0700, Adam Williamson wrote:
On Wed, 2011-10-12 at 13:45 -0400, Simo Sorce wrote:
> I have no problem with changing the password, but leave my ssh keys
> alone, unless there is a real reason to ask people to change them.
Reading between the lines of recent attacks, it seems likely that
private keys compromised in some of the attacks were used to perform
others. (No-one's come out and officially said this yet but it seems
pretty obvious from the subtext of some of the reports; I'm thinking
kernel.org / linux.com, for e.g.) It doesn't seem at all unlikely that
some people may have used the same identities on some of the other
compromised systems as they are using on FAS, and hence it seems pretty
reasonable to require this change.
And forcing a key change improves the situation exactly how ?
If a key is compromised is because the attacker has access to
compromised key, which reasonably, means that new keys will be as
compromised if they are being used on the same system as before.
OTOH with a massive key change you have no reasonable way to monitor
suspicious key replacement activity. Remember that ssh keys can be
uploaded by simply knowing the FAS account password which is arguably
much simpler to snatch as we have many systems that require such
passwords in various different ways.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
2:55 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 12 Oct 2011, Adam Williamson wrote:
Reading between the lines of recent attacks, it seems likely that
private keys compromised in some of the attacks were used to perform
others. (No-one's come out and officially said this yet but it seems
pretty obvious from the subtext of some of the reports; I'm thinking
kernel.org / linux.com, for e.g.) It doesn't seem at all unlikely that
some people may have used the same identities on some of the other
compromised systems as they are using on FAS, and hence it seems pretty
reasonable to require this change.
Because you really think people will not use their old key to access all
other resources anymore, including perhaps their own laptop, so the new
key will be obtainable using the old key, which you assume could be compromised.
It basically adds no security. Users who did passphrase protect their key should
be fine and just need to go through a useless change loop, while insecure
users are just going to add a new key that's instantly compromised because
their old compromised key isn't removed because they need/use it elsewhere too.
So yeah, this qualifies as security theatre.
Also, if we are doing this, did pkgs.fedoraproject.org get a new ssh host key?
Paul
3:22 a.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On 10/12/11 19:53, Adam Williamson wrote:
On Wed, 2011-10-12 at 13:45 -0400, Simo Sorce wrote:
> I have no problem with changing the password, but leave my ssh keys
> alone, unless there is a real reason to ask people to change them.
Reading between the lines of recent attacks, it seems likely that
private keys compromised in some of the attacks were used to perform
others. (No-one's come out and officially said this yet but it seems
pretty obvious from the subtext of some of the reports; I'm thinking
kernel.org / linux.com, for e.g.) It doesn't seem at all unlikely that
some people may have used the same identities on some of the other
compromised systems as they are using on FAS, and hence it seems pretty
reasonable to require this change.
I don't think so.
People which have found their system compromised most likely already
have replaced all the ssh keys -> fine.
People which have not been compromised can continue to use the old keys
without problems.
For people which are compromised but didn't notice (and thus still
running a compromised system) the key change buys not much as the new
keys likely will be compromised too.
cheers,
Gerd
1:04 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 12 Oct 2011, Simo Sorce wrote:
On Wed, 2011-10-12 at 11:41 -0600, Kevin Fenzi wrote:
> On Wed, 12 Oct 2011 13:30:19 -0400
> Jeff Layton <jlayton(a)redhat.com> wrote:
>
> > I have a question not covered here: I just changed my ssh key a week
> > or two ago in the wake of the kernel.org compromise...
> >
> > Is my new key sufficient? I really don't want to have to re-distribute
> > my key to all of the various servers again.
>
> Well, we talked about this some, but we don't have fingerprints from
> several weeks ago to check people against to confirm they uploaded a
> new key.
>
> Would it be possible for you to just make a new fedora only key?
Can you stop asking useless security theater measures instead ?
My ssh keys are fine and I see no reason to change them for you.
If all projects I participate in were to ask me to change my keys I
would end up with a mess of different keys for absolutely no reason.
I have no problem with changing the password, but leave my ssh keys
alone, unless there is a real reason to ask people to change them.
Look at it this way, your keys and password may be fine. Can you say the
same about every other Fedora contributor? It not, what criteria would
you use to say who should and shouldn't change their passwords and keys?
Lots of people use and share keys across different projects. Lots of bad
stuff is going down, we don't have much information on what's been
compromised where, who or how. It might seem like theater to you.
You're very in tuned with the feng-shui of security and you are probably
fine. But not all of our contributors can say that.
-Mike
1:16 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 13:04 -0500, Mike McGrath wrote:
On Wed, 12 Oct 2011, Simo Sorce wrote:
> On Wed, 2011-10-12 at 11:41 -0600, Kevin Fenzi wrote:
> > On Wed, 12 Oct 2011 13:30:19 -0400
> > Jeff Layton <jlayton(a)redhat.com> wrote:
> >
> > > I have a question not covered here: I just changed my ssh key a week
> > > or two ago in the wake of the kernel.org compromise...
> > >
> > > Is my new key sufficient? I really don't want to have to
re-distribute
> > > my key to all of the various servers again.
> >
> > Well, we talked about this some, but we don't have fingerprints from
> > several weeks ago to check people against to confirm they uploaded a
> > new key.
> >
> > Would it be possible for you to just make a new fedora only key?
>
> Can you stop asking useless security theater measures instead ?
>
> My ssh keys are fine and I see no reason to change them for you.
> If all projects I participate in were to ask me to change my keys I
> would end up with a mess of different keys for absolutely no reason.
>
> I have no problem with changing the password, but leave my ssh keys
> alone, unless there is a real reason to ask people to change them.
>
Look at it this way, your keys and password may be fine. Can you say the
same about every other Fedora contributor? It not, what criteria would
you use to say who should and shouldn't change their passwords and keys?
Given the way passwords are used I see no issue in asking them to be
changed, they are very easy to steal in our current system, so I don't
complain about that.
Ssh keys are a different matter, they are generally much more secure as
they are not easily distributed or easy to steal, and changing them is
no assurance the new ones are not as compromised. (see previous mail)
Lots of people use and share keys across different projects. Lots of
bad
stuff is going down, we don't have much information on what's been
compromised where, who or how. It might seem like theater to you.
You're very in tuned with the feng-shui of security and you are probably
fine. But not all of our contributors can say that.
Storing a public key is not an issue, so the fact I use my key with
different projects has absolutely no bearing on my exposure, zero,
zilch. Unless I store my *private* keys on non-personal machines.
The problem is that blindly changing keys if a contributor is being
careless accomplishes exactly nothing, and just burdens all careful
ones.
If you have evidence of contributors being careless with SSH keys the
only recourse is to identify and educate the offenders requiring them to
change those keys and not have a 'hit 100 to educate 1' policy that
serves little or no purpose.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
1:27 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 14:16 -0400, Simo Sorce wrote:
Storing a public key is not an issue, so the fact I use my key with
different projects has absolutely no bearing on my exposure, zero,
zilch. Unless I store my *private* keys on non-personal machines.
I rather suspect this is exactly what happened in some of the
compromises. (Note the other recent FAS security notification, which
specifically told people not to store their private keys on fedorapeople
and said that any found on fedorapeople would be automatically deleted.
I wonder what could *possibly* be the motivation for such a move to
happen. Right at this particular point in history.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:51 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 14:16 -0400, Simo Sorce wrote:
On Wed, 2011-10-12 at 13:04 -0500, Mike McGrath wrote:
> On Wed, 12 Oct 2011, Simo Sorce wrote:
>
> > On Wed, 2011-10-12 at 11:41 -0600, Kevin Fenzi wrote:
> > > On Wed, 12 Oct 2011 13:30:19 -0400
> > > Jeff Layton <jlayton(a)redhat.com> wrote:
> > >
> > > > I have a question not covered here: I just changed my ssh key a week
> > > > or two ago in the wake of the kernel.org compromise...
> > > >
> > > > Is my new key sufficient? I really don't want to have to
re-distribute
> > > > my key to all of the various servers again.
> > >
> > > Well, we talked about this some, but we don't have fingerprints from
> > > several weeks ago to check people against to confirm they uploaded a
> > > new key.
> > >
> > > Would it be possible for you to just make a new fedora only key?
> >
> > Can you stop asking useless security theater measures instead ?
> >
> > My ssh keys are fine and I see no reason to change them for you.
> > If all projects I participate in were to ask me to change my keys I
> > would end up with a mess of different keys for absolutely no reason.
> >
> > I have no problem with changing the password, but leave my ssh keys
> > alone, unless there is a real reason to ask people to change them.
> >
>
> Look at it this way, your keys and password may be fine. Can you say the
> same about every other Fedora contributor? It not, what criteria would
> you use to say who should and shouldn't change their passwords and keys?
Given the way passwords are used I see no issue in asking them to be
changed, they are very easy to steal in our current system, so I don't
complain about that.
Ssh keys are a different matter, they are generally much more secure as
they are not easily distributed or easy to steal, and changing them is
no assurance the new ones are not as compromised. (see previous mail)
> Lots of people use and share keys across different projects. Lots of bad
> stuff is going down, we don't have much information on what's been
> compromised where, who or how. It might seem like theater to you.
> You're very in tuned with the feng-shui of security and you are probably
> fine. But not all of our contributors can say that.
Storing a public key is not an issue, so the fact I use my key with
different projects has absolutely no bearing on my exposure, zero,
zilch. Unless I store my *private* keys on non-personal machines.
The problem is that blindly changing keys if a contributor is being
careless accomplishes exactly nothing, and just burdens all careful
ones.
If you have evidence of contributors being careless with SSH keys the
only recourse is to identify and educate the offenders requiring them to
change those keys and not have a 'hit 100 to educate 1' policy that
serves little or no purpose.
+1^10
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
2:07 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath:
Lots of people use and share keys across different projects.
There is no security issue in sharing kes across different projects,
other than that it gives a strong hint that you are the same person in
both projects, much stronger than name or email.
Regards
Henrik
2:20 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 21:07 +0200, Henrik Nordström wrote:
ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath:
> Lots of people use and share keys across different projects.
There is no security issue in sharing kes across different projects,
Sure there is. There's the exact same problem as using the same password
across multiple projects: if someone compromises the key they have
compromised all of those projects. If you use a different key for each
project, an attacker can only compromise one project with any given key.
Sure, ssh keys are much harder to compromise than passwords, but
_assuming a compromise has happened_ the consequences of using a single
key for everything are just as bad as using a single password for
everything.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:38 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
ons 2011-10-12 klockan 12:20 -0700 skrev Adam Williamson:
Sure there is. There's the exact same problem as using the same
password
across multiple projects: if someone compromises the key they have
compromised all of those projects. If you use a different key for each
project, an attacker can only compromise one project with any given key.
To compromise my SSH key they need to compromise the location where my
key is stored and the key encryption passprase. If they manage to do
that then any key I have stored there is at equal risk, or anything else
I have on my computers or any system I have accessed meanwhile.
Accessing a compromised system using an SSH key do not place the key as
such at risk. There only is a slight risk if you have agent forwarding
enabled that the key may be used (not copied or stolen) while you are
logged in and is why agent forwarding SHOULD be disabled by default (and
is by default).
Accessing a compromised system using a password immediately gives the
password away.
Regards
Henrik
2:48 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 21:38 +0200, Henrik Nordström wrote:
ons 2011-10-12 klockan 12:20 -0700 skrev Adam Williamson:
> Sure there is. There's the exact same problem as using the same password
> across multiple projects: if someone compromises the key they have
> compromised all of those projects. If you use a different key for each
> project, an attacker can only compromise one project with any given key.
To compromise my SSH key they need to compromise the location where my
key is stored and the key encryption passprase.
Sure. However, if you have multiple keys with multiple passphrases, then
it's extra work to compromise each key. It is also possible, if you use
multiple keys for multiple systems, that you do not need to store every
key you own on every system you use. To take the possible real-world
example I raised...
let's say you have an account on kernel.org and one on linux.com. It may
make some kind of sense to your workflow for you to keep the private key
you use to access linux.com in your home directory on kernel.org. Now,
if the key in question is 'your single personal key you use for
everything', then if someone compromises kernel.org and then compromises
the key you have stored there, they have now compromised everything you
have access to, as you use that single key for everything.
Say the key in question is 'the key you use specifically for linux.com',
and you didn't choose to store any other of your private keys on
kernel.org because you'd never need to access any other systems from
kernel.org, you have now successfully mitigated the scope of the attack
to kernel.org and linux.com but _not_ any of the other systems you have
access to (and use different keys for, keys which you did not store on
kernel.org).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:21 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 12:48 -0700, Adam Williamson wrote:
On Wed, 2011-10-12 at 21:38 +0200, Henrik Nordström wrote:
> ons 2011-10-12 klockan 12:20 -0700 skrev Adam Williamson:
>
> > Sure there is. There's the exact same problem as using the same password
> > across multiple projects: if someone compromises the key they have
> > compromised all of those projects. If you use a different key for each
> > project, an attacker can only compromise one project with any given key.
>
> To compromise my SSH key they need to compromise the location where my
> key is stored and the key encryption passprase.
Sure. However, if you have multiple keys with multiple passphrases, then
it's extra work to compromise each key. It is also possible, if you use
multiple keys for multiple systems, that you do not need to store every
key you own on every system you use. To take the possible real-world
example I raised...
let's say you have an account on kernel.org and one on linux.com. It may
make some kind of sense to your workflow for you to keep the private key
you use to access linux.com in your home directory on kernel.org.
No it doesn't make sense in *any* case.
Use ssh agent forwarding if you must.
Now,
if the key in question is 'your single personal key you use for
everything', then if someone compromises kernel.org and then compromises
the key you have stored there, they have now compromised everything you
have access to, as you use that single key for everything.
You failed when you copied your private key on a shared system. End of
the game, no need to elaborate further
Plus if you do that changing keys will make hardly a difference, you
have bad behavior and you will expose your keys again, as I said before.
So you are only punishing those that are carefully by asking
indiscriminate ssh key changes.
Say the key in question is 'the key you use specifically for
linux.com',
and you didn't choose to store any other of your private keys on
kernel.org because you'd never need to access any other systems from
kernel.org, you have now successfully mitigated the scope of the attack
to kernel.org and linux.com but _not_ any of the other systems you have
access to (and use different keys for, keys which you did not store on
kernel.org).
Say you like to store you FAS password in a txt file unencrypted on
kernel.org, no need to steal keys, the attacker can simply load a new
key in FAS and have all access he needs.
If you have poor security policies for your security stuff you will
always endanger the systems you use, no matter how many times said
system forces you to change credentials. you will never force changing
credentials often enough to make a difference.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
3:12 a.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, Oct 12, 2011 at 12:48:57PM -0700, Adam Williamson wrote:
Sure. However, if you have multiple keys with multiple passphrases,
then
it's extra work to compromise each key.
Not true at all. If I keep my key(s) in a single location (a secure
machine at my home), then either all keys in that location are secure
or they've all been compromised. Someone with a rootkit on that
machine can capture all of my keys and all of my passphrases.
let's say you have an account on kernel.org and one on linux.com.
It
may make some kind of sense to your workflow for you to keep the
private key you use to access linux.com in your home directory on
kernel.org.
If you do this, you're doing it wrong.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
12:16 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, 2011-10-13 at 09:12 +0100, Richard W.M. Jones wrote:
On Wed, Oct 12, 2011 at 12:48:57PM -0700, Adam Williamson wrote:
> Sure. However, if you have multiple keys with multiple passphrases, then
> it's extra work to compromise each key.
Not true at all. If I keep my key(s) in a single location (a secure
machine at my home), then either all keys in that location are secure
or they've all been compromised. Someone with a rootkit on that
machine can capture all of my keys and all of my passphrases.
A rootkit is one kind of compromise, sure. I outlined another kind in an
earlier reply to a similar objection. (Here's another one: you keep your
Single Key For Everything or your Giant Key Collection on a USB key, and
the USB key gets swiped. Yes, yes, I know, the key should be
encrypted...sigh.)
> let's say you have an account on kernel.org and one on
linux.com. It
> may make some kind of sense to your workflow for you to keep the
> private key you use to access linux.com in your home directory on
> kernel.org.
If you do this, you're doing it wrong.
It's been pretty well established by now that lots of people do security
wrong all the time. Just saying 'everyone who's doing it wrong loses and
the only scenario we care about is the one in which everyone does it
right' is ludicrous.
The point is that there are actual plausible scenarios in which using
multiple keys results in a less catastrophic outcome than using a single
key for everything. That's all I ever claimed. I did not claim any of
the hypothetical examples I presented were cases of best security
practice.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:45 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 12:20 -0700, Adam Williamson wrote:
On Wed, 2011-10-12 at 21:07 +0200, Henrik Nordström wrote:
> ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath:
>
> > Lots of people use and share keys across different projects.
>
> There is no security issue in sharing kes across different projects,
Sure there is. There's the exact same problem as using the same password
across multiple projects: if someone compromises the key they have
compromised all of those projects. If you use a different key for each
project, an attacker can only compromise one project with any given key.
Sure, ssh keys are much harder to compromise than passwords, but
_assuming a compromise has happened_ the consequences of using a single
key for everything are just as bad as using a single password for
everything.
That's a nonsense. Simply said. If I have a properly generated random
ssh private key with a strong passphrase that I never put outside of my
workstations and safe backup media then there is no other way it can be
compromised than to compromise my workstation. And in that scenario it
surely does not matter whether I use single key for all the various
projects or multiple keys each key for a single project. Of course if
the public key algorithm (RSA or DSA) is broken such that the private
key can be derived from the public one or from the signatures then it
might make a slight difference. But that is currently not possible for
keys >= 1536 or so bits even with large computing power. And if there
was an easy way to break the public key algorithms many more things
would be broken than just a single compromised SSH key.
This is completely different from the password scenario where the
storage and transport model of the password from the user to the server
is extremely variable and might be quite insecure in some cases.
The much better security of the SSH public keys is actually not coming
from the fact, that they are "larger" and "random" but from the fact
that they are misused much harder than the passwords. And Fedora account
policy should reflect that and not blindly request changing SSH keys
from people who keep them safe.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
2:55 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 21:45 +0200, Tomas Mraz wrote:
That's a nonsense. Simply said. If I have a properly generated
random
ssh private key with a strong passphrase that I never put outside of my
workstations and safe backup media then there is no other way it can be
compromised than to compromise my workstation.
Sadly, not everyone uses properly strong passphrases on their private
keys. Some people don't use passphrases at all, and short ones can be
brute forced.
Workstations can be compromised in such a way as to compromise only a
subset of private keys, too.
So, let's say I use the key ADAM to access my personal systems, and the
key FEDORA to access Fedora systems.
When you first ssh into a remote system when you're using GNOME, GNOME
will prompt you for the key's passphrase, and there's a little drop down
labelled 'Details' which gives you some choices about when to re-lock
the key. By default it keeps the key open until you log out from GNOME,
but _you can change this_.
Let's say I leave that setting on default for key ADAM, but change it to
'lock after 1 minute' for key FEDORA.
Now I go out and leave my laptop lying on the coffee shop table for two
minutes while I buy a coffee. Some dastardly person swipes said laptop.
They high tail it off to their secure location, and quickly disable the
screen lock. Now they have access to my running session, and they can
ssh into my personal systems with impunity, because key ADAM is unlocked
until they log out. It's more than one minute since I last used key
FEDORA, though, so if they try and ssh into fedorapeople.org they'll
find that key is locked, and they can't screw around with Fedora.
(Okay, so in practice, because of the FAS email loophole, they can just
reset my FAS password, log in, and change the ssh key. But the point
stands in theory: you can have stricter policies for some ssh keys than
others, and hence some can be compromised without all being
compromised.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:27 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 12:55 -0700, Adam Williamson wrote:
On Wed, 2011-10-12 at 21:45 +0200, Tomas Mraz wrote:
> That's a nonsense. Simply said. If I have a properly generated random
> ssh private key with a strong passphrase that I never put outside of my
> workstations and safe backup media then there is no other way it can be
> compromised than to compromise my workstation.
Sadly, not everyone uses properly strong passphrases on their private
keys. Some people don't use passphrases at all, and short ones can be
brute forced.
Workstations can be compromised in such a way as to compromise only a
subset of private keys, too.
So, let's say I use the key ADAM to access my personal systems, and the
key FEDORA to access Fedora systems.
When you first ssh into a remote system when you're using GNOME, GNOME
will prompt you for the key's passphrase, and there's a little drop down
labelled 'Details' which gives you some choices about when to re-lock
the key. By default it keeps the key open until you log out from GNOME,
but _you can change this_.
Let's say I leave that setting on default for key ADAM, but change it to
'lock after 1 minute' for key FEDORA.
Now I go out and leave my laptop lying on the coffee shop table for two
minutes while I buy a coffee. Some dastardly person swipes said laptop.
They high tail it off to their secure location, and quickly disable the
screen lock. Now they have access to my running session, and they can
ssh into my personal systems with impunity, because key ADAM is unlocked
until they log out. It's more than one minute since I last used key
FEDORA, though, so if they try and ssh into fedorapeople.org they'll
find that key is locked, and they can't screw around with Fedora.
(Okay, so in practice, because of the FAS email loophole, they can just
reset my FAS password, log in, and change the ssh key. But the point
stands in theory: you can have stricter policies for some ssh keys than
others, and hence some can be compromised without all being
compromised.)
Sorry Adam but this is BS, if your laptop is stolen you MUST replace all
your keys anyways because you cannot count on them not being
compromised, period. So this complex scenario is just mirrors and smoke.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
3:50 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 16:27 -0400, Simo Sorce wrote:
On Wed, 2011-10-12 at 12:55 -0700, Adam Williamson wrote:
> On Wed, 2011-10-12 at 21:45 +0200, Tomas Mraz wrote:
>
> > That's a nonsense. Simply said. If I have a properly generated random
> > ssh private key with a strong passphrase that I never put outside of my
> > workstations and safe backup media then there is no other way it can be
> > compromised than to compromise my workstation.
>
> Sadly, not everyone uses properly strong passphrases on their private
> keys. Some people don't use passphrases at all, and short ones can be
> brute forced.
>
> Workstations can be compromised in such a way as to compromise only a
> subset of private keys, too.
>
> So, let's say I use the key ADAM to access my personal systems, and the
> key FEDORA to access Fedora systems.
>
> When you first ssh into a remote system when you're using GNOME, GNOME
> will prompt you for the key's passphrase, and there's a little drop down
> labelled 'Details' which gives you some choices about when to re-lock
> the key. By default it keeps the key open until you log out from GNOME,
> but _you can change this_.
>
> Let's say I leave that setting on default for key ADAM, but change it to
> 'lock after 1 minute' for key FEDORA.
>
> Now I go out and leave my laptop lying on the coffee shop table for two
> minutes while I buy a coffee. Some dastardly person swipes said laptop.
>
> They high tail it off to their secure location, and quickly disable the
> screen lock. Now they have access to my running session, and they can
> ssh into my personal systems with impunity, because key ADAM is unlocked
> until they log out. It's more than one minute since I last used key
> FEDORA, though, so if they try and ssh into fedorapeople.org they'll
> find that key is locked, and they can't screw around with Fedora.
>
> (Okay, so in practice, because of the FAS email loophole, they can just
> reset my FAS password, log in, and change the ssh key. But the point
> stands in theory: you can have stricter policies for some ssh keys than
> others, and hence some can be compromised without all being
> compromised.)
Sorry Adam but this is BS, if your laptop is stolen you MUST replace all
your keys anyways because you cannot count on them not being
compromised, period. So this complex scenario is just mirrors and smoke.
The point is, if you use one key they can access everything, if you use
several you actually have time to change your key before they are able
to brute-force the pass-phrase (assuming you use one).
Pierre
3:54 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 22:50 +0200, Pierre-Yves Chibon wrote:
On Wed, 2011-10-12 at 16:27 -0400, Simo Sorce wrote:
> On Wed, 2011-10-12 at 12:55 -0700, Adam Williamson wrote:
> > On Wed, 2011-10-12 at 21:45 +0200, Tomas Mraz wrote:
> >
> > > That's a nonsense. Simply said. If I have a properly generated random
> > > ssh private key with a strong passphrase that I never put outside of my
> > > workstations and safe backup media then there is no other way it can be
> > > compromised than to compromise my workstation.
> >
> > Sadly, not everyone uses properly strong passphrases on their private
> > keys. Some people don't use passphrases at all, and short ones can be
> > brute forced.
> >
> > Workstations can be compromised in such a way as to compromise only a
> > subset of private keys, too.
> >
> > So, let's say I use the key ADAM to access my personal systems, and the
> > key FEDORA to access Fedora systems.
> >
> > When you first ssh into a remote system when you're using GNOME, GNOME
> > will prompt you for the key's passphrase, and there's a little drop
down
> > labelled 'Details' which gives you some choices about when to re-lock
> > the key. By default it keeps the key open until you log out from GNOME,
> > but _you can change this_.
> >
> > Let's say I leave that setting on default for key ADAM, but change it to
> > 'lock after 1 minute' for key FEDORA.
> >
> > Now I go out and leave my laptop lying on the coffee shop table for two
> > minutes while I buy a coffee. Some dastardly person swipes said laptop.
> >
> > They high tail it off to their secure location, and quickly disable the
> > screen lock. Now they have access to my running session, and they can
> > ssh into my personal systems with impunity, because key ADAM is unlocked
> > until they log out. It's more than one minute since I last used key
> > FEDORA, though, so if they try and ssh into fedorapeople.org they'll
> > find that key is locked, and they can't screw around with Fedora.
> >
> > (Okay, so in practice, because of the FAS email loophole, they can just
> > reset my FAS password, log in, and change the ssh key. But the point
> > stands in theory: you can have stricter policies for some ssh keys than
> > others, and hence some can be compromised without all being
> > compromised.)
>
> Sorry Adam but this is BS, if your laptop is stolen you MUST replace all
> your keys anyways because you cannot count on them not being
> compromised, period. So this complex scenario is just mirrors and smoke.
The point is, if you use one key they can access everything, if you use
several you actually have time to change your key before they are able
to brute-force the pass-phrase (assuming you use one).
If they have my private SSH key they probably also have my passphrase
and do not need to brute-force anything. Not saying that I do not use
quite strong passphrase on my SSH private key but if someone is able to
steal my private key he has the access to my machine and with that
access he is probably also able to install a keylogger there.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
5:09 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 16:27 -0400, Simo Sorce wrote:
Sorry Adam but this is BS, if your laptop is stolen you MUST replace
all
your keys anyways because you cannot count on them not being
compromised, period. So this complex scenario is just mirrors and smoke.
It's an example of a situation in which one key is compromised and one
isn't. I didn't make any suggestions as to what would be the best
practice for the *hypothetical* person in the *hypothetical* example to
follow after the example had happened, because that was utterly outside
the scope of the post.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:43 a.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
Hi,
Sure, ssh keys are much harder to compromise than passwords, but
_assuming a compromise has happened_ the consequences of using a single
key for everything are just as bad as using a single password for
everything.
One ssh key per project doesn't make sense at all to me. They all would
be on my laptop, and in case it gets compromised the attacker can easily
snatch all the keys.
One ssh key per machine makes alot more sense. For outgoing ssh
connections from -- say -- shell.fedoraproject.org I wouldn't just copy
my private key from my laptop but generate a new one, then add it to
authorized_keys where needed.
That does (a) limit the access to the machines really needed instead of
allowing ssh to every machine I'm ssh'ing to from my laptop and
(b) doesn't compromise the keys used on my laptop in case
shell.fedoraproject.org is hacked.
cheers,
Gerd
12:18 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, 2011-10-13 at 10:43 +0200, Gerd Hoffmann wrote:
Hi,
> Sure, ssh keys are much harder to compromise than passwords, but
> _assuming a compromise has happened_ the consequences of using a single
> key for everything are just as bad as using a single password for
> everything.
One ssh key per project doesn't make sense at all to me. They all would
be on my laptop, and in case it gets compromised the attacker can easily
snatch all the keys.
I didn't claim it was necessarily a great approach. I simply disputed a
bald assertion that there was absolutely zero exposure difference
between using a single key for everything and using multiple keys. I
never claimed that 'you should use multiple keys' or 'it's best security
practice to use multiple keys' or anything like that; I simply took
exception at the suggestion that there was absolutely no difference
between the scenarios.
One ssh key per machine makes alot more sense. For outgoing ssh
connections from -- say -- shell.fedoraproject.org I wouldn't just copy
my private key from my laptop but generate a new one, then add it to
authorized_keys where needed.
That's a sensible approach, sure.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:55 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, Oct 13, 2011 at 12:18 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Thu, 2011-10-13 at 10:43 +0200, Gerd Hoffmann wrote:
> One ssh key per machine makes alot more sense. For outgoing ssh
> connections from -- say -- shell.fedoraproject.org I wouldn't just copy
> my private key from my laptop but generate a new one, then add it to
> authorized_keys where needed.
That's a sensible approach, sure.
Its the only right way to do it. As a general rule, a private ssh key
should NEVER be transferred off the machine it was generated on. If
you have the same private key on more than one machine at a time,
you're Doing It Wrong.
11:18 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, Oct 13, 2011 at 10:55:59PM -0500, Callum Lerwick wrote:
On Thu, Oct 13, 2011 at 12:18 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> On Thu, 2011-10-13 at 10:43 +0200, Gerd Hoffmann wrote:
>> One ssh key per machine makes alot more sense. For outgoing ssh
>> connections from -- say -- shell.fedoraproject.org I wouldn't just copy
>> my private key from my laptop but generate a new one, then add it to
>> authorized_keys where needed.
>
> That's a sensible approach, sure.
Its the only right way to do it. As a general rule, a private ssh key
should NEVER be transferred off the machine it was generated on. If
you have the same private key on more than one machine at a time,
you're Doing It Wrong.
Having the same private key on two machines may indeed be the wrong way to
do things but it's questionable that the method described is truly the "only
right way to do it". Is it worse to have any private keys (even one
generated on that machine) on a shared server or to use an ssh-agent with
your local credentials through the shared shared server?
-Toshio
11:25 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, Oct 13, 2011 at 11:18 PM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
On Thu, Oct 13, 2011 at 10:55:59PM -0500, Callum Lerwick wrote:
> On Thu, Oct 13, 2011 at 12:18 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
> > On Thu, 2011-10-13 at 10:43 +0200, Gerd Hoffmann wrote:
> >> One ssh key per machine makes alot more sense. For outgoing ssh
> >> connections from -- say -- shell.fedoraproject.org I wouldn't just copy
> >> my private key from my laptop but generate a new one, then add it to
> >> authorized_keys where needed.
> >
> > That's a sensible approach, sure.
>
> Its the only right way to do it. As a general rule, a private ssh key
> should NEVER be transferred off the machine it was generated on. If
> you have the same private key on more than one machine at a time,
> you're Doing It Wrong.
>
Having the same private key on two machines may indeed be the wrong way to
do things but it's questionable that the method described is truly the "only
right way to do it". Is it worse to have any private keys (even one
generated on that machine) on a shared server or to use an ssh-agent with
your local credentials through the shared shared server?
Its the only right way to manage private keys on a given system.
Whether or not a given system should even HAVE private keys in use on
it at all is an orthogonal issue... :)
11:25 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, Oct 13, 2011 at 10:55:59PM -0500, Callum Lerwick wrote:
Its the only right way to do it. As a general rule, a private ssh
key
should NEVER be transferred off the machine it was generated on.
Yeah, who needs backups of private keys anyways!
you have the same private key on more than one machine at a time,
you're Doing It Wrong.
That's kinda silly. I work on a desktop or on a laptop. When working on
my desktop, I really don't want to fire up my laptop just for the ssh
key. And adding two keys in all authorized_keys for this is kinda silly,
and does not add any security over the one copied key.
Paul
11:33 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, Oct 13, 2011 at 11:25 PM, Paul Wouters <paul(a)xelerance.com> wrote:
On Thu, Oct 13, 2011 at 10:55:59PM -0500, Callum Lerwick wrote:
> Its the only right way to do it. As a general rule, a private ssh key
> should NEVER be transferred off the machine it was generated on.
Yeah, who needs backups of private keys anyways!
We're talking about SSH keys here. There's no web of trust to lose.
Lose your keys? Generate new ones.
> you have the same private key on more than one machine at a
time,
> you're Doing It Wrong.
That's kinda silly. I work on a desktop or on a laptop. When working on
my desktop, I really don't want to fire up my laptop just for the ssh
key. And adding two keys in all authorized_keys for this is kinda silly,
and does not add any security over the one copied key.
You're wrong, and you're doing it wrong.
11:50 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, 13 Oct 2011, Callum Lerwick wrote:
> Yeah, who needs backups of private keys anyways!
We're talking about SSH keys here. There's no web of trust to lose.
Lose your keys? Generate new ones.
And contact my customers and what not to change it? Go past all the
servers i have access to with that key? No thanks.
>> you have the same private key on more than one machine at a
time,
>> you're Doing It Wrong.
>
> That's kinda silly. I work on a desktop or on a laptop. When working on
> my desktop, I really don't want to fire up my laptop just for the ssh
> key. And adding two keys in all authorized_keys for this is kinda silly,
> and does not add any security over the one copied key.
You're wrong, and you're doing it wrong.
Excellent dialog, strong arguments! Guess I'll stop feeding the trolls now.
Paul
2:43 a.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Fri, Oct 14, 2011 at 6:33 AM, Callum Lerwick <seg(a)haxxed.com> wrote:
On Thu, Oct 13, 2011 at 11:25 PM, Paul Wouters
<paul(a)xelerance.com> wrote:
> On Thu, Oct 13, 2011 at 10:55:59PM -0500, Callum Lerwick wrote:
>
>> Its the only right way to do it. As a general rule, a private ssh key
>> should NEVER be transferred off the machine it was generated on.
>
> Yeah, who needs backups of private keys anyways!
We're talking about SSH keys here. There's no web of trust to lose.
Lose your keys? Generate new ones.
There are people that use their keys for more than one machine. You
people make it sound like it is so easy to change keys.
It is *NOT* PERIOD.
The only reason why one would ever have/need to do that is when the
key is compromised. Losing the key due to file system corruption or
hardware failure shouldn't be a reason for that.
But the whole discussion is pointless at this point.
2:58 a.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, Oct 13, 2011 at 11:43 PM, drago01 <drago01(a)gmail.com> wrote:
There are people that use their keys for more than one machine. You
people make it sound like it is so easy to change keys.
It is *NOT* PERIOD.
Well if fedora infrastructure asked us to use gpg keys for ssh auth,
and we all used gpg subkey created from a master gpg key we kept
private this would actually be very easy. We actually have the tools
in the distro to do this gpgkey2ssh and gpg-agent and friends to
manage our gpg keyring as a set of usable ssh auth keys.
Has anyone made any serious use of gpg subkeys as ssh auth? I've been
playing with it a little but havent fully made the jump yet.
-jef
11:41 a.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Fri, Oct 14, 2011 at 2:58 AM, Jef Spaleta <jspaleta(a)gmail.com> wrote:
Has anyone made any serious use of gpg subkeys as ssh auth? I've been
playing with it a little but havent fully made the jump yet.
I've looked a little at monkeysphere this morning and it looks
interesting. It'd be nice if at least the FI folks could publish the
host keys for the Fedora systems using monkeysphere. I plan on giving
monkeysphere a good trial here. Note that there are a couple of bugs
currently, but they are fairly easy to work around.
https://bugzilla.redhat.com/show_bug.cgi?id=732191
https://bugzilla.redhat.com/show_bug.cgi?id=732203
--
Jeff Ollie
12:25 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Fri, Oct 14, 2011 at 8:41 AM, Jeffrey Ollie <jeff(a)ocjtech.us> wrote:
I've looked a little at monkeysphere this morning and it looks
interesting. It'd be nice if at least the FI folks could publish the
host keys for the Fedora systems using monkeysphere. I plan on giving
monkeysphere a good trial here. Note that there are a couple of bugs
currently, but they are fairly easy to work around.
I thought monkeysphere was basically an addon for additional
functionality. I was talking about using gpg-agent to load your
personal keyring on your laptop and generating a gpg subkey from your
private key. Converting that subkey into a ssh key for each system you
remote to. That way you can revoke/throw away each subkey without
risking your master key and gpg-agent on your local system makes it
easy to load all the keys without a lot of fuss on your part.
Basically what I'm saying is, it looks like Fedora infrastructure
doesn't need to do anything for us to choose to have easier management
of per remote host ssh keys. gpg-agent with gpg subkey usage appears
to be that easier way. I'm just saying it would be good if Fedora
Intrastructure, as domain experts, provided some best practice
guidance on how to set that up correctly and gave it a thumbs up as a
useful approach.
-jef
4:58 a.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
Hi,
> That's kinda silly. I work on a desktop or on a laptop. When
working on
> my desktop, I really don't want to fire up my laptop just for the ssh
> key. And adding two keys in all authorized_keys for this is kinda silly,
> and does not add any security over the one copied key.
You're wrong, and you're doing it wrong.
Well, its a case-by-case thing IMHO. For machines which are (a) sitting
at the same physical location and LAN segment and (b) trusting each
other anyway and (c) used by yourself only it doesn't add that much
security to have different ssh keys on each box ...
cheers,
Gerd
2:59 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 12 Oct 2011, Henrik Nordström wrote:
ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath:
> Lots of people use and share keys across different projects.
There is no security issue in sharing kes across different projects,
other than that it gives a strong hint that you are the same person in
both projects, much stronger than name or email.
Sorry I didn't explain it very well.
1) People share keys across different projects.
2) We've found PRIVATE keys on our servers
3) We have no reason to believe private keys that can authenticate to
Fedora weren't on some of the compromised systems we've heard so much
about.
You have to remember, lots of our contributors aren't highly technical.
Some don't even know what a private key is. They just follow the docs on
the website and get access to contribute. Not everyone is a packager.
-Mike
3:13 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 14:59 -0500, Mike McGrath wrote:
On Wed, 12 Oct 2011, Henrik Nordström wrote:
> ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath:
>
> > Lots of people use and share keys across different projects.
>
> There is no security issue in sharing kes across different projects,
> other than that it gives a strong hint that you are the same person in
> both projects, much stronger than name or email.
>
Sorry I didn't explain it very well.
1) People share keys across different projects.
2) We've found PRIVATE keys on our servers
3) We have no reason to believe private keys that can authenticate to
Fedora weren't on some of the compromised systems we've heard so much
about.
You have to remember, lots of our contributors aren't highly technical.
Some don't even know what a private key is. They just follow the docs on
the website and get access to contribute. Not everyone is a packager.
OK, but then you should not penalize also the people who keep their SSH
private keys only on safe private computers.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
3:18 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 12 Oct 2011 22:13:11 +0200
Tomas Mraz <tmraz(a)redhat.com> wrote:
OK, but then you should not penalize also the people who keep their
SSH private keys only on safe private computers.
We're sorry if it's causing you inconvenience. We have no way at all to
tell apart the groups of people who understand keys and crypto and best
practices from the people who should read the docs and information and
learn about them.
If even just a few people learn and improve their practices, isn't it
worth the small trouble to those that already understand?
kevin
3:30 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 14:18 -0600, Kevin Fenzi wrote:
On Wed, 12 Oct 2011 22:13:11 +0200
Tomas Mraz <tmraz(a)redhat.com> wrote:
>
> OK, but then you should not penalize also the people who keep their
> SSH private keys only on safe private computers.
We're sorry if it's causing you inconvenience. We have no way at all to
tell apart the groups of people who understand keys and crypto and best
practices from the people who should read the docs and information and
learn about them.
If even just a few people learn and improve their practices, isn't it
worth the small trouble to those that already understand?
No.
Seriously, no.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
3:35 a.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, Oct 12, 2011 at 02:18:20PM -0600, Kevin Fenzi wrote:
On Wed, 12 Oct 2011 22:13:11 +0200
Tomas Mraz <tmraz(a)redhat.com> wrote:
>
> OK, but then you should not penalize also the people who keep their
> SSH private keys only on safe private computers.
We're sorry if it's causing you inconvenience. We have no way at all to
tell apart the groups of people who understand keys and crypto and best
practices from the people who should read the docs and information and
learn about them.
If even just a few people learn and improve their practices, isn't it
worth the small trouble to those that already understand?
Not really. How is this going to change the behaviour of the
people who don't use good practices?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
3:22 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 12 Oct 2011, Tomas Mraz wrote:
On Wed, 2011-10-12 at 14:59 -0500, Mike McGrath wrote:
> On Wed, 12 Oct 2011, Henrik Nordström wrote:
>
> > ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath:
> >
> > > Lots of people use and share keys across different projects.
> >
> > There is no security issue in sharing kes across different projects,
> > other than that it gives a strong hint that you are the same person in
> > both projects, much stronger than name or email.
> >
>
> Sorry I didn't explain it very well.
>
> 1) People share keys across different projects.
> 2) We've found PRIVATE keys on our servers
> 3) We have no reason to believe private keys that can authenticate to
> Fedora weren't on some of the compromised systems we've heard so much
> about.
>
> You have to remember, lots of our contributors aren't highly technical.
> Some don't even know what a private key is. They just follow the docs on
> the website and get access to contribute. Not everyone is a packager.
OK, but then you should not penalize also the people who keep their SSH
private keys only on safe private computers.
First, asking people to change their key is work, not punishment.
Second, we have no idea how to figure out who has uploaded their private
keys to compromised systems that we don't run. If you know how we're all
ears :) That's the problem with these things, coming up with criteria of
who should and who shouldn't is nearly impossible so one bad apple is
spoiling the bunch. It stinks but it happens.
-Mike
3:34 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 15:22 -0500, Mike McGrath wrote:
On Wed, 12 Oct 2011, Tomas Mraz wrote:
> On Wed, 2011-10-12 at 14:59 -0500, Mike McGrath wrote:
> > On Wed, 12 Oct 2011, Henrik Nordström wrote:
> >
> > > ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath:
> > >
> > > > Lots of people use and share keys across different projects.
> > >
> > > There is no security issue in sharing kes across different projects,
> > > other than that it gives a strong hint that you are the same person in
> > > both projects, much stronger than name or email.
> > >
> >
> > Sorry I didn't explain it very well.
> >
> > 1) People share keys across different projects.
> > 2) We've found PRIVATE keys on our servers
> > 3) We have no reason to believe private keys that can authenticate to
> > Fedora weren't on some of the compromised systems we've heard so much
> > about.
> >
> > You have to remember, lots of our contributors aren't highly technical.
> > Some don't even know what a private key is. They just follow the docs on
> > the website and get access to contribute. Not everyone is a packager.
>
> OK, but then you should not penalize also the people who keep their SSH
> private keys only on safe private computers.
>
First, asking people to change their key is work, not punishment.
Unnecessary work
is kind of punishment.
BTW what prevents the people who do not care about their SSH private key
security to upload their new SSH key to a compromised system immediately
after their generate it again?
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
3:40 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 22:34 +0200, Tomas Mraz wrote:
Unnecessary work is kind of punishment.
BTW what prevents the people who do not care about their SSH private key
security to upload their new SSH key to a compromised system immediately
after their generate it again?
Nothing prevents them from doing it. But this action, here, today, is
trying to stave off risk from PAST compromises of others systems. It is
not trying to stave off FUTURE compromises.
It's like changing your house locks if you lose your keys. Nothing keeps
you from losing your keys again - but you're completely certain that the
old keys are useless now.
To be clear - this not the only measures we're taking. We're trying to
enhance our security posture so we can be better able to deal with what
appears to now be a commonplace event in the open source development
world.
-sv
6:20 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 12 Oct 2011 16:40:07 -0400
seth vidal <skvidal(a)fedoraproject.org> wrote:
On Wed, 2011-10-12 at 22:34 +0200, Tomas Mraz wrote:
> Unnecessary work is kind of punishment.
>
> BTW what prevents the people who do not care about their SSH
> private key security to upload their new SSH key to a compromised
> system immediately after their generate it again?
Nothing prevents them from doing it. But this action, here, today, is
trying to stave off risk from PAST compromises of others systems. It
is not trying to stave off FUTURE compromises.
It's like changing your house locks if you lose your keys. Nothing
keeps you from losing your keys again - but you're completely certain
that the old keys are useless now.
I for one am fairly certain that the folks who left their private keys
on public systems will do that again, fairly quickly. I am also fairly
certain that they are not following this debate.
--
Bernd Stramm
bernd.stramm(a)gmail.com
7:06 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 12 Oct 2011 19:20:54 -0400
Bernd Stramm <bernd.stramm(a)gmail.com> wrote:
I for one am fairly certain that the folks who left their private
keys on public systems will do that again, fairly quickly.
I'm not so sure. I hope some of them will take a minute to read and
follow best practices.
I am also
fairly certain that they are not following this debate.
Correct, but they would have seen the announcement, and later if they
don't change anything they will see a direct email with info.
kevin
3:37 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, 2011-10-12 at 22:13 +0200, Tomas Mraz wrote:
>
> You have to remember, lots of our contributors aren't highly technical.
> Some don't even know what a private key is. They just follow the docs on
> the website and get access to contribute. Not everyone is a packager.
OK, but then you should not penalize also the people who keep their SSH
private keys only on safe private computers.
What can we do there? We can't separate out those with good practices
and those without.
And to be completely fair - I know of some interesting cases where very
trusted and competent people who practiced safe security behaviors just
made a mistake they didn't notice.
These are smart, capable people who simply made a mistake.
If you were to speak to them you would say "they have their stuff
together, no way they would make a mistake like this" But they did.
It happens.
-sv
3:52 a.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
Hi,
What can we do there? We can't separate out those with good
practices
and those without.
For starters block ssh keys found @ fedorapeople.org ?
cheers,
Gerd
4:41 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
ons 2011-10-12 klockan 14:59 -0500 skrev Mike McGrath:
1) People share keys across different projects.
Yes.
2) We've found PRIVATE keys on our servers
Which should lead to immediate account suspension, no matter if that key
is the Fedora key or some other key.
And in reality it's not related to '1' above, but general awareness of
what SSH keys are and how to handle them.
3) We have no reason to believe private keys that can authenticate
to
Fedora weren't on some of the compromised systems we've heard so much
about.
Right. That is a good motivation for a key change. If that had been in
the original mail most if this SSH key discussion had been avoided and
instead focused on how to handle that, which I think would had been a
more constructive discussion.
It's already clear from the discussion that all SSH keys are not equal.
But I would surely hope no one with such involvement that he/she is
active with SSH accounts in Fedora and one or more of the other
referenced projects is so ignorant about their SSH keys that they leave
them on remote servers. But I can not guarantee this of course.
Regards
Henrik
3:14 a.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Wed, Oct 12, 2011 at 02:59:31PM -0500, Mike McGrath wrote:
2) We've found PRIVATE keys on our servers
By all means educate these users with a large clue-stick.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
12:39 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, Oct 13, 2011 at 09:14:46AM +0100, Richard W.M. Jones wrote:
On Wed, Oct 12, 2011 at 02:59:31PM -0500, Mike McGrath wrote:
> 2) We've found PRIVATE keys on our servers
By all means educate these users with a large clue-stick.
The problem is this:
Fedora contributors are a group of technically minded people that we think
should know better. Fedora contributors in the sysadmin groups (needed to
have shells on these machines) are an even more technically and security
minded group that should know even better. Yet that select group of people
are making a very bad mistake.
We can (and have) identified these people and hit them with the clue stick.
What we cannot do is audit kernel.org, linux.com, etc, and find out what
technically minded users that we have in common are made a similar mistake
on their systems and then hit *them* with a cluestick. Which is not to
place blame on those other sites for withholding information; we've never
revealed similar information. Debian didn't reveal that level of
information after their intrusion either.
But what does that lack of information leave us with? A whole lot of ssh
keys that may or may not have had their private keys on a compromised host
with no way of telling who's who. We don't even know if one of the keys was
known to have been used in the kernel.org and linux.com compromises. If the
users in question are on a long hiatus for Fedora work, those keys might
never be changed even if the user has been hit with a cluestick on
kernel.org.
So what are our admins to do? 1) We could ignore the issue. We have a lot
of contributors. Maybe we should just expect that some of their accounts
are going to be compromised. 2) We could require everyone to change keys.
3) You might have the information necessary to get us a list of our users
whose accounts or keys were potentially compromised on other people's
systems. If so, it might be reasonable to filter for just those people.
OTOH, if someone is out there purposefully targetting open source sites,
perhaps too much caution is better than too little.
-Toshio
1:29 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, 13 Oct 2011 10:39:03 -0700
Toshio Kuratomi <a.badger(a)gmail.com> wrote:
...
So what are our admins to do? 1) We could ignore the issue. We have
a lot of contributors. Maybe we should just expect that some of
their accounts are going to be compromised.
Not maybe. Certainly some of the accounts will be compromised.
2) We could require
everyone to change keys.
And some time after that, some accounts will be compromised again. Some
of the same accounts as before, and some other accounts. Not maybe.
Certainly, 100%.
--
Bernd Stramm
bernd.stramm(a)gmail.com
1:34 p.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
I think requiring a minium sized password that is pretty long, like maybe
15-20 or larger. The chance of somebody cracking those sized passwords would
be smaller. Also I know there was a previous issue about the Yubikey as part
of security. In my opinion requiring a 15-20 long password added with a
Yubikey would be something that would maybe lessen the chance. I currently
use Lasspass to create passwords, and my master password is a long password
and the password I get it to generate is also quite long.
On Thu, Oct 13, 2011 at 1:29 PM, Bernd Stramm <bernd.stramm(a)gmail.com>wrote:
On Thu, 13 Oct 2011 10:39:03 -0700
Toshio Kuratomi <a.badger(a)gmail.com> wrote:
>...
> So what are our admins to do? 1) We could ignore the issue. We have
> a lot of contributors. Maybe we should just expect that some of
> their accounts are going to be compromised.
Not maybe. Certainly some of the accounts will be compromised.
> 2) We could require
> everyone to change keys.
And some time after that, some accounts will be compromised again. Some
of the same accounts as before, and some other accounts. Not maybe.
Certainly, 100%.
--
Bernd Stramm
bernd.stramm(a)gmail.com
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3:59 a.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On 10/12/2011 09:59 PM, Mike McGrath wrote:
On Wed, 12 Oct 2011, Henrik Nordström wrote:
> ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath:
>
>> Lots of people use and share keys across different projects.
>
> There is no security issue in sharing kes across different projects,
> other than that it gives a strong hint that you are the same person in
> both projects, much stronger than name or email.
>
Sorry I didn't explain it very well.
1) People share keys across different projects.
2) We've found PRIVATE keys on our servers
3) We have no reason to believe private keys that can authenticate to
Fedora weren't on some of the compromised systems we've heard so much
about.
4) There are indications for keys being shared between indivuals.
Ralf
4:13 a.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On Thu, 2011-10-13 at 10:59 +0200, Ralf Corsepius wrote:
On 10/12/2011 09:59 PM, Mike McGrath wrote:
> On Wed, 12 Oct 2011, Henrik Nordström wrote:
>
>> ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath:
>>
>>> Lots of people use and share keys across different projects.
>>
>> There is no security issue in sharing kes across different projects,
>> other than that it gives a strong hint that you are the same person in
>> both projects, much stronger than name or email.
>>
>
> Sorry I didn't explain it very well.
>
> 1) People share keys across different projects.
> 2) We've found PRIVATE keys on our servers
> 3) We have no reason to believe private keys that can authenticate to
> Fedora weren't on some of the compromised systems we've heard so much
> about.
4) There are indications for keys being shared between indivuals.
Which you dreamed
up and made false accusations of. But let's suppose
that anyone really shares their private keys on purpose what would
prevent them to share them again if they change them?
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
4:32 a.m.
New subject: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On 10/13/2011 11:13 AM, Tomas Mraz wrote:
On Thu, 2011-10-13 at 10:59 +0200, Ralf Corsepius wrote:
> On 10/12/2011 09:59 PM, Mike McGrath wrote:
>> On Wed, 12 Oct 2011, Henrik Nordström wrote:
>>
>>> ons 2011-10-12 klockan 13:04 -0500 skrev Mike McGrath:
>>>
>>>> Lots of people use and share keys across different projects.
>>>
>>> There is no security issue in sharing kes across different projects,
>>> other than that it gives a strong hint that you are the same person in
>>> both projects, much stronger than name or email.
>>>
>>
>> Sorry I didn't explain it very well.
>>
>> 1) People share keys across different projects.
>> 2) We've found PRIVATE keys on our servers
>> 3) We have no reason to believe private keys that can authenticate to
>> Fedora weren't on some of the compromised systems we've heard so much
>> about.
>
> 4) There are indications for keys being shared between indivuals.
Which you dreamed up and made false accusations of.
Putting aside the rude tone of your answer, ...
... there were questionable git check-ins from a "package dep mass
rebuilt", whose changelog entries were attributed to a different person
than that who actually commited the changes (Doing so makes sense when a
person submits a substantial patch, but doing so in a "mass rebuild"
doesn't).
This leaves few conclusions, e.g.
- the account owner passed on his ssh keys to another person or granted
terminal access to another person, who then missed to disguise himself
as the account owner.
- the account owner doesn't understand changelog entries and commited a
broken changelog entry.
Note that I said "indications" - May-be the git server admins could
prove this (e.g. checking IPs), but it's close to impossible prove from
outside.
But let's suppose
that anyone really shares their private keys on purpose what would
prevent them to share them again if they change them?
Nothing - It's a matter of trust.
If these people are caught, confronting them with sanctions (close down
their Fedora accounts) would be an appropriate means.
Ralf
4601
days inactive
4603
days old
59 comments
20 participants
participants (20)
-
Adam Williamson -
bernd.stramm＠gmail.com -
Callum Lerwick -
drago01 -
Gerd Hoffmann -
Henrik Nordström -
Jef Spaleta -
Jeffrey Ollie -
Kevin Fenzi -
Mike McGrath -
Nathan O. -
Paul Wouters -
Peter Robinson -
Pierre-Yves Chibon -
Ralf Corsepius -
Richard W.M. Jones -
Seth Vidal -
Simo Sorce -
Tomas Mraz -
Toshio Kuratomi