Ridding myself of root passwords?

Dan Egli ddavidegli at gmail.com
Thu Feb 6 04:02:11 MST 2014

On February 4, 2014, Michael Torrie wrote:

> Recent versions of openssh allow to configure options on a per-host or

> per-subnet basis.. For example, here's an extract from my sshd_config:

[ config items deleted]

Interesting, and I could certainly see that in a /root/.sshd/config file,
but in the master file? That indicates that unless you have the
certificate, NO ONE can login via SSH. That seems overkill to me. Perhaps
that works good in your situation, but I certainly can't see a situation
where I'd want to do that. In root's config, sure. That makes a LOT of
sense. But not for every user on the system. I suppose you could override
the global behavior by an individual user's .sshd/config file, but that
still seems like overkill to me. Perhaps you can explain why you block
logins except via ssh key or certificate to all users? I'd be curious to
understand the reasoning behind this approach.

--- Dan

On Wed, Feb 5, 2014 at 9:45 AM, Michael Torrie <torriem at gmail.com> wrote:

> On 02/04/2014 08:20 PM, Daniel Fussell wrote:
> > I'm not trying to be a flaming-troll, I really would like to know if
> > there is a better way to manage delegate admin accounts without giving
> > away the keys to the kingdom.  Just for discussion's sake, lets ignore
> > for the moment that physical access is root access.
> I think the overall point is not that root access isn't the keys of the
> kingdom, but rather if you don't ever use the root password directly,
> then you never have to change it (it could in fact never be set) when
> someone leaves.  The idea is to have many root users (one for each
> admin), in essence. Because in my mind there's no difference between
> root and an admin with sudo access. For all intents and purposes, my
> personal login is root.  That's okay, though, and it's much easier to
> revoke than changing the root password on dozens of servers.  Of course
> the idea of elevating privileges only as necessary is a good security
> feature.  Every program, service, and sysadmin should always operate
> with as few privileges as necessary.  (In practice probably most of us
> sudo -i and hack away.)
> Very few people have ever sit this up, and maybe with sudo and ssh keys
> it's overkill and unnecessary, but managing root access can be quite
> effective with Kerberos.  What I did was set up sysadmin principals to
> have a common suffix, say /ADMIN, and then kerberized services were set
> to allow any /ADMIN principal access.  Sysadmins just kinit their
> principal, and then ssh transfers it from machine to machine as you go.
>  It's pretty slick, actually.  And the logs do record which principal
> was used to access root.
> To remove access to a sysadmin who leaves, you just remove his /ADMIN
> principle.  His other credentials need not be touched.  This way you
> could have a student who works for a couple semesters as a sysdadmin,
> then leaves and goes back to being a normal student who still needs
> access to the computers.  But you can do similar things with sudo and
> gidNumbers.  Just create an LDAP group that's essentially wheel, and
> make your admins a member of that group.  Remove when they leave.
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */

More information about the PLUG mailing list