On Mon, Jul 14, 2014 at 12:14 PM, Jimmy Kaplowitz jkaplowitz@google.com wrote:
As further data points, Debian on AWS EC2 uses the 'admin' username, and all Google-supported images on Google Compute Engine (including CentOS) don't have a default account at all, but rather use integrated SSH key management via our metadata server and an open source daemon we install into the guest.
But you're not changing root's uid, gid, shell, home directory, or group memberships, right? It's all fun and games until someone touches old tools that have worked consistently for more than a decade with an unexpected discrepancy between UNIX historical settings, and someone's untested "security enhancement". It's the sort of thing that makes people hate security changes.
Blocking direct login access by locking the password and/or blocking SSH root access are all understandable, but should *not* be changed from upstream's defaults without considerable thought. They *will* break procedures that are applied to both systems, especially those that rely on remote SSH key or direct root privileges such as the "knife ssh" command from chef and other SSH based multiple-target tools.
Having to pipe the commands through some kind of sudo adds complexity. Don't get me wrong, I agree that in most cases it can and should be turned off for security reasons. But changing the defaults is going to burn sys-admin's very valuable time. Is it worth the security enhancement to make their lives more difficult?