Okay, so could you, on production:-
- Generate an ssh key in the usual way with ssh-keygen and the options you find are appropriate.
- Copy/add the public key into the authorized_keys file
- Copy the authorized_keys file to the target server
This way they authorized key will allow you to ssh/sftp to the local server too, but it will persist whenever you replicate 'everything' to the DR server.
I guess from what you are saying, that the production server name will also be replicated, hence why the /etc/hosts needs to be protected. Can I assume that /etc/hosts is very small and that you use DNS? If not, then you are risking updates to /etc/hosts on production being missed on the DR server. Really, you should keep /etc/hosts to:-
- One record per network card, plus one for the loopback
- One record for the boot addresses and persistent addresses when operating in a cluster.
More than this is bad practice anyway. I have a struggle with colleagues chucking stuff in all over the place because they see it as easier that asking for a DNS update. We end up in a mess every now and then because of typing errors or a complete failure to make the update to all. I am always taking them out and putting them in DNS behind the scenes - and they don't notice.
Anyway, does this give you an option to proceed?
Robin
