One, any wireless links you use for anything should be encrypted with a WEP key. Not just email and not just for sensitive information. An exposed home wireless router will allow any intruder to use your bandwidth, even if your information is no use to them.

Two, any sensitive-information email should be encrypted with a personal certificate and the receiver must use your public certificate to decrypt it. Otherwise, whether you use SSH or not is irrelevant once the email is in route to the receiving SMTP server. Many people (including corporations) are taking great lengths to protect their systems, but no effort is made to educate the end-user as to encryption usage and privacy requirements. I’ve also blogged about this serious omission related to today’s IT environments:

http://www.linkany.com/plog/index.php?op=ViewArticle&articleId=17&blogId=3

Three, if you are an ISP or hosting email provider or IT manager, you should absolutely set up SPF records for the sending domains you’re responsible for, backup storage for emails (European law requires 10 years of emails to be saved for corporations), updated working anti-spam filtering (EU law also requires this), and intelligent anti-virus protection (not just blocking attachments).

For Windows users I’d highly recommend PuTTY, an excellent free (MIT licence) terminal emulator that does port forwarding, as well as telnet, SCP, SFTP. (The Pageant tool in PuTTY is the equivalent of ssh-agent, and sits in the tray.) To go with that: a pretty much identical to Doug’s but for PuTTY/Windows tutorial and another PuTTY port forwarding howto for good measure.

There is a configuration file for the ssh client called “config”. It is located in the “.ssh/” directory under your home directory. Below is a slightly munged and pared listing of my ssh config file:

— begin file listing —
# this is a comment

Host *
#Compression yes
Compression no
#CompressionLevel 9
CompressionLevel 0
ForwardX11 yes
KeepAlive yes
StrictHostKeyChecking no
NoHostAuthenticationForLocalhost yes
EscapeChar ~
#VerifyHostKeyDNS yes

Host uncensored
HostName uncensored.citadel.org
User bbs
LocalForward 1304 uncensored.citadel.org:110
LocalForward 1305 uncensored.citadel.org:143
Compression yes
CompressionLevel 9

Host osuny.inri.net
User bbs
Compression yes
CompressionLevel 9

Host eisner
HostName encompasserve.org
#User some_user
Compression yes
CompressionLevel 9
LocalForward 1302 mail.encompasserve.org:25
LocalForward 1303 mail.encompasserve.org:993
LocalForward 1301 mail.encompasserve.org:995
ForwardX11 yes
ServerAliveInterval 70

Host eisner.proxy
HostName encompasserve.org
ProxyCommand /home/bork/bin/stunnel %h %p
Compression yes
CompressionLevel 9
LocalForward 1302 mail.encompasserve.org:25
LocalForward 1303 mail.encompasserve.org:993
LocalForward 1301 mail.encompasserve.org:995
ForwardX11 yes
ServerAliveInterval 70

Host ferdberful
Compression no
CompressionLevel 0
Ciphers blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

Host pizzabox
Compression no
CompressionLevel 0
ForwardAgent yes
Ciphers blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
ForwardX11 yes

Host manson
HostName manson.vistech.net
User bork
Compression yes
CompressionLevel 9
Ciphers blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
ForwardX11 yes
ServerAliveInterval 70

Host dahmer
#HostName openvms-rocks.com
HostName dahmer.vistech.net
Compression yes
CompressionLevel 9
ForwardX11 yes
ServerAliveInterval 70

— end file listing —

You can read about the options used here in the “ssh_config” man page. The entry for “uncensored” is worth noting as it allows me to simply type “ssh uncensored” at the commandline to login into “uncensored.citadel.org” as the user “bbs”, setup some tunnels, and turn on compression (compression is usefull on slow links like dialup internet access).

The reason I specify the order of ciphers to use when logging into some machines is because they are slow. Specifying this order lets me use a faster cipher for these machines which makes ssh work faster on them.

Finally let me mention that while I don’t have a mac myself I have read enough about Mac OS X to know that it uses OpenSSH which I have lots of experience with. As for the OSes I use they are linux, Solaris, OpenVMS, and NetBSD. Most of my working computers are non x86 architecture stuff.

Grurp

