We implemented this within IBM:

-  created userid 'support' on all Linux guests - made it a 'no login' user
-  Put support in sudoers to allow commands with NOPASSWD on all guests
-  Distributed the 'authorized_keys' to /home/support/.ssh with  the support
user's public key on the central system.
- Used 'support' to run various various scripts, tools, etc via ssh to
collect Linux files and data across all servers.  Also used to 'push' files
to the Linux servers (scripts, /etc/sudoers, etc) - and change passwords,
etc.
- Created an 'intelligent' ssh tool which could talk to servers based on
different criteria (names, ips, groups, customers, etc) - all run from
'support' on the central server.

I'm not sure whether the above violates any security rules - it would depend
on the security policies in place..

Scott Rohling

On Sun, Jan 18, 2009 at 2:58 PM, Michael MacIsaac <[email protected]>wrote:

> ... sent this this AM - not sure where it went ... resending ...
>
> Marcy,
>
> > Same rule here....  (if only some of these vendors (cough ibm/tivoli
> cough) would comprehend... )
> I'm trying to comprehend, and will also try to bubble the message upwards
> in my small sphere of influence.
>
> So let me ask this to the list - what are the rules regarding key-based
> authentication?  Is this approach not authorized even though no root (or
> any other) passwords goes over the wire?  Or is it just the rule that the
> /root/.ssh/authorized_keys file never exist?
>
> If there is no key-based authentication for root allowed, can there be for
> non-root users (not sure how much this will help).
>
> One thing I'm looking for is a way that a central Linux system can pull
> important data (/etc/fstab /etc/zipl.conf,
> /etc/sysconfig/network/ifcfg-qeth-*), and run certain commands remotely on
> other Linux systems without the need for someone sitting typing a password
> many times.
>
> Systems management tasks need to be automated to scale the number of
> servers a single admin can care for, but security rules in certain shops
> seem to be preventing that.  There must be some intelligent compromise
> (and it's probably involves sudo)
>
> Thanks.
>
> "Mike MacIsaac" <[email protected]>   (845) 433-7061
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
>

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to