Secure POP via SSH mini-HOWTO Manish Singh, v1.0, 30 September 1998 This document explains how to set up secure POP connections using ssh. ______________________________________________________________________ Table of Contents 1. Introduction 2. The Basic Technique 2.1 Setting up Port Forwarding 2.2 Testing it out 3. Using it With Your Mail Software 3.1 Setting up fetchmail 3.2 Automating it all 3.3 Not using fetchmail 4. Miscellany 4.1 Disclaimer 4.2 Copyright 4.3 Acknowledgements ______________________________________________________________________ 1. Introduction Normal POP mail sessions, by their very nature, are insecure. The password goes across the network in cleartext for everyone to see. Now, this may be perfectly acceptable in a trusted or firewalled environment. But on a public network, such as a university or your run-of-the-mill ISP, anyone armed with a simple network sniffer can grab your password right off the wire. This is compounded by the fact that many people set their computers to check for mail at regular intervals, so the password is sent out quite frequently, which makes it easy to sniff. With this password, an attacker can now access your email account, which may have sensitive or private information. It is also quite common that this password is the same as the user's shell account, so there is the possibility for more damage. By doing all POP traffic using an encrypted channel, nothing goes in cleartext over the network. We can use ssh's diverse methods of authentication, instead of a simple plaintext password. That is the real point of using this method: not because we get encrypted content (which is futile at this point, since it's probably gone unencrypted over several networks already before reaching your mailbox; securing those communications is the job of GNU Privacy Guard or PGP, not ssh), but the secure authentication. There are other methods of achieving secure authentication already, such as APOP, KPOP, and IMAP. However, using ssh has the advantage that it works with normal POP configurations, without requiring special client (not all mail clients support advanced protocols) or server support (except for sshd running on the server). You mail provider may be unable or unwilling to use a more secure protocol. Besides, by using ssh you can compress the traffic too, which is a nice little extra for people with slow connections. 2. The Basic Technique This technique relies on a fundamental feature of ssh: port forwarding There are many variations on this theme, which depend on your desired mail setup. They all require ssh, which is available from http://www.ssh.fi/ and mirrors. RPMs are available at ftp://ftp.replay.com/pub/crypto/ and Debian packages are available at ftp://non-us.debian.org/debian-non-US/ (and their respective mirrors). 2.1. Setting up Port Forwarding To start port forwarding, run the following command: ssh -C -f popserver -L 11110:popserver:110 sleep 5 Let's take a closer look at that command: ssh The ssh binary itself, the magic program that does it all. -C This enables compression of the datastream. It's optional, but usually useful, especially for dialup users. -f Once ssh has done authentication and established port forwarding, fork to background so other programs can be run. Since we're just using the port forwarding features of ssh, we don't need a tty attached to it. popserver The POP server we're connecting to. -L 11110:popserver:110 Forward local port 11110 to port 110 on the remote server popserver. We use a high local port (11110) so any user can create forwardings. sleep 5 After ssh has forked itself into the background, it runs a command. We use sleep so that the connection is maintained for enough time for our mail client to setup a connection to the server. 5 seconds is usually sufficient time for this to happen. You can use most other options to ssh when appropriate. A common setting may be a username, since it might be different on the POP server. This requires sshd running on the remote server popserver. However, you do not need to have an active shell account there. The time it takes to print a message ``You cannot telnet here'' is enough to setup a connection. 2.2. Testing it out Once you've figured out the details command to run to establish port forwarding, you can try it. For example: $ ssh -C -f msingh@popserver -L 11110:popserver:110 sleep 1000 popserver is the ol' POP server. My username on my local machine is manish so I need to explicitly specify the username msingh. (If your local and remote usernames are the same the msingh@ part is unnecessary. Then it prints: msingh@popserver's password: And I type in my POP password (you may have different shell and POP passwords though, so use your shell one). Now we're done! So we can try: $ telnet localhost 11110 which should print something like: QUALCOMM POP v3.33 ready. Woohoo! It works! The data is sent out over the network encrypted, so the only cleartext is over the loopback interfaces of my local box and the POP server. 3. Using it With Your Mail Software This section describes setting up your POP client software to use the ssh forwarded connection. It's primary focus is fetchmail (ESR's excellent mail-retrieval and forwarding utility), since that is the most flexible software I have found for dealing with POP. fetchmail can be found at http://www.tuxedo.org/~esr/fetchmail/. It will do you a great service to read the excellent documentation that comes with fetchmail. 3.1. Setting up fetchmail The following is my .fetchmailrc ______________________________________________________________________ defaults user msingh is manish no rewrite poll localhost with protocol pop3 and port 11110: preconnect "ssh -C -f msingh@popserver -L 11110:popserver:110 sleep 5" password foobar; ______________________________________________________________________ Pretty simple, huh? fetchmail has a wealth of commands, but the key ones are the preconnect line and the poll option. We're not connecting directly to the POP server, but instead localhost and port 11110. The preconnect does the forwarding each time fetchmail is run, leaving open the connection for 5 seconds, so fetchmail can make it's own connect. The rest fetchmail does itself. So each time you run fetchmail, you're prompted for your ssh password for authentication. If you run fetchmail in the background (like I do), it's inconvenient to have to do that. Which brings us to the next section. 3.2. Automating it all ssh can authenticate using many methods. One of these is an RSA public/private key pair. You can generate an authentication key for your account using ssh-keygen. An authetication key can have a passphrase associated with it, or the passphase can be blank. Whether you want a passphrase depends on how secure you think the account you are using locally is. If you think your machine is secure, go ahead and have a blank passpharase. Then the above .fetchmailrc works just by running fetchmail. You can then run fetchmail in daemon mode when you dial up and mail is fetched automatically. You're done. However, if you think you need a passphrase, things get more complex. ssh can run under control of an agent, which can register keys and authenticate whatever ssh connections are made under it. So I have this script getmail.sh: ______________________________________________________________________ #!/bin/sh ssh-add while true; do fetchmail --syslog --invisible; sleep 5m; done ______________________________________________________________________ When I dialup, I run: $ ssh-agent getmail.sh This prompts me for my passphrase once, then checks mail every 5 minutes. When the dialup connection is closed, I terminate ssh-agent. (This is automated in my ip-up and ip-down scripts) 3.3. Not using fetchmail What if I can't/don't want to use fetchmail? Pine, Netscape, and some other clients have their own POP mechanisms. First, consider using fetchmail! It's far more flexible, and mail clients shouldn't be doing that kind of stuff anyway. Both Pine and Netscape can be configured to use local mail systems. But if you must, unless your client has a preconnect feature like fetchmail, you're going to have to keep the ssh port forward active for the entire time you're connected. Which means using sleep 100000000 to keep the connection alive. This might not go over well with your network admins. Secondly, some clients (like Netscape) have the port number hardcoded to 110. So you need to be root to do port forwarding from privledged ports. This is also annoying. But it should work. 4. Miscellany 4.1. Disclaimer There is no guarantee that this document lives up to its intended purpose. This is simply provided as a free resource. As such, the author of the information provided within cannot make any guarentee that the information is even accurate. Use at your own risk. Cryptographic software such as ssh may be subject to certain restrictions, depending on where you live. In some countries, you must have a license to use such software. If you are unsure of your local laws, please consult someone who is familiar with your situation for more information. The use of the information provided in this document is most likely not anticipated by your mail service provider. The author does not encourage the abuse and misuse of network services, and provides this document for informational purposes only. If you are in doubt about whether the use of these techniques falls within the service agreement of your mail provider, please clear that up beforehand. 4.2. Copyright This document is copyright 1998 Manish Singh Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this document under the conditions for verbatim copying, provided that this copyright notice is included exactly as in the original, and that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this document into another language, under the above conditions for modified versions. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions. All trademarks used in this document are acknowledged as being owned by their respective owners. 4.3. Acknowledgements Special thanks goes to Seth David Schoen , who enlightened me in the ways of ssh port forwarding.