Generate and Store SSH Keys
Hello,
I wanted to ask a question about SSH Keys. At the current time our users just create SSH on their own servers using keygen or puttygen. We are trying to create a process for them to request the creation of SSH Keys to a designated group and then have them collect the keys from a network share, so we can keep track of the SSH Keys.
The proposal is to insall PuttyGen on one of our ADCS (Issuing CA) to generate and 'store' the keys on the CA. That is not a good idea, right ? The CA stores the CA database. If you agree, please give me reasons as to why it is not a good idea to generate or store SSH keys on a CA server.
We even have separate Web Enrollment servers.
Should we instead build a separate server to generate SSH Keys ?
Thanks. Mona.
I wanted to ask a question about SSH Keys. At the current time our users just create SSH on their own servers using keygen or puttygen. We are trying to create a process for them to request the creation of SSH Keys to a designated group and then have them collect the keys from a network share, so we can keep track of the SSH Keys.
The proposal is to insall PuttyGen on one of our ADCS (Issuing CA) to generate and 'store' the keys on the CA. That is not a good idea, right ? The CA stores the CA database. If you agree, please give me reasons as to why it is not a good idea to generate or store SSH keys on a CA server.
We even have separate Web Enrollment servers.
Should we instead build a separate server to generate SSH Keys ?
Thanks. Mona.
Super bad idea.
If the system where the keys live is compromised... well... every key can be used to access each related machine... with impunity... meaning, these will all be normal logins. Very hard to keep track of who's a hacker accessing a system + who's a real person.
The entire purpose of ssh is to keep private keys separate from public keys.
Maybe describe why your going to all this trouble... what specific problem you're attempting to solve... then someone can provide other approaches for a solution...
If the system where the keys live is compromised... well... every key can be used to access each related machine... with impunity... meaning, these will all be normal logins. Very hard to keep track of who's a hacker accessing a system + who's a real person.
The entire purpose of ssh is to keep private keys separate from public keys.
Maybe describe why your going to all this trouble... what specific problem you're attempting to solve... then someone can provide other approaches for a solution...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
While the keypairs are similar, ssh is not CA. You do not keep other people's private keys for them. That defeats the entire purpose of ssh. You can track the public keys.
I've read this question several times + still fail to understand any reasoning for collecting together all private parts of keypairs in a central location.
@Mona, likely best to describe the exact problem you're trying to resolve. More than likely someone can suggest a simple resolution approach.
@Mona, likely best to describe the exact problem you're trying to resolve. More than likely someone can suggest a simple resolution approach.
Same like people are generating the private key for the CA derived CSR from some unknown public source.
For a webserver, (or any SSL using server) the key should be generated on the platform the private key should not leave the platform...
The public key is part of the CSR to be signed. So the public is key is to be spread far and wide. that is what Public in Public Key means.
The word Private in private Key actually means just THAT. Keep it to yourself (being it keeping to yourself personally (SSH) or "personally" to the webserver for which it is intended. )
For a webserver, (or any SSL using server) the key should be generated on the platform the private key should not leave the platform...
The public key is part of the CSR to be signed. So the public is key is to be spread far and wide. that is what Public in Public Key means.
The word Private in private Key actually means just THAT. Keep it to yourself (being it keeping to yourself personally (SSH) or "personally" to the webserver for which it is intended. )
It is feasible to store public keys in various locations including ldap.
It is feasible to store them in custom backends using a trivial zcript. I have one around for an sql backend.
It is feasible to store them on a nas
As mentionned above, beware of spofs. If you have existing ldap accounts, there is little point to bother with ghe extra spof
I personally run a cron job that regenerates the whole directory every few minutes, and the directory is only writable by root.
This allows to use a config file with a pattern matching the machines, remove keys within minutes, change keys, ...
It is feasible to store them in custom backends using a trivial zcript. I have one around for an sql backend.
It is feasible to store them on a nas
As mentionned above, beware of spofs. If you have existing ldap accounts, there is little point to bother with ghe extra spof
I personally run a cron job that regenerates the whole directory every few minutes, and the directory is only writable by root.
This allows to use a config file with a pattern matching the machines, remove keys within minutes, change keys, ...
Because that introduces a single point of failure which can destroy the entire network's integrity. If the server holding all the secret keys (that doesn't even sound good) is subverted, then every key for every server on the network is known. Doesn't sound so good put in those terms, does it ...
There is no need for anyone outside a server to know a server's private key. Regenerate new keys periodically, yes, fine, that can be done in a cron script. Nor is there a need for anyone outside a workstation to know that workstation's PuTTY keys; nothing other than PuTTY uses them. And in either case, server or workstation, if you suspect a key problem you just generate a new one and immediately forget what it is.