Postfix+uucp+ssh

From FnordWiki
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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: 

from="162.222.179.81",no-agent-forwarding,no-port-forwarding,no-user-rc,no-X11-forwarding,command="/usr/sbin/uucico --debug 5 --prompt --login arch.imarketingplatform.com"

A bit of explanation for those restrictions:

from="162.222.179.81"
This key is only allowed to be used by a client at 162.222.179.81.
no-agent-forwarding
This key is not allowed to set up an ssh-agent proxy connection
no-port-forwarding
This key is not allowed to forward arbitrary TCP ports through the server
no-user-rc
Do not read the uucp user's .ssh/rc file
no-X11-forwarding
Do not forward X11 traffic
command="/usr/sbin/uucico --debug 5 --prompt --login arch.imarketingplatform.com"
When this key is used to authenticate, the specified command will be run. uucico details:
/usr/sbin/uucico
this is the UUCP file transfer program
--debug 5
Sets the amount of debugging info logged. 5 is probably overkill, but it's not a huge amount of disk space required.
--prompt
tells uucico that it will be printing its own "login: " and "password: " prompts.
--login arch.imarketingplatform.com
tells uucico that the remote user name is arch.imarketingplatform.com and that there is no need to prompt for a user name. This setting allows us to associate an SSH key with a single remote UUCP system. Without this being set, the remote system gets to tell uucico which user to authenticate as.

testing this layer

On the client system, as the uucp user, run this: 

ssh -v -i .ssh/id_rsa uucp@mail.imarketingplatform.com < /dev/null

And expect output similar to this: 

