Case Study: Secure Connections

Problem: Many protocols need (but lack) strong encryption and authentication. Several tools must be combined to provide satisfactory results.

Solution 1: Use stunnel to encapsulate the connection in SSL encryption.

Limitations:

• SSL does not in itself have strong authentication mechanisms.

Result: Frequently used as a "good-enough" solution, particularly for short-term arrangements.

Solution 2: Use port forwarding (the '-L' option in OpenSSH) to forward a port to the destination.

Limitations:

• This method requires a standing SSH connection to function. SSH connections can be lost due to network congestion or outages. Tools such as inittab or autossh can recreate the connection if it fails, but these will typically implement a back-off algorithm in the event of an SSH command that fails repeatedly, leading to extended outages if multiple failures occur.
• This method requires elevated privileges on the client side to forward privileged ports.
• This method is subject to limitations in the number of tunneled connections SSH can provide (10 in OpenSSH), which can't be easily increased.

Result: Frequently used as a "good-enough" solution, particularly for short-term arrangements.

Solution 3: Use application support to initiate a per-connection SSH session (e.g. "rsync --rsh=ssh").

Limitations:

• This method requires application support. As rsync demonstrates, this is a duplication of effort that doesn't really solve the problem. Rsync does not provide strong authentication in itself, and is additionally subject to the limitations of SSH.
• This method will "trap" the rsync client within the account it used to connect via SSH, and this causes other problems (e.g. a backup will not preserve ownership). This leads to over-granting privileges (e.g. allowing it to connect as root).
• The private key used to connect can be bound to the server side of the rsync command, but this requires that the administrator use a script to control the command line the client is allowed to use. When connecting to a privileged account, this is almost begging to be compromised.

Result: This leads to either an insecure solution, or limited backups.

Solution 4: Create SSH connections on demand from inetd, use a bound command in the authorized_keys file to forward the connection to the desired destination using the socat socket tool.

Limitations:

• SSH connections can be slow to initiate.

Result: Inetd can grant privileged ports to unprivileged users in a secure fashion. SSH provides secure authentication and encryption. The connection is forwarded transparently without any application support. The connection succeeds or fails based on current conditions. An effectively unlimited number of connections are possible. This solution is preferred unless rapid connection setup/teardown is needed (which will require a full VPN).

Example: A remote server needs to back itself up over an untrusted connection.

In the /etc/inetd.conf file of the client:

127.0.0.1:873 stream tcp nowait backupuser /usr/bin/ssh ssh -T -q -q 
-e none -i /home/backupuser/.ssh/backups backups@backups.mydomain.com

In the authorized_keys of the server for the backups user:

no-pty,command="/usr/bin/socat -T 3600 -t 60 - 
tcp-connect:localhost:873" ssh-rsa ABCDEF0123456789= 
backupuser@server.mydomain.com

An rsync backup job can then be run normally.

Notes:

• Why not use a more common tool like nc? Nc uses stdio, which does buffering when it detects that a file descriptor is not a tty, in order to improve performance. This can cause a protocol like rsync to deadlock (e.g. a response is expected but has been buffered). Socat has the flexibility to deal with this problem, and provides many other options like connecting to sockets bound to the filesystem.
• To make stdin/stdout fully transparent with OpenSSH, "-e none" disables escape sequences, "-q -q" silences debug messages, and "-T" silences a debug message when a pty is not allocated for the command.
• The connection is not 8-bit clean if a pty is allocated, so this must be disabled.

Return to case studies.