1 |
Hello, |
2 |
|
3 |
You cannot. The reason for this is simple : you can copy as many times |
4 |
as you wish it your private key in any place. Even if you were able to |
5 |
check-up that a private key is passphrase-protected, it wouldn't mean |
6 |
every single copy of that key is protected so. And the interest of the |
7 |
private key is that only the owners possesses it and hides it; thus you |
8 |
shouldn't think about a mensual submission of the keyfile to |
9 |
automatically check it is protected, because it would open a serious |
10 |
security hole. |
11 |
|
12 |
I see the problem you face because some time ago, I used |
13 |
passphrase-protected keys on my usb stick and ones stored on windows, |
14 |
but I assumed my linux system was secure enough not to need any more |
15 |
password once logged in. Opinon I revised with time :) |
16 |
|
17 |
If you generates the keypair for these users, you can protect them with |
18 |
a complex password, so that lazy users may keep it and learn it (or |
19 |
write it down...). Fortunately (from my point of view), you do not have |
20 |
any single point of control on your users' private keyfile. Keeping |
21 |
their credentials safe is of their responsibilities. Your security |
22 |
officer probably knows that 80-90% of the security is about educating |
23 |
people. To sensibilise them is you most efficient measure of control. |
24 |
|
25 |
Any way I might think about checking the protection of a private key |
26 |
seems to be a violation of privacy to me, regardless of the technology. |
27 |
The one step you may act is when generating the key pair. What if you |
28 |
generate it and transfer it to the user in a secure way, after they |
29 |
filled a form with the password setting for the key ? This way, as they |
30 |
chosed the password, they'd remember it and don't need to change it or |
31 |
remove it, unless they really want to. Against that last case, there's |
32 |
nothing you can do. |
33 |
|
34 |
Good luck, |
35 |
Jil. |
36 |
|
37 |
Alan McKinnon a écrit : |
38 |
> Hi all, |
39 |
> |
40 |
> I think I'm barking up an impossible tree, but it's worth asking. |
41 |
> |
42 |
> Scenario: |
43 |
> |
44 |
> I have an sshd-enabled jump box catering for 100+ users. They all use ssh keys |
45 |
> and we ask them all nicely to passphrase-protect the private key and pretend |
46 |
> that we enforce this. Keys are in use because the admin load of coping with |
47 |
> passwords isn't worth the effort. Fortunately, I have a security officer who |
48 |
> is properly clued up and very willing to listen to reason. |
49 |
> |
50 |
> My question: |
51 |
> |
52 |
> Is there any known way, no matter how convulted and bizarre, of checking and |
53 |
> enforcing from the server end that a private key is passphrase protected? Our |
54 |
> own research indicates no. One possible way is to audit the user's client |
55 |
> machine, but we don't have that level of access (and don't want it either) |
56 |
> |
57 |
> |