We are writing scripts to automatically redeploy our servers. These scripts are stored in version control.
Some of the servers require access to private Git repositories with access restricted by SSH. Is it stupid to store private SSH keys in version control with the rest of the configuration scripts or is there an obvious alternative?
Ideally we would not need to create new keypairs every time we reinstalled a server.
Ideally, I would separate the data from the code in the scripts you're writing. That means to store all your assets outside of the repository, probably in packages specific to your distribution (dpkg, RPM, etc.), signed using GPG. This will make your scripts more abstract, flexible and easier to maintain, but you will have to learn how to create packages for your distribution.
If you insist on using a key shared between all your servers, at least encrypt it and ask for a password during installation time. This way the password will not be stored in the repository and can be changed when necessary.
No matter how secure your repository is, you need to keep in mind that if you keep the private keys unencrypted in your (D)VCS, they will be distributed to all the people that will be developing as well. That, in my opinion makes containing any information leaks much more difficult. In this case, consider the situation when a member of your team leaves, you will need a way to revoke and issue a new set of keys anyway.
I would not easily discard the possibility of generating a new keypair for each new server. I guess that distribution of the public keys is what bothers your, but it is not an unsolvable task. Depending on your installation script, the generated public key can be displayed during the process and added to the repository's access lists.
Are you planning on using some kind of configuration management or instrumentation system to bootstrap and configure the servers? If not, I would strongly suggest you consider using one instead of developing a set of scripts. They provide a lot of other added benefits to server management, not only for this task in particular. Puppet, chef, cfengine, salt, bcfg2 (and a few others) and even some remote instrumentation systems like Fabric and Ansible make the process of exporting a set of public keys quite easy and pain-free.
You've to define your security level, is your repository secured? Is it more secured than your finals servers? At least same security? You have to keep in mind, anybody accessing your repository will access your finals server.
Private keys can be compared with passwords, as if you have the private key you are able to access the systems this key is meant for.
It's only not a problem to put your keys into a version control system when only people who should have access to the keys have access to the version control system.
