Then you're a fool! Generate new private keys on the PROD server and upload them.
I don't know if you can do it with your SCM, but a better solution would be the source control server to push to PROD rather than the other way round, as it prevents attacks from a compromised PROD server.
> Generate new private keys on the PROD server and upload them.
How is that any more secure then agent forwarding? The vulnerability with agent forwarding needs some work and right timing to be exploited after the prod server is rooted. Having a set of private keys lying around is offering access on a plate.
>I don't know if you can do it with your SCM, but a better solution would be the source control server to push to PROD rather than the other way round, as it prevents attacks from a compromised PROD server.
Yes, I am wiser (or less foolish if you prefer ;-) ) now. One can always fall back to rsync and friends if the SCM lacks.
Having specific keys for specific purposes is more secure because when you add the public half of it to your SVN server, you put the extra options along with the key that limit the server it can come from, and the command it can execute. This means that your seemingly-scary private key can now do one thing and one thing only - pull from svn.
Now you can do deployments without any constraints like "abhaga needs to be awake and have his computer on and be SSHed to the right places" :)
I don't know if you can do it with your SCM, but a better solution would be the source control server to push to PROD rather than the other way round, as it prevents attacks from a compromised PROD server.