[CentOS-devel] Cloud image default login

[Jimmy Kaplowitz]

Hi Nico,

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.

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.

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.

- Jimmy

We aren't changing root's passwd data.


On Mon, Jul 14, 2014 at 6:44 PM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> On Mon, Jul 14, 2014 at 12:14 PM, Jimmy Kaplowitz <jkaplowitz at 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?
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140715/14867957/attachment.html>