OpenSSH_6.6.1, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug1: Connecting to mail.imarketingplatform.com [54.186.217.34] port 22.
debug1: Connection established.
debug1: identity file .ssh/id_rsa type 1
debug1: identity file .ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Debian-4~bpo70+1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH_6.6.1* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA c9:47:bd:43:30:39:70:2d:91:b9:3b:46:3d:8b:48:39
debug1: Host 'mail.imarketingplatform.com' is known and matches the ECDSA host key.
debug1: Found key in /var/spool/uucp/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: .ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to mail.imarketingplatform.com ([54.186.217.34]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Port forwarding disabled.
debug1: Remote: User rc file execution disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Forced command.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Port forwarding disabled.
debug1: Remote: User rc file execution disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Forced command.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Password:debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
Transferred: sent 5676, received 3804 bytes, in 2.4 seconds
Bytes per second: sent 2376.9, received 1593.0
debug1: Exit status 0

If the two output lines reading "debug1: Authentication succeeded (publickey)." and "Authenticated to mail.imarketingplatform.com ([54.186.217.34]:22)." are missing, this indicates a problem doing public key authentication. Check the SSH server log for clues. The most likely issues are file permissions on the authorized_keys file on the server.

The "Password:" in the above output is uucico prompting for the client system's password. If that isn't there, make sure UUCP is installed on the server system, check the server side UUCP debug log, and double check the command setting for that key in the authorized_keys file on the server.

Near the end, also not the "Remote: Port forwarding disabled." and similar indications. These reflect the restrictions in the authorized_keys entry for this key.

Taylor UUCP configuration

Wherein we will tell the hub and leaf systems about each other, configure UUCP authentication, and set them up to talk over our SSH connection

leaf node side

The leaf system will be doing all of the calling out, so we'll set that up first.

remote system setup

cron will be running something like uucico -smail.imarketingplatform.com periodically. This will tell it to connect to the remote UUCP system it knows as mail.imarketingplatform.com (as listed in /etc/uucp/sys) send any waiting files it has to the remote system and pull any files the remote system has down.

The leaf system needs to have the following in /etc/uucp/sys: 

system mail.imarketingplatform.com
  time          Any
  port          mail.imarketingplatform.com-SSH
  call-login    *
  call-password *
  protocol      a
  sequence      true
  free-space    67108864
  commands      rmail

Some explanation of those:

system mail.imarketingplatform.com
This begins the description of the remote system. Note that this is only a UUCP system name and need not correspond to any real or DNS name.
time Any
when is the local uucio allowed to call the specified remote system?
port mail.imarketingplatform.com
Look for a corresponding communications port description in /etc/uucp/port
call-login *
The username we will use to do UUCP authentication with the remote system will be looked up in /etc/uucp/call
call-password *
The password we will use to for UUCP authentication with the remote system will be looked up in /etc/uucp/call
protocol a
This tells uucico to use the Taylor uucp 'a' file transfer protocol. Experience has shown this to be the best choice for links with asymmetric bandwidth (ie, most DSL and cable modem setups)
sequence true
Use conversation sequencing. This is a security measure.
free-space 67108864
Ensures that at least 64Mbytes of space will be available after receiving the incoming file. Else, the file transfer will be rejected. Keeps us from filling up /var.
commands rmail
the remote system will only be able to send email. No Usenet style news. No file transfers. No other remote command execution. This is another security restriction

So, how do things look now if we ask uucico to poll mail.imarketingplatform.com? 

$ sudo -u uucp /usr/sbin/uucico -x 11 -s mail.imarketingplatform.com; echo $?
0
$

That looks fine. Let's check the log file: 

$ uulog
uucico mail.imarketingplatform.com - (2014-10-10 17:45:46.36 22019) ERROR: No matching ports
$
remote port configuration

In this portion of the configuration, we let Taylor UUCP know how to connect to the remote system. This is configured in the /etc/uucp/port file. It should have a section reading like so: 

#
# Run a remote uucico over ssh.
#
port		mail.imarketingplatform.com-SSH
  type		pipe
  seven-bit     false
  reliable      true
  command	/usr/bin/ssh -2 -4 -a -C -c chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com -e none -k -l uucp -m umac-128-etm@openssh.com,umac-64-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128@openssh.com,umac-64@openssh.com -o BatchMode=yes -o ChallengeResponseAuthentication=no -o GSSAPIAuthentication=no -o GSSAPIKeyExchange=no -o GSSAPIClientIdentity=no -o IdentitiesOnly=yes -o IdentityFile=/var/spool/uucp/.ssh/id_rsa -o KbdInteractiveAuthentication=no -o PasswordAuthentication=no -o PermitLocalCommand=no -o PreferredAuthentications=publickey -o PubkeyAuthentication=yes -o RekeyLimit=16K -o RequestTTY=yes -o ServerAliveCountMax=3 -o ServerAliveInterval=5 -o StrictHostKeyChecking=yes -o Tunnel=no -q -tt mail.imarketingplatform.com

And now for some explanation:

port mail.imarketingplatform.com-SSH
This is the name of the port as referenced in the /etc/uucp/sys file.
type pipe
This is a UNIX pipe. Other possibilities cover the use of modems, direct serial connections, and a few other possibilities
command /usr/bin/ssh ...
This is the command which will be run. It will read its input from uucico, and its out will be read by uucico. There are a boatload of options specified here. Some details on those:
-2
Use SSH protocol version 2. SSH protocol version 1 has known security flaws and should not be used.
-4
connect using IPv4. IPv6 connections will not be attempted
-a
disable forwarding of an SSH authentication agent (ssh-agent, ssh-add, etc)
-C
enable compression of the SSH traffic
-c chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
These are the ciphers the SSH client will propose to the servers
-e none
No escape character for this client. This allows 8 bit clean data transmission between the client and server
-k
disables GSSAPI authentication with the server. We don't have Kerberos
-l uucp
user name we will authenticate as to the server
-m umac-128-etm@openssh.com,umac-64-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128@openssh.com,umac-64@openssh.com
Message Authentication Codes (MACs) we will offer to use with the server
-o BatchMode=yes
Do not ask the user running the ssh client for any input before authenticating
-o ChallengeResponseAuthentication=no
decline the ChallengeRepsonse authentication method
-o GSSAPIAuthentication=no
decline the GSSAPIAuthentication authentication method
-o GSSAPIKeyExchange=no
decline exchange of GSSAPI keys
-o GSSAPIClientIdentity=no
Do not identify the client with a GSSAPI key
-o IdentitiesOnly=yes
use only public key identities specified on the command line. Do not any keys given by an SSH agent
-o IdentityFile=/var/spool/uucp/.ssh/id_rsa
Use this private key. We made this earlier, up in the SSH layer section
-o KbdInteractiveAuthentication=no
Don't do keyboard interactive authentication
-o PasswordAuthentication=no
Don't try to password authentication
-o PermitLocalCommand=no
Do not allow the client to run local command by a keyboard escape
-o PreferredAuthentications=publickey
Offer only publickey authentication to the SSH server
-o PubkeyAuthentication=yes
Accept offers of public key authentication from the server
-o RekeyLimit=16k
Rekey the connection after 16kbytes of exchanged data
-o RequestTTY=yes
Request that the server allocate a pseudo TTY device.
-o ServerAliveCountMax=3
If the server stops talking to us for 3 ServerAliveIntervals (next item), close the connection. We'll try again soon.
-o ServerAliveInterval=5
5 seconds without traffic over the connection and we'll ask the server if it's alive.
-o StrictHostKeyChecking=yes
the SSH client will not add an entry to the .ssh/known_hosts file
-o Tunnel=no
do not try to create a layer 2 or layer 3 tunnel with the other end.
-q
Make the client be quiet
-tt
Force allocation of a pseudo TTY on the server side
mail.imarketingplatform.com
The name of the SSH server we'll be connecting to

Important: Quotes and backslash escapes do not work in Taylor UUCP config files. Do not try to use them on SSH option parameters in this file. Mysterious failures will ensue.

Save this file and try the running uucico again: 

$ sudo -u uucp /usr/sbin/uucico -x 11 -s mail.imarketingplatform.com; echo $?
0
$

And check the logs: 

$ uulog
uucico mail.imarketingplatform.com - (2014-10-10 21:04:05.18 30393) Calling system mail.imarketingplatform.com (port mail.imarketingplatform.com-SSH)
uucico mail.imarketingplatform.com - (2014-10-10 21:04:05.18 30393) ERROR: Line disconnected
$

Hmm. What does the UUCP debug log have to say? 

$ sudo uulog -D
uucico mail.imarketingplatform.com - (2014-10-10 21:04:05.18 30393) DEBUG: fconn_open: Opening port mail.imarketingplatform.com-SSH (default speed)
uucico mail.imarketingplatform.com - (2014-10-10 21:04:05.18 30393) Calling system mail.imarketingplatform.com (port mail.imarketingplatform.com-SSH)
uucico mail.imarketingplatform.com - (2014-10-10 21:04:05.18 30393) DEBUG: Forking /usr/bin/ssh -2 -4 -a -C -c chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128- gcm@openssh.com -e none -k -l uucp -m umac-128-etm@openssh.com,umac-64-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128@openssh.com,umac-64@openssh.com -o BatchMode=yes -o ChallengeResponseAuthentication=no -o GSSAPIAuthentication=no -o GSSAPIKeyExchange=no -o GSSAPIClientIdentity=no -o IdentitiesOnly=yes -o IdentityFile=/var/spool/uucp/.ssh/id_rsa -o KbdInteractiveAuthentication=no -o PasswordAuthentication=no -o PermitLocalCommand=no -o PreferredAuthentications=publickey -o PubkeyAuthentication=yes -o RekeyLimit="64K 10s" -o RequestTTY=yes -o ServerAliveCountMax=3 -o ServerAliveInterval=5 -o StrictHostKeyChecking=yes -o Tunnel=no mail.imarketingplatform.com
uucico mail.imarketingplatform.com - (2014-10-10 21:04:05.18 30393) DEBUG: fcsend: Writing "\r"
uucico mail.imarketingplatform.com - (2014-10-10 21:04:05.18 30393) DEBUG: icexpect: Looking for 5 "ogin:"
uucico mail.imarketingplatform.com - (2014-10-10 21:04:05.18 30393) DEBUG: icexpect: Got "uucico mail.imarketingplatform.com - (2014-10-10 21:04:05.18 30393) ERROR: Line disconnected
" (error)
uucico mail.imarketingplatform.com - (2014-10-10 21:04:05.18 30393) DEBUG: fconn_close: Closing connection
uucico mail.imarketingplatform.com - (2014-10-10 21:04:09.18 30393) DEBUG: Exit status 255
uucico mail.imarketingplatform.com - (2014-10-10 21:04:09.18 30393) DEBUG: Call failed: 3 (Login failed)
uucico mail.imarketingplatform.com - (2014-10-10 21:04:09.19 30398) DEBUG: usysdep_detach: Forked; old PID 30393, new pid 30398
uucico - - (2014-10-10 21:04:09.19 30399) DEBUG: usysdep_detach: Forked; old PID 30398, new pid 30399
uucico - - (2014-10-10 21:04:09.19 30399) DEBUG: Forking /usr/sbin/uuxqt
$

So it's not working yet, but it does appear to be connecting to the SSH server successfully. And it's looking for the string "ogin:", but isn't seeing that. Which we'd expect, since the authorized_keys file says that the remote uucico won't give a login prompt (/usr/sbin/uucico ... --login arch.imarketingplatform.com is in the command run when that key is used to authenticate.)

We'll need to change the chat script the leaf node's uucico is using to adjust for the lack of a "login: " prompt.

fixing the chat script

Here, uucico is saying that it doesn't know how to connect to the remote system we told it to talk to. Which goes back to the port mail.imarketingplatform.com listing in our /etc/uucp/sys file. We'll fix that next.

Back to /etc/uucp/sys, add this to the end of our mail.imarketingform.com system section: 

chat-timeout    5
chat            word: \P

Running uucico again and checking the debug log, shows a different output now. Right after "icexpect: Looking for 5 "word:"", we see a line that says "DEBUG: icexpect: Got": 

uucico mail.imarketingplatform.com - (2014-10-10 22:06:10.73 32679) DEBUG: fconn_open: Opening port mail.imarketingplatform.com-SSH (default speed)
uucico mail.imarketingplatform.com - (2014-10-10 22:06:10.73 32679) Calling system mail.imarketingplatform.com (port mail.imarketingplatform.com-SSH)
uucico mail.imarketingplatform.com - (2014-10-10 22:06:10.73 32679) DEBUG: Forking /usr/bin/ssh -2 -4 -a -C -c chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128- gcm@openssh.com -e none -k -l uucp -m umac-128-etm@openssh.com,umac-64-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128@openssh.com,umac-64@openssh.com -o BatchMode=yes -o ChallengeResponseAuthentication=no -o GSSAPIAuthentication=no -o GSSAPIKeyExchange=no -o GSSAPIClientIdentity=no -o IdentitiesOnly=yes -o IdentityFile=/var/spool/uucp/.ssh/id_rsa -o KbdInteractiveAuthentication=no -o PasswordAuthentication=no -o PermitLocalCommand=no -o PreferredAuthentications=publickey -o PubkeyAuthentication=yes -o RekeyLimit="16K 5s" -o RequestTTY=yes -o ServerAliveCountMax=3 -o ServerAliveInterval=5 -o StrictHostKeyChecking=yes -o Tunnel=no mail.imarketingplatform.com
uucico mail.imarketingplatform.com - (2014-10-10 22:06:10.73 32679) DEBUG: icexpect: Looking for 5 "word:"
uucico mail.imarketingplatform.com - (2014-10-10 22:06:10.73 32679) DEBUG: icexpect: Got "uucico mail.imarketingplatform.com - (2014-10-10 22:06:10.73 32679) ERROR: Line disconnected
" (error)
uucico mail.imarketingplatform.com - (2014-10-10 22:06:10.73 32679) DEBUG: fconn_close: Closing connection
uucico mail.imarketingplatform.com - (2014-10-10 22:06:14.73 32679) DEBUG: Exit status 255
uucico mail.imarketingplatform.com - (2014-10-10 22:06:14.73 32679) DEBUG: Call failed: 3 (Login failed)
uucico mail.imarketingplatform.com - (2014-10-10 22:06:14.73 32683) DEBUG: usysdep_detach: Forked; old PID 32679, new pid 32683
uucico - - (2014-10-10 22:06:14.73 32684) DEBUG: usysdep_detach: Forked; old PID 32683, new pid 32684
uucico - - (2014-10-10 22:06:14.73 32684) DEBUG: Forking /usr/sbin/uuxqt

So uucico is now looking for "word:" instead of "ogin:". We haven't yet specified a password to send. That goes in /etc/uucp/call. Add a line like so at the end: 

mail.imarketingplatform.com     arch.imarketingplatform.com    choo1zei6su4Oofoov3eekohshii0liR8ii4gahJ3gaiqu7ahDi9zoh7ufaehi5k

Punctuation characters are problematic as UUCP passwords. Just do really long, random alphanumeric strings for passwords. A corresponding line will be needed in /etc/uucp/passwd on the server side. It has a similar format, but omits the first field.

server side

Set the server system's UUCP node name

The server presents a name when a client connects. If this name does not match what the client is expecting, the client will hang up. (Smart, huh?)

Add the following in /etc/uucp/config: 

nodename        mail.imarketingplatform.com
make the leaf system known

Add info to /etc/uucp/sys on the hub system: 

system arch.imarketingplatform.com
  time          Never
  call-login    *
  call-password *
  protocol      a
  sequence      true
  free-space    67108864

This is pretty much a turned around version of /etc/uucp/sys file on the leaf system. It is important that the hub system knows the leaf system exists, though. Else authentication will fail miserably.

add a password so the leaf system can authenticate

Speaking of authentication, we'll need some entries in /etc/uucp/passwd on the hub system: 

arch.imarketingplatform.com    choo1zei6su4Oofoov3eekohshii0liR8ii4gahJ3gaiqu7ahDi9zoh7ufaehi5k

test it

Do this on the leaf node: 

$ sudo -u uucp /usr/sbin/uucico -x 11 -s mail.imarketingplatform.com; echo $?
0
$ uulog
uucico mail.imarketingplatform.com - (2014-10-16 03:55:33.03 4968) Calling system mail.imarketingplatform.com (port mail.imarketingplatform.com-SSH)
uucico mail.imarketingplatform.com - (2014-10-16 03:55:34.35 4968) Login successful
uucico mail.imarketingplatform.com - (2014-10-16 03:55:34.49 4968) Handshake successful (protocol 'a' starting: 10, 10, 4, 2400, 16384, 0)
uucico mail.imarketingplatform.com - (2014-10-16 03:55:44.73 4968) Protocol 'a' messages: sent 11, received 10
uucico mail.imarketingplatform.com - (2014-10-16 03:55:44.73 4968) Protocol 'a' packets: sent 2, received 1
uucico mail.imarketingplatform.com - (2014-10-16 03:55:44.73 4968) Protocol 'a' errors: bytes resent 0, timeouts 1, errors 0
uucico mail.imarketingplatform.com - (2014-10-16 03:55:44.77 4968) Call complete (10 seconds 0 bytes 0 bps)
$

This says leaf node called the hub node. Logged in successfully. And no files were transfered. uulog -D will dump a lot more debug info.

Postfix

A very nice Internet mail transfer agent. Human readable config files (I'm looking at you, sendmail). Decent logging. Acts like a UNIXy program (I'm looking at you, qmail).

Telling postfix about the UUCP message transport service

This goes on both the hub and leaf nodes. Add an entry in /etc/postfix/master.cf: 

uucp      unix  -       n       n       -       -       pipe
  flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)

master.cf is where each of Postfix's "services" (components which run in separate processes) lives, how to start it, and how to communicate with it.

Tell the hub how get mail destined for the leaf node to the leaf node, using the UUCP transport

Retrieved from "https://wiki.fnord.greeley.co.us/mediawiki/index.php?title=Postfix%2Buucp%2Bssh&oldid=689"