350 lines
11 KiB
Plaintext
350 lines
11 KiB
Plaintext
Secure POP via SSH mini-HOWTO
|
||
Manish Singh, <yosh@gimp.org>
|
||
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 <20> 1998 Manish Singh <yosh@gimp.org>
|
||
|
||
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
|
||
<schoen@uclink4.berkeley.edu>, who enlightened me in the ways of ssh
|
||
port forwarding.
|
||
|
||
|
||
|