Creating shared keys across servers can be handy for rsync'ing your data from a cron job, logging in or running scripts across a ssh connection without answering a password prompt and otherwise automating work. It also introduces a security issue. Anyone with access to the first server will automatically have access to the other server by simply inspecting the ~/.ssh/ directory and the .bash_history file.

Consider whether it makes sense to ask root to provide you with an application specific user which will only run those scripts you need to automate from a remote server. Privilege separation is key, build in security as you go. Don't trust iptables to keep out the bad guy. Consider how to contain the bad guys if they crack your firewall. Retrofitting security as an after-thought provides its dangers, that you will forget the need later, that you will postpone working out the secure way to get the job done because for the moment, well, at least you are getting the job done.

I tend to create an application specific database user for nearly every script or application I create. I create application specific system users for many applications I write. Don't make it easy on a cracker. Frustrate them at every turn. Don't let one insecure application on your network lead to the compromise of your databases, applications and systems. And especially don't make it easy to root your server by sharing keys across servers for a user which gets expansive and unnecessary sudo privileges.

And with those caveats, the advise above about ssh-keygen are responsive to your specific question.

-- Hugh