I’m already doing this with a Yahoo email account, as you might be able to tell above in the post where I show my local/remote port equivalents table. Works the same as any other email account, as long as you already have POP access to your Yahoo account (a paid feature, I believe, but it also comes with SBC/Yahoo DSL).

If you don’t get it working for some reason, find me in Austin before the conference gets going. I’ll be there Friday night onward.

Can I do what Doug’s suggested using Mail.app accessing accounts on Yahoo? If *you* have done this, please let me know!

I had been searching for a solution to having port 25 blocked by wireless hotspots, bt I also like the idea of securing my e-mail and ftp transmissions in general.

Unfotunately, whils I can create a tunnell into my domain, I cannot access either the POP server or the SMTP server. This may be because I host on a server farm, and the mailservers are actually at a different domain than my own, and I can’t get direct SSH access to them. Is there a way around this (for a not too proficient unix newbie)?

Thanks,

Roger

Either

1) Your SMTP server does not require any sort of authentication (it’s an “open relay”, and you should promptly switch providers, or it uses antiquated methods like “POP before SMTP”).

2) It uses SMTP Auth and provides “secure” authentication schemes, like CRAM-MD5 or DIGEST-MD5 (both of which are natively supported by Apple’s Mail client).

3) It uses SMTP Auth + TLS and uses a ‘cleartext’ authentication scheme, tunnelled over the TLS connection.

I’m hard-pressed to think of a provider that doesn’t fall into one of these three classes.

On the receiving end, again, “most” POP3 servers support either APOP authentication or POP3-over-SSL (both of which are supported by Apple’s Mail client). And most modern IMAP servers support SSL connections.

The biggest problem I’ve had doing mail over wireless is Port 25-blocking.

Mind you, I use SSH tunnelling for all kinds of other stuff (VNC, MySQL, …). Just not for mail …

However, I (hopefully) found another solution for securing outgoing mail from my Powerbook. I downloaded a program called Postfix Enabler that allows you to set up your powerbook as its own localhost SMTP server. Not only this, but it creates local SSL certificates so that you can turn SSL on in your outgoing mail settings in Mail.

I’ve just sent a few emails using this method, and it seems to work quite well. Does anybody know if this is actually a reliable way of sending email securely? I’m not an expert at this stuff, so if anybody has any cautionary notes, I’d be glad to take heed. Thanks!

So confused.

And to echo lots of comments above: yes, if you have the ability to use SSL for your connections, USE IT! Using SSL will secure mail all the way to your mail server. You don’t need SSH, or SSHTM, or any of the steps in my original post if that’s the case.

My SSH server and my mail server happen to be on the same machine — everything is self-contained on one box. So, [I think] in my case, I’m essentially getting the same extensiveness of security that SSL would provide. Other people may SSH into a different box than their mail server. As Joe says above, once past the SSH server, hopefully at that point, your mail is passing along on a trusted wired network, where sniffing isn’t as much an issue, nor possible without root (or similar high-privilege) access to one of the destination or intermediary relay servers.

Here is what it should look like:
Mail client -> SSH Tunnel Manager RUNNING ON SAME COMPUTER (this provides a secure connection) -> Internet (still secure here) -> Other computer running sshd (daemon) -> Internet from other computer (insecure now, unless using SSL or similar) -> Mail server.

So essentially, you make a secure tunnel to some other machine. From then on, you are NOT secured unless using another secure connection like SSL to your mail server. SSH Tunnel manager does the job of opening the tunnel and securing the connection (with ssh). Once your laptop is connected to the other computer, you are basically using the other computer’s ports you specify as your own.

The key thing to get here is that we are NOT trying to get an end-to-end secure connection between the laptop on wireless and the mail server. We are ONLY concerned about going from the wireless connection to an intermediary (Other computer in this example, something you trust) securely. Once we are at the other computer, we should hopefully be on a wired connection that we can mostly trust to talk to our mailserver.

Using SSL, as proposed in many posts above, allows complete end to end security, but you wouldn’t need ssh tunnels if you could communicate that way.

SSH is only being used to secure your wireless communications from an untrusted wireless network where your traffic could be sniffed to a “secure” network that you yourself trust.

If you need some more explanation, I can draw up a little picture of what this looks like.