[TriLUG] Remote Execution using remctl

Jack Hill via TriLUG trilug at trilug.org
Wed Sep 2 10:19:27 EDT 2015


On Wed, 2 Sep 2015, Ron Kelley via TriLUG wrote:

> Greetings all,
>
> I am trying to setup an environment whereby an admin server can run 
> commands remotely on another server w/out using SSH (think automation 
> with no interaction).  I know I can setup password-less SSH via the 
> “authorized_keys” file, but I prefer a more granular approach to specify 
> which users/commands can be run.
>
> In my searching, I ran into a tool called “remctl” which seems to do 
> what I want.  Essentially, you create a config file on the client server 
> specifying the remote server, remote username, and command(s) to allow. 
> However, remctl requires some sort of Kerberos configuration - something 
> I know nothing about.
>
> I was wondering if anyone had experience getting remctl running on 
> CentOS and could share some advice.  Or, perhaps, suggest an alternative 
> to remctl.

Hi Ron,

I've used remctl before and quite like it. In particular it's ACL support 
is great, so if you need to grant different permissions to different sets 
of users it really shines.

Kerberos is a protocol scheme that solves various authentication problems 
for entities in the same (or manually federated) administrative realm
using an online trusted third party (the Kerberos server or key 
distribution center (KDC)). Kerberos also provides a single-sign-on 
mechanism. I think Kerberos is pretty neat and is wildly popular due to 
Microsoft's co-option. It would be another security critical service for 
you to run, so if remctl is the only motivating factor for Kerberos it is 
probably not worth it. However, it may be worth looking at your 
infrastructure to see if Kerberos makes sense as it might solve other 
problems you have as well. The MIT Kerberos documentation is pretty good 
<http://kerberos.org/docs/index.html>.

There are other GSS-API mechanisms than Kerberos, but I don't know if 
remctl supports them or how much work they would be to add.

Best,
Jack


More information about the TriLUG mailing list