SSLr*: rsh,rcp,rdist over SSL

Fancy the BSD r* commands, but hate risking your neck? Relax. With SSLr* you can have your cake and eat it too. Its the standard BSD r* commands using an ssl_rcmd(3) implemented on top of Eric Young's SSLeay library and the newer OpenSSL which implement the SSLv2 and SSLv3 protocols. See the SSLeay FAQ for more info.

Note: the SSLeay and OpenSSL libraries can be built with NO_RSA defined and in conjunction with SSLv3 and DSA certs allow royalty free secure communications anywhere in the world (assuming strong crypto is legal :-).

Actually, SSL support is added via my own sslfd libaray which allows appliactions like ftpd,telnet and r* to be converted to use SSL with minimal effort and fully supports the NO_RSA setup.

The /etc/services entry for SSLrshd should be:

sshell	614/tcp	SSLshell

SSLrshd(8) is the server, it uses a set of auth files which are backwards compatible with the /etc/ssl.users from Tim Hudson's SSLtelnet to determine if access should be granted.

The client must always supply a certificate and the server certificate is optional this is achieved by reversing the SSL_{accept,connect} roles between the server and client.

The latest version of SSLrsh and SSLrshd allow the conventional client/server roles to be used by adding the command line option -zrcmd=1. Two entries in inetd.conf are needed for SSLrshd to support both setups if needed.

SSLrshd looks up the provided certificate in /etc/ssl.users and if the requested local user or root is found as a target user, then and only then is permission granted.

Note that none of SSLrshd's clients (SSLrsh(1), SSLrcp and SSLrdist) run set-uid, nor does SSLrshd generally care where the requests come from. The exception is the case where the client provides a host certificate (Common Name field is fully qualified hostname). If the CN contains '.'s and can be found in the DNS it is assumed to be a host certificate and will only be accepted from the host it was issued to and then only if an appropriate entry appears in an auth file.

For the truely paranoid, SSLrshd supports chroot()ing similar to the BSD ftpd. If the target user is listed in /etc/rshchroot as in user[:dir] then SSLrshd will chroot(dir) or to the user's home directory. It will then do the normal chdir(pwd->pw_dir) so you can have a common chroot dir and home dirs under that.

I've not done a lot of mods to the r* man pages, but all of the clients take the same -z options as SSLtelnet plus a few others. Or look for SSL_CERT,SSL_KEY,SSL_CIPHER in the environment - again nothing runs set-uid so nothing to attack. The -z options apply to SSLr*, SSLtelnet and stelnet:

cert=file: Indicates that the X.509 certificate can be found in file. It is quite useful to include the key in the same file, so they cannot get separated and are easier to use. It is most convenient to put SSL_CERT=file in your environment.
key=file: Ok, so you didn't listen and you keep your key in a separate file, so tell the program where it is. You can also use SSL_KEY in your environment.
verify=N: If N&1 is true, then peer will be asked for a certificate. If N&2 is also true, then peer's certificate must validate or session will be dropped. And you guessed it, SSL_VERIFY in the environment does just as well.
cipher=cipher[:cipher...]: Allows you to control which ciphers can be negotiated. The list of ciphers supported by SSLeay is quite long. I often use SSL_CIPHER=IDEA-CBC-MD5:DES-CBC3-MD5:DES-CBC-MD5 when I'm feeling paranoid.

To date SSLrsh has been tested on NetBSD 1.x, FreeBSD 2.x, Linux 2.0 (Red-Hat), SunOS 4.x, Solaris 2.x, HP-UX 9, HP-UX 10 and IRIX 5. Note that just about every system other than 4.4BSD and Linux, appear to have a bug in shutdown(2) on a socketpair. If you find a command like:


echo "sleep 60; date" | SSLrsh sun

does not work, then recompile SSLrshd with -DSHUTOWN_HACK

SSLrdist

I know that the latest rdist from USC (which is what SSLrdist is built from) would work with SSLrsh as shipped. But if using a certificate that requires a password to unlock it, this approach would require the password to be entered for each SSLrsh invocation (ie. for each host in a multi-host update). The diffs are minor and the added ease of use well worth it.

To build, you must unpack the rdist distribution somewhere (see here for where to get it) and make ssl/bin/rdist/src and ssl/bin/rdistd/src symlinks to it, the Makefiles should do the rest.

Note that Linux will not build rdistd (6.1.3) unless you move rdist*/include/paths.h aside.

If all else fails, rdist.patch shows what you need to do.