Postfix+uucp+ssh

At $DAYJOB, we run servers in Google Compute Engine. Google (wisely) does not allow TCP port 25 traffic into or out of its Compute Engine offering. How to get email in and out? Well, we can put together an email stack using Postfix as the mail transfer agent (and sendmail equivalent), Taylor UUCP as a non-SMTP transport facility, and OpenSSH to carry the UUCP protocol.

Why these components?

A bit of rationale for each of these:

• Postfix: I like its config file format and flexibility. And I find it easier to get along with than sendmail. After finding Postfix, I've never bothered to get acquainted with exim.
• Taylor UUCP: It's the UUCP available on Debian. The config files aren't too hard to understand. And there is plenty of support if you want it available via Google.
• OpenSSH provides us cryptographic authentication of both ends, management of leaf systems' access by public keys, it provides a reliable pipe interface usable by UUCP, and can be configured for securely identifying both parties without having a human type a password.

Architecture

This is a leaf and trunk setup. The Google Compute Engine machines will be connecting to a central mail hub system running in Amazon EC2. These leaf systems will periodically (driven by cron) run the uucico component of the UUCP stack to send messages to (and potentially pull them from) the Amazon mail hub machine.

Required software packages

First off, we need some software on each of the leaf systems. All our systems are running Debian or Ubuntu, so installing software is an apt-get install away.

For the leaf and hub systems, do this:

apt-get install openssh-server openssh-client uucp postfix

When debconf asks its questions about postfix configuration, tell it that we're on a "local only" system. We'll fix up that config later.

A leaf to hub communications channel

Setting up SSH communications

client side

The UUCP facility runs as user uucp on both the leaf and hub systems. So setting up the SSH communications channel means setting up the uucp user's SSH config on both ends. For the short term, the uucp user will need regular shell access. Set it up with bash like so:

sudo chsh -s /bin/bash uucp
sudo su - uucp

And generate a bit, fat SSH RSA keypair for as the uucp user:

cd ~uucp                             # should put us in /var/spool/uucp
mkdir -m 700 .ssh || true
ssh-keygen -vv -t rsa -b 8192 -N ''

Explanation of key generation parameters:

-vv

Be extra verbose

-t rsa

Generate an SSH protocol version 2 RSA key

-b 8192

Make the key 8192 bits long. This should be secure for a very, very long time.

-N ''

Do not secure the private key with a passphrase. Which is what we'll need to do use it as a batch process.

Without a -f filename option, ssh-keygen will leave the RSA private key file it generates in $HOME/.ssh/id_rsa

server side

Again, we need to do some stuff as user uucp. Set that up:

sudo chsh -s /bin/bash uucp
sudo su - uucp

Create a .ssh directory in user uucp's home directory:

cd ~uucp
mkdir -m 700 .ssh

Allow key-based authentication from the leaf system. We do this by putting the leaf system's uucp user's public key in the hub system's uucp user's .ssh/authorized_keys file. You'll want to copy and paste the leaf system's public key from its user ~uucp/.ssh/id_rsa.pub file. It will look something like this:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAEAQC+MsCRxe8+YEBqWmu+OArYqJAJ/Kxrv0Th8LrCqtiedwaIY+0MoxCbIbOKb6qcIPcSD8abwVWet6ao72BH5VGfxTF4NsIyzZuY3yw1halwEcA4nFJxjkSovQsSIpZNYfSUQ2uKI+HZwtFMNCrLwozsW7OwrSHHZehApNH34NrCrn3ToG8GjCo7YPvg+FvqwvLOKdBiPUiKkK+K5f8VVO59YGX3Jrs2W+Y30jeddNAs2b7JjlDFogg8usGHGLdLwGIcyUA+/fdHzZJd3w58U27Q3fqv0EghtD8AH+AkM5mcu3+PqFuPPzzgnCd9YDH69tM6/JVh6D4V14P+bwxiIWl2+6cVoRopwsvy0aXyMaCbMIbu18hy2ECr6T4I96l2xNs5L/945tev33uUeYx5GpWhIFMP+uPbb+UaISbEbLD1X2wpHIUXWmmu+Wt16NtEa2ZJWOOMptv8Mzk/xSVjcro071xGcJVREiusr8xLGYBbgAWFo4SWX4PqPXwzPOq6cE6mKrz/4hF/cAfiexppZp5bsqoy2RFQSLtUSTpocYjIW4Q7XJheyh8Ha4PNfZGo+Mh6AMc6hJBZH0PKlkqR2QenjaWrZ2fUPrKmI1sNK1RD9n3HigV5lTumjgQTEVuYaQxIC4uyXVV54/ifBXzXh6OtVkdnakf9YEry97FBqvUGtNvpTkgmmrz7sVOg+IPFDQmD2RpcOUE4Mh+mxuIRTi+CZAU7nWjGGcObFBrSzVR8m2oVWuOare/eOD3PM3EAC8C8Ks1diISyc1u9iwG5xQ1PQOgpWPC4DWskC8ewI+KJT0uz2l+v6zYiu0Hxm2MNoqJm3cJv4hOgLU1trCYbhI1piHYVNDd7Pm1M9DwZYbhCF5rvhMd+vRWxeTgU3sswdGeA9+UjHBh26emLBZSRziE3n1XkdOqwSAJ8hlXZoWDkttyOZnHDs9Z+jl+YAqEMLecbGCIhKoiQYxZkhCI83DqX8uJ3KgMf+RwtwoD8+nDGYIj052z22eMiSue2/+bybzuv72wBThteg28dY9e6SyYeaWu7iFqZG8SbkDKsVExmE+PKhdPQ0jrc5zjs0j4xpo7G+d4Bxf+IctV0WEJV5Q1tZRruNlO2573Sy/6dhLWm9vZFt9HjgGdF/+/fmvg3yWzDzpRTe7+db4Mt7T54DZVpxeGtaG5TeiIvEdp5jZsG7x1l/emydi49uyzfo/u9D5OgtC7wcFM8b7GxSAAMX4rz3crLddbga/vGtkSRHyMinjT9v6+/KiTIPNWK4/oabkvo0s+21tDtx7tlG/aUzGuQPOLOplKU/LVDq17Y3w2oNKIk3Ef6MTs0vfZB0YDGMGNn7Q1Dt8PRdDSI5Sn6uVRT uucp@platform-development-0

OpenSSH's sshd allows additional restrictions to be placed on the use of a key. These go at the front of the line in the user authorized_keys file. Here is a suggested set to start with: