mirror of https://github.com/tLDP/LDP
298 lines
11 KiB
Plaintext
298 lines
11 KiB
Plaintext
<!doctype linuxdoc system>
|
|
|
|
<article>
|
|
|
|
<title>Secure POP via SSH mini-HOWTO
|
|
<author>Manish Singh, <tt><htmlurl url="mailto:yosh@gimp.org"
|
|
name="<yosh@gimp.org>"></tt>
|
|
<date>v1.0, 30 September 1998
|
|
|
|
<abstract>
|
|
This document explains how to set up secure POP connections using ssh.
|
|
</abstract>
|
|
|
|
<toc>
|
|
|
|
<sect>Introduction
|
|
<p>
|
|
|
|
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, <bf/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.
|
|
|
|
<sect>The Basic Technique
|
|
<p>
|
|
|
|
This technique relies on a fundamental feature of ssh: <em/port forwarding/
|
|
|
|
There are many variations on this theme, which depend on your desired mail
|
|
setup. They all require ssh, which is available from
|
|
<htmlurl url="http://www.ssh.fi/"
|
|
name="http://www.ssh.fi/"> and mirrors.
|
|
RPMs are available at
|
|
<htmlurl url="ftp://ftp.replay.com/pub/crypto/"
|
|
name="ftp://ftp.replay.com/pub/crypto/">
|
|
and Debian packages are available at
|
|
<htmlurl url="ftp://non-us.debian.org/debian-non-US/"
|
|
name="ftp://non-us.debian.org/debian-non-US/">
|
|
(and their respective mirrors).
|
|
|
|
<sect1>Setting up Port Forwarding
|
|
<p>
|
|
|
|
To start port forwarding, run the following command:
|
|
|
|
<tscreen><verb>
|
|
ssh -C -f popserver -L 11110:popserver:110 sleep 5
|
|
</verb></tscreen>
|
|
|
|
Let's take a closer look at that command:
|
|
|
|
<descrip>
|
|
|
|
<tag><tt/ssh/</tag>
|
|
The ssh binary itself, the magic program that does it all.
|
|
|
|
<tag><tt/-C/</tag>
|
|
This enables compression of the datastream. It's optional, but usually useful,
|
|
especially for dialup users.
|
|
|
|
<tag><tt/-f/</tag>
|
|
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.
|
|
|
|
<tag><tt/popserver/</tag>
|
|
The POP server we're connecting to.
|
|
|
|
<tag><tt/-L 11110:popserver:110/</tag>
|
|
Forward local port 11110 to port 110 on the remote server <tt/popserver/. We
|
|
use a high local port (11110) so any user can create forwardings.
|
|
|
|
<tag><tt/sleep 5/</tag>
|
|
After ssh has forked itself into the background, it runs a command. We use
|
|
<tt/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.
|
|
|
|
</descrip>
|
|
|
|
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 <em/requires/ sshd running on the remote server <tt/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.
|
|
|
|
<sect1>Testing it out
|
|
<p>
|
|
|
|
Once you've figured out the details command to run to establish port
|
|
forwarding, you can try it. For example:
|
|
|
|
<tscreen><verb>
|
|
$ ssh -C -f msingh@popserver -L 11110:popserver:110 sleep 1000
|
|
</verb></tscreen>
|
|
|
|
<tt/popserver/ is the ol' POP server. My username on my local machine is
|
|
<tt/manish/ so I need to explicitly specify the username <tt/msingh/. (If
|
|
your local and remote usernames are the same the <tt/msingh@/ part is
|
|
unnecessary.
|
|
|
|
Then it prints:
|
|
|
|
<tscreen><verb>
|
|
msingh@popserver's password:
|
|
</verb></tscreen>
|
|
|
|
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:
|
|
|
|
<tscreen><verb>
|
|
$ telnet localhost 11110
|
|
</verb></tscreen>
|
|
|
|
which should print something like:
|
|
|
|
<tscreen><verb>
|
|
QUALCOMM POP v3.33 ready.
|
|
</verb></tscreen>
|
|
|
|
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.
|
|
|
|
<sect>Using it With Your Mail Software
|
|
<p>
|
|
|
|
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
|
|
<htmlurl url="http://www.tuxedo.org/~esr/fetchmail/"
|
|
name="http://www.tuxedo.org/~esr/fetchmail/">.
|
|
It will do you a great service to read the excellent documentation that
|
|
comes with fetchmail.
|
|
|
|
<sect1>Setting up fetchmail
|
|
<p>
|
|
|
|
The following is my <tt/.fetchmailrc/
|
|
|
|
<tscreen><code>
|
|
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;
|
|
</code></tscreen>
|
|
|
|
Pretty simple, huh? fetchmail has a wealth of commands, but the key ones are
|
|
the <tt/preconnect/ line and the <tt/poll/ option.
|
|
|
|
We're not connecting directly to the POP server, but instead localhost and
|
|
port 11110. The <tt/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.
|
|
|
|
<sect1>Automating it all
|
|
<p>
|
|
|
|
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
|
|
<tt/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 <tt/.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 <bf/agent/, which can register keys and
|
|
authenticate whatever ssh connections are made under it. So I have this
|
|
script <tt/getmail.sh/:
|
|
|
|
<tscreen><code>
|
|
#!/bin/sh
|
|
ssh-add
|
|
while true; do fetchmail --syslog --invisible; sleep 5m; done
|
|
</code></tscreen>
|
|
|
|
When I dialup, I run:
|
|
|
|
<tscreen><verb>
|
|
$ ssh-agent getmail.sh
|
|
</verb></tscreen>
|
|
|
|
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)
|
|
|
|
<sect1>Not using fetchmail
|
|
<p>
|
|
|
|
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 <tt/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.
|
|
|
|
<sect>Miscellany
|
|
|
|
<sect1>Disclaimer
|
|
<p>
|
|
|
|
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.
|
|
|
|
<sect1>Copyright
|
|
<p>
|
|
|
|
This document is copyright © 1998 Manish Singh
|
|
<htmlurl url="mailto:yosh@gimp.org"
|
|
name="<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.
|
|
|
|
<sect1>Acknowledgements
|
|
<p>
|
|
|
|
Special thanks goes to Seth David Schoen
|
|
<htmlurl url="mailto:schoen@uclink4.berkeley.edu"
|
|
name="<schoen@uclink4.berkeley.edu>">,
|
|
who enlightened me in the ways of ssh port forwarding.
|
|
|
|
</article>
|