remctl

Small deeds done are better than great deeds planned.

Peter Marshall

Blurb

remctl is a client/server application that supports remote execution of specific commands, using Kerberos GSS-API for authentication. Authorization is controlled by a configuration file and ACL files and can be set separately for each command, unlike with rsh. remctl is like a Kerberos-authenticated simple CGI server, or a combination of Kerberos ssh and sudo without most of the features and complexity of either.

Description

remctl is a client/server application that supports remote execution of specific commands, using Kerberos GSS-API for authentication and confidentiality. The commands a given user can execute are controlled by a configuration file and ACL files and can easily be tightly limited, unlike with rsh. The mapping of command to backend program is done by the configuration file, which allows some additional flexibility compared to ssh command restrictions and works with Kerberos authentications rather than being limited to public key authentications.

remctld is very similar to a CGI server that uses a different network protocol than HTTP, always does strong authentication before executing the desired command, and guarantees the data is encrypted on the network. Alternately, you can think of it as a very simple combination of Kerberos ssh and sudo, without most of the features of both but with simpler authorization.

There are a lot of different client/server systems that do something similar: current packages like gRPC, and a wealth of older systems like rsh, CGI, CERN's arc, and more elaborate systems like MIT's Moira. remctl has the advantage over many of these schemes of using GSS-API and being about as simple as it possibly can be while still being useful. It doesn't require any particular programming language, builds self-contained binaries, and uses as minimal of a protocol as possible.

Both C and Java clients and servers are provided, as well as Perl, PHP, Python, and Ruby bindings for the C client library. For more information about the Java client, see java/README. For more information about the PHP bindings, see php/README. For more information about the Python bindings, see python/README. For more information about the Ruby bindings, see ruby/README.

Also included in the remctl package is an alternate way of running the remctl server: remctl-shell. This program is designed to be run as either a shell or a forced command under ssh, using ssh for authentication and communicating the authentication information to remctl-shell via either environment variables or command-line arguments via the forced command configuration. This version of the server uses simple ssh clients, rather than using the remctl client program or libraries.

remctl was originally written by Anton Ushakov as a replacement for IBM's sysctl, a client/server application with Kerberos v4 authentication that allowed the client to run Tcl code on the server, protected by ACLs. At Stanford, we used sysctl extensively, but mostly only to run external programs, so remctl was developed as a Kerberos v5 equivalent that did only the portions we needed.

Complete protocol documentation is available in docs/protocol.html. Also present, as docs/design.html, is the original design document (now somewhat out of date).

Requirements

The remctld server and the standard client are written in C and require a C compiler and GSS-API libraries to build. Both will build against either MIT Kerberos or Heimdal of any reasonable vintage. remctl will also build against the Kerberos GSS-API implementation shipped with AIX 5.2 (and possibly later versions) and the Solaris 10 generic GSS-API library (and possibly later versions). The remctl_set_ccache implementation is improved by building with Kerberos libraries and a GSS-API library that supports gss_krb5_import_cred.

The remctld server requires libevent 1.4.x or later. It was only tested with libevent 1.4.13-stable and later, but should work with 1.4.4 or later. It is now only tested with libevent 2.x, so moving to a later version of libevent if possible is recommended.

The remctl server will support regex ACLs if the system supports the POSIX regex API. The remctl server also optionally supports PCRE regular expressions in ACLs. To include that support, the PCRE library (either PCRE2 or PCRE1) is required.

To build the remctl client for Windows, the Microsoft Windows SDK for Windows Vista and the MIT Kerberos for Windows SDK are required, along with a Microsoft Windows build environment (probably Visual Studio). remctl has only been tested with the 3.2.1 MIT Kerberos for Windows SDK. To run the resulting binary, MIT Kerberos for Windows must be installed and configured. The client was tested on Windows XP and Vista and should work on Windows 2000 and up; however, the primary maintainer does not use or test Windows, so it's always possible Windows support has broken. The server is not supported on Windows.

To build the Perl bindings for the C client library, you will need Perl 5.10 or later.

To build the PHP bindings for the C client library, you will need PHP 5.x or later and phpize, plus any other programs that phpize requires. PHP 5.x support has only been tested on 5.2 and 5.3, and PHP support is now only tested on PHP 7.x and later.

To build the Python bindings for the C client library, you will need Python 2.7, or Python 3.1 or later. You will also need the setuptools and pytest modules and, for Python 2, the typing module. Earlier versions may work back to possibly Python 2.3, but are not tested.

To build the Ruby bindings for the C client library, you will need Ruby 1.8 or later (primarily tested with 2.5 and later).

None of the language bindings have been tested on Windows.

A Java client and Java server are available in the java subdirectory, but they are not integrated into the normal build or built by default. There is a basic Makefile in that directory that may require some tweaking. It currently requires the Sun Java JDK (1.4.2, 5, or 6) or OpenJDK 6 or later. A considerably better Java client implementation is available on the java branch in the Git repository but has not yet been merged.

To bootstrap from a Git checkout, or if you change the Automake files and need to regenerate Makefile.in, you will need Automake 1.11 or later. For bootstrap or if you change configure.ac or any of the m4 files it includes and need to regenerate configure or config.h.in, you will need Autoconf 2.64 or later. Perl is also required to generate manual pages from a fresh Git checkout. You will also need pkg-config installed to regenerate configure and xml2rfc to build the formatted protocol documentation.

Download

The distribution:

remctl 3.18 2022-05-09 tar.gz (PGP signature) tar.xz (PGP signature)

An archive of older releases is also available. Versions older than 3.14 have known security vulnerabilities and should not be used.

Debian packages are available from Debian as of Debian 3.1 (sarge). For Debian 4.0 (etch) and later, install remctl-server for the server and remctl-client for the client. (The sarge release had a single remctl package that contained both.)

The Net::Remctl Perl module is available in Debian 5.0 (lenny) and newer; install libnet-remctl-perl for it. The PHP bindings (php5-remctl), Python bindings (python-remctl), and Ruby bindings (ruby-remctl) are available in Debian 6.0 (squeeze) and newer. The Ruby bindings package is named libremctl-ruby in Debian versions before 7.0 (wheezy).

See the Debian package tracker for more information.

For those using Puppet, there is a Puppet module available for installing the remctl server and managing server configurations. This was written and is maintained by the IN2P3 Computing Centre; see that page for more information.

remctl is maintained using the Git version control system. To check out the current development tree, see GitHub or clone:

    https://git.eyrie.org/git/kerberos/remctl.git

Pull requests on GitHub are welcome. You can also browse the current development source.

Documentation

User documentation:

Security advisories:

Developer documentation:

API documentation:

License

The remctl package as a whole is covered by the following copyright and license:

Copyright 2015-2022 Russ Allbery <eagle@eyrie.org>

Copyright 2002-2014 The Board of Trustees of the Leland Stanford Junior University

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Some individual source files are covered by other, compatible licenses. For complete copyright and license information, see the file LICENSE in the remctl source distribution.

Last spun 2022-12-12 from thread modified 2022-05-09