2008/5/26 Victor Reyes <victor.reyes / gmail.com>:
> Actually, ssh was my first choice and we use it for a short period until it
> became impractical.

From your posting it is not fully clear to me why it was "impractical".

>   6. *root* can only be use via *su*.

If ssh is allowed and several people should be allowed to become
"root" on all the machines, then you might as well allow root access
via ssh (probably with password auth disabled for improved security).

>   7. The solution I am looking for is to be used only by the sys admins.
>   8. My *first solution* was using *ssh* as it is fully allowed by the sec
>   group. Since authenticating would be impractical when executing a cmd on
>   over 100 servers, we created public/private keys, which was a pain below the
>   waist to distribute for everyone.

Hm...  Normally I would have expected home directories to be shared
via nfs in such a setup.  Even if not, you could have automated this.

> Also, since in many instances we needed to
>   run *root* commands, that was a real problem since we would have to
>   either setup keys for root or implement* sudo*. That's why I decided to
>   create my own poor-man distributed remote command processor.

... which was identified as a security threat. :-)  As always there is
the tradeoff between security and convenience.

> So, this is what I need to do.
>
> Create an environment where a sys admin:
>
>   1. log-in with her userid as we do daily and su to root.
>   2. Execute a root cmd remotely on a server or multiple servers and
>   receive the reply on the local server. We use one server as a the main
>   server. Kind of a control work station.
>   3. The communication between the main (local) server and the remote
>   server(s) must be "secured" (ssh, ssl, encryption, whatever)

I'd still use ssh or stunnel.  You could even use ssh's port
forwarding feature to connect to your remote command processor.

Kind regards

robert

-- 
use.inject do |as, often| as.you_can - without end