<div dir="ltr">Hi Nico,<div><br></div><div>You and I completely agree that unexpected discrepancies often cause problems, break workflows, and make people hate security changes. I've been a Debian developer for over 13 years and a UNIX sysadmin for longer than that. There are many cases where I've made arguments similar to yours inside Google, sometimes even mentioning "knife ssh" itself (yes I've used Chef), and we're more compatible with customers' non-GCE automation because of such arguments.</div>
<div><br></div><div>Despite all of that, adding this account management daemon in GCE makes sense, as do the other carefully chosen integration bits we add. Our account daemon can certainly be disabled without harm (e.g. via systemctl in CentOS 7), doesn't interfere with UNIX ways of working, and doesn't dictate what we do about the root account. It's even careful not to remove keys which were added separately by users, distinguishing carefully via comment lines. All of the software we add is of course free and open source software, typically under the Apache License 2.0, and also typically human-readable Python, shell, systemd unit files, or the like. Some of our software is even packaged in RPMs (built via a hacky internal process); we do plan to reach out to coordinate proper RPM packaging and integration into a suitable CentOS repository.</div>
<div><br></div><div>Regarding your specific concerns about root's passwd data, we don't change that. I forget whether we change CentOS's root SSH login setting; we do change a few other things like disabling password SSH auth and putting in some connection keepalive settings, but it's quite close to stock config. We try to keep our deviations justifiable, and if you think any are not, we'd like to hear about them. :) As one example justification, the SSH connection keepalive is because TCP connections that remain idle too many minutes will get dropped by the GCE firewall.</div>
<div><br></div><div>- Jimmy<br><div><div><br></div><div>We aren't changing root's passwd data.</div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 14, 2014 at 6:44 PM, Nico Kadel-Garcia <span dir="ltr"><<a href="mailto:nkadel@gmail.com" target="_blank">nkadel@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Mon, Jul 14, 2014 at 12:14 PM, Jimmy Kaplowitz <<a href="mailto:jkaplowitz@google.com">jkaplowitz@google.com</a>> wrote:<br>
> As further data points, Debian on AWS EC2 uses the 'admin' username, and all<br>
> Google-supported images on Google Compute Engine (including CentOS) don't<br>
> have a default account at all, but rather use integrated SSH key management<br>
> via our metadata server and an open source daemon we install into the guest.<br>
<br>
</div>But you're not changing root's uid, gid, shell, home directory, or<br>
group memberships, right? It's all fun and games until someone<br>
touches old tools that have worked consistently for more than a decade<br>
with an unexpected discrepancy between UNIX historical settings, and<br>
someone's untested "security enhancement". It's the sort of thing that<br>
makes people hate security changes.<br>
<br>
Blocking direct login access by locking the password and/or blocking<br>
SSH root access are all understandable, but should *not* be changed<br>
from upstream's defaults without considerable thought. They *will*<br>
break procedures that are applied to both systems, especially those<br>
that rely on remote SSH key or direct root privileges such as the<br>
"knife ssh" command from chef and other SSH based multiple-target<br>
tools.<br>
<br>
Having to pipe the commands through some kind of sudo adds complexity.<br>
Don't get me wrong, I agree that in most cases it can and should be<br>
turned off for security reasons. But changing the defaults is going to<br>
burn sys-admin's very valuable time. Is it worth the security<br>
enhancement to make their lives more difficult?<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org">CentOS-devel@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos-devel" target="_blank">http://lists.centos.org/mailman/listinfo/centos-devel</a><br>
</div></div></blockquote></div><br></div>