ssh key maintenance advice

[TwoProc]

Hey all,

I'm looking for a better way than every 30 days generating new keys, splatting them all over the place by hand following a list of which users get which keys from other users on other hosts, etc.

So, I'm wondering, who has a better way? How about Radius server for ssh key exchange? Is that what it's for? Can someone point me to a document that gives a nice high and mid-level overview layout of what the strategies could be?

I've got to believe that there's a better way. I know I can get ssh to serve a users' public keys, but what about all keys for everyone and some receivership rules?

Suggestions & ideas on how my esteemed colleagues handle this best would be sincerely appreciated.

Many thanks!

[Steven Schweda]

Why are you generating new keys every 30
days? Do the old ones get rusty or
something?

[Steven E. Protter]

Shalom,

These keys are good and can stay secure for years.

If you have a master ssh server with its root key distributed to all other systems as authorized_user entry, that server can take care of maintenance issues.

SEP

[Andre Cornelissen]

If you are generating keys because of password aging you might want to disable password interactive login all together and remove the password expiration too.
http://www.linuxquestions.org/questions/linux-security-4/how-to-deny-password-login-in-the-ssh-please-199730/

Regards,
Andre

[Don Mallory]

Aside from someone breaking the algorithm used in creating the keys, there should be no reason to ever regenerate them other than a host replacement.

The example I can use would be the failure of using an appropriate level of randomness in generating the key pairs. This occurred about a year ago with respect to most SSH implementations.

If you are protecting your key pairs properly this should never be a problem.

If you are extremely paranoid, you could replace all key pairs at the time of departure of a highly trusted staff member. Otherwise, you are actually introducing risk.

The intent of those keys, and especially the known_hosts lists is that you should always know your hosts. If you for some reason do not know the other hosts, it is clearly an unexpected state, whether accidental (keys changed, forgot to update host list), or malicious. Either way, you would want to investigate.

That said, it's an interesting idea that you suggest to manage ssh key pairs in the same manner as you might manage a certificate authority for SSL keys through some sort of Public Key Infrastructure implementation.

Perhaps you have the makings of a new product...

Best regards,
Don

[TwoProc]

Thanks for the advice guys. But, PCI requirements, etc - expect keys replaced every 30 days. Did they explicity say THESE keys? No, but our consultant says THESE keys - so, I'm very happy to hear that it's uncommon to change these out, meaning the consultant is off his rocker. Thanks you guys!

[Steven Schweda]

> [...] PCI requirements, etc - expect keys
> replaced every 30 days. [...]

PCI? Peripheral Component Interconnect?
Who???

> [...] our consultant says [...]

Did you ask why? Did you get a reasonable
answer? (Did you pay too much for the
consultation?)

[Bill Hassell · Accepted solution]

Payment Card Industry -- a very common term in the banking industry. Wikipedia offers a good overview:

http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard

And yes, like most emerging standards (especially banking), they take a decade to get going so "replacement keys" probably meant the desk and file cabinet keys. For a large enterprise where managing a lot of servers is a big task, the ability to transfer files and remotely manage them using ssh makes key replacement a very high risk procedure. It would take a lot of planning to prevent multi-server downtime for virtually no increase in security levels.

It can probably be scripted and scheduled but untangling servers that stopped completing their tasks because of a glitch in key distribution is going to be a highly visible event with lots of explaining to do.

I agree with Steven: Ask why. No procedural changes should ever be allowed without justification with industry standards. And eve then, upper management can issue a statement to cover exceptions to the findings.

[TwoProc]

thanks Bill for advice and input. Thanks Steve for responding.