q9405096 at brampton.cqu.edu.au
Mon Jul 24 05:12:19 EDT 2000
Daniel Quinlan uttered:
> root access only at the console or via su
> root password to follow a pattern based on the site
> su access only to group members
I don't like the root password being known by users on machines where
security is important.
> which group should I make su owned by? I remember it being wheel
> on some other *nix I've worked on but Debian doesn't appear to have
> wheel. I'm going to email someone at Debian about this one.
'info su' before you email Debian.
sudo has facilities for allowing certain commands to be run as root by
certain users. This makes it easy to restrict or allow access to
commands based on the group a user is in whether it's "real"
(/etc/group) or "virtual" (/etc/sudoers).
It can also be configured so that one configuration file can be used for
an entire organisation.
> how to manage the RSA keys?
> Give each tech their own key and copy all tech's keys to all servers
> Give each tech a copy of a single key & copy that key to all servers
Give each tech their own key, as mentioned below.
> I'm leaning towards a single key as it is easier to manage. If
> someone leaves all we have to do is create a new key and update
> every server, which could be scripted to some extent.
Hmm. You can do this with multiple keys, I don't see what the problem
is here. With multiple keys, if someone leaves, you just delete their
account. (Oh, and they never knew the root password in the first place,
so we don't need to worry about that. ;)
deluser over ssh versus rsync over ssh. Not much difference in ability
to be scripted.
> Also if we suspect that someone has obtained a copy of the key and
> the passphrase we can push out a new key to all servers.
Again, the same sort of thing. Push out a new key for the user in
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 232 bytes
Desc: not available
More information about the General