On Wed, 12 Oct 2011 13:30:19 -0400 Jeff Layton jlayton@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
On Wed, 2011-10-12 at 11:41 -0600, Kevin Fenzi wrote:
On Wed, 12 Oct 2011 13:30:19 -0400 Jeff Layton jlayton@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.
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.
On Wed, Oct 12, 2011 at 7:53 PM, Adam Williamson awilliam@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 ....
On Wed, Oct 12, 2011 at 7:01 PM, drago01 drago01@gmail.com wrote:
On Wed, Oct 12, 2011 at 7:53 PM, Adam Williamson awilliam@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
On Wed, 2011-10-12 at 20:01 +0200, drago01 wrote:
On Wed, Oct 12, 2011 at 7:53 PM, Adam Williamson awilliam@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.
On Wed, Oct 12, 2011 at 8:24 PM, Adam Williamson awilliam@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@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.
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.
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
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
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@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
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@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.
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.)
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@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
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
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.
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
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).
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.
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.
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.
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.
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.)
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.
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
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.
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.
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
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.
On Thu, Oct 13, 2011 at 12:18 PM, Adam Williamson awilliam@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.
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@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
On Thu, Oct 13, 2011 at 11:18 PM, Toshio Kuratomi a.badger@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@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... :)
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
On Thu, Oct 13, 2011 at 11:25 PM, Paul Wouters paul@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.
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
On Fri, Oct 14, 2011 at 6:33 AM, Callum Lerwick seg@haxxed.com wrote:
On Thu, Oct 13, 2011 at 11:25 PM, Paul Wouters paul@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.
On Thu, Oct 13, 2011 at 11:43 PM, drago01 drago01@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
On Fri, Oct 14, 2011 at 2:58 AM, Jef Spaleta jspaleta@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
On Fri, Oct 14, 2011 at 8:41 AM, Jeffrey Ollie jeff@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
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
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
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.
- People share keys across different projects.
- We've found PRIVATE keys on our servers
- 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.
On Wed, 12 Oct 2011 22:13:11 +0200 Tomas Mraz tmraz@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
On Wed, 2011-10-12 at 14:18 -0600, Kevin Fenzi wrote:
On Wed, 12 Oct 2011 22:13:11 +0200 Tomas Mraz tmraz@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.
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@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.
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.
- People share keys across different projects.
- We've found PRIVATE keys on our servers
- 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
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.
- People share keys across different projects.
- We've found PRIVATE keys on our servers
- 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?
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
On Wed, 12 Oct 2011 16:40:07 -0400 seth vidal skvidal@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.
On Wed, 12 Oct 2011 19:20:54 -0400 Bernd Stramm bernd.stramm@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
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
ons 2011-10-12 klockan 14:59 -0500 skrev Mike McGrath:
- People share keys across different projects.
Yes.
- 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.
- 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
On Wed, Oct 12, 2011 at 02:59:31PM -0500, Mike McGrath wrote:
- We've found PRIVATE keys on our servers
By all means educate these users with a large clue-stick.
Rich.
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:
- 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
On Thu, 13 Oct 2011 10:39:03 -0700 Toshio Kuratomi a.badger@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.
- 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%.
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@gmail.comwrote:
On Thu, 13 Oct 2011 10:39:03 -0700 Toshio Kuratomi a.badger@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.
- 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@gmail.com
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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.
- People share keys across different projects.
- We've found PRIVATE keys on our servers
- 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
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.
- People share keys across different projects.
- We've found PRIVATE keys on our servers
- 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.
- 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?
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.
- People share keys across different projects.
- We've found PRIVATE keys on our servers
- 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.
- 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