I agree with Mr. Ball. Having service settings on the master disk replicated to clones creates a single point of compromise in all of the machines. I would recommend eliminating service settings from the master copy and replacing scripts to generate the settings info from a trusted source (new keygens for every server and sshd settings from a trusted source, for instance). This will accomplish three goals: 1) Servers that don't run SSH won't have the configs to make it happen. Thus SSH won't start and will not be a service available for attack. This meets the 'least services' principle. 2) For servers that do run SSH, the scripts will gather common config data from a trusted source, maintaining consistency. This allows the SSH service to be maintainable on individual servers across a large farm. 3) The SSH setup scripts should then fork off to generate their own keysets. This creates an additional layer to penetrate for each server and eliminates the common point of failure issue. This limits the common vulnerabilities to application/protocol level attacks. These are addressed by a patching/maint infrastructure or process, which hopefully is already set up.