MacDevCenter.com: Personal Security on Jaguar: The Secure Shell, Part 1

Published on MacDevCenter (http://www.macdevcenter.com/)
See this if you're having trouble printing code examples

Personal Security on Jaguar: The Secure Shell, Part 1

by Chris Cochella
05/01/2003

In a world full of spam, identity theft, and heightened national security, no one can argue that personal security isn't important. Many of us shred paper records of personal information to keep them from dumpster divers. Yet sometimes we forget to take those same precautions with our digital information. In some cases our digital data--personal ID numbers (PINs) and passwords--are more important than paper information.

Why do we let our guard down in the digital realm? Is this discrepancy due to the complexity of digitally shredding documents compared to paper shredding? I find it much simpler to shred paper than setup an encryption tunnel. But protecting our digital information is just as important if not more so.

The goal of this article is to help you improve your daily security habits by learning how to use a few cool software programs included with Jaguar, while making these habits easy and transparent to implement. Let's face it, if we can't make it relatively easy, we won't do it.

There are multiple security technologies that fit in the category of personal security including the configuration of Jaguar's firewall, SSL (Secure Sockets Layer), and file encryption with protocols like Pretty Good Privacy (keep an eye out for an upcoming article on this topic). Our focus will be on another complementary security mechanism available in Jaguar, Secure Shell (SSH).

The purpose of focusing on SSH is that it can be instantly used in Jaguar to secure two of the most common daily work processes: file transfers (FTP) and email. As a web applications developer, I often connect to remote servers to upload files or make changes to sites. Wrapped around this process is a constant buzz of email communication. In the case of email and FTP we want to protect our passwords as well as the information or content that we send. SSH can do both and it costs nothing.

If this article is already too geeky, take a step back by reading The Code Book, a wonderful and exciting tour of how encryption has impacted history from the time of Elizabeth I and Mary Queen of Scots through World War II to the present day. This book will stoke anyone's interest in encryption.

Isn't this Science Fiction?

If you think that password theft by snooping on net traffic is the subject of science fiction, think again. Take a look at the following output (greatly edited for easier viewing) from a program called tcpflow, that will capture your own network-bound traffic and display it in the Terminal application.

[tibook:~] chris% sudo tcpflow -i en1 -c port 110
tcpflow[3975]: listening on en1
+OK Qpopper (version 4.0.5) at mailserver.myisp.com starting.
AUTH
USER chris
+OK Password required for chris.
PASS fido0269
+OK chris has 0 visible messages (0 hidden) in 0 octets.
QUIT
+OK Pop server at mailserver.myisp.com signing off.

Without going into the details of the tcpflow command structure, this command causes tcpflow to "listen" or grab information from port 110 and display the information that comes and goes. Port 110 is the port that POP incoming mail uses. The message is clear: "Hey, that is my username, password and mail server flying by". Yup, that's right! Notice my fabricated password for this example is "fido0269". If this were also my bank PIN (a common practice) I would be in big trouble.

If I can grab a free utility like tcpflow and do this, how hard would it be for a motivated malicious person to do this on a grand and automated scale. It would certainly be a lot cleaner than rifling through a dumpster. I don't know how to eavesdrop on the Internet at large (and I don't want to), but it's clear to me that it isn't hard.

Now that you are reliving that adolescent nightmare of showing up at school exposed in only your underwear you might be asking: "What do I do?" As you probably guessed, our digit-shredding super hero is SSH.

What is it?

SSH started out as a secure replacement for telnet, often referred to as the shell (think Terminal App), and other programs for issuing remote commands. The SSH protocol, now in version 2 (often shown as SSH-2), has evolved to do a lot more like secure FTP (SFTP) and tunneling, which we will get to later. First, we will do the basics and then ramp up.

SSH version 2 is more secure than version 1 and is now widely adopted. Thus, I'll focus on the SSH-2 protocol and supporting products. I won't, however, discuss compatibility issues with SSH-1. In most cases compatibility between protocol versions is not a problem and we will not prospectively problem-solve these possibilities here.

For more information on SSH-1 and SSH-2, including complicated configurations, please refer to the clear and well-written book SSH, The Secure Shell: The Definitive Guide by Daniel J. Barrett and Richard Silverman. To be honest, my digital life would still be exposed if it were not for the usefulness of this book.

Where Is It?

You can find the SSH command in Jaguar at the following location,

[tibook:~] chris% which ssh
/usr/bin/ssh

Your version of ssh can be determined with the following command:

[tibook:~] chris% ssh -V
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL

Notice that Jaguar uses OpenSSH, which is a very common public license version with a cool fish logo.

Screen shot.
The OpenSSH Logo.

Two of the major managed server and website hosting companies I work with use OpenSSH on FreeBSD and Red Hat Linux, which were easy to integrate with Jaguar's version of SSH. In most cases, you will not experience any problems.

And, like all good shell or terminal commands, you can use the man pages

[tibook:~] chris% man ssh
SSH(1) System General Commands Manual       SSH(1)

NAME ssh - OpenSSH SSH client (remote login program)
SYNOPSIS
ssh [-l login_name] hostname | user@hostname [command]
...

Simply typing "ssh" will also return a short list of command options like:

[tibook:~] chris% ssh
Usage: ssh [options] host [command]
Options:
  -l user     Log in using this user name.
  -n          Redirect input from /dev/null.
  -F config   Config file (default: ~/.ssh/config).
  ...

These are very basic commands, but typing them before starting something new on the command line always gives me a sense of comfort. You might like the same start.

How Does SSH Work?

SSH works by establishing an encrypted dialog between a client (your computer) and a server (your ISP's email or FTP server). The dialog might start with "Please give me my email" or something like that. Note that your computer could also act as a server if you were trying to "talk" to it from a home computer during off hours.

Encryption is simply a mechanism of shredding or scrambling information before sending it, such that it can only be put back together again by the intended recipient. Therefore, the two parties in the conversation need to have compatible SSH applications installed. In a nutshell, the server and client have unique keys that are used to generate random data that is used to shred the plain text or "clear" information. The details of making strong encryption algorithms, performing authentication, and guaranteeing integrity are very interesting but beyond our purpose here. The following is shredded output similar to the email retrieval tcpflow session shown above,

[tibook:~] chris% sudo tcpflow -i en1 -c port 22 tcpflow[3972]: listening on en1 /..#1\+2Q....a...r.Fj......:.......j4.....=}..j.. #..*.....u.i.a6.fq?%P6.gjhkym+|.q........ .........9A,..T$>W...,,,,,,>K......8... U. 1.Sd...}OFXl^;.s..5..p.? >...]r...Zs7...q....gz.h.......j. >.{...1..V.Q...&..D...6.....f$.D.*.-.1.E

Not very understandable is it? That is the point.

Notice that the tcpflow command is now grabbing information on port 22, the default SSH port. Thus, all information passing through port 22 is encrypted by the SSH client and all return information from the server is received on port 22. You might be wondering how we go from the POP email port of 110 to the SSH port of 22. We will clear this up a little later when we discuss port forwarding also known as tunneling. For now it is enough to understand that the first tcpflow results were "in the clear" and now they are shredded. This brings us up to Stealth Meter level 3 (simply reading this article got us to Stealth Meter level 2).

Encrypted Password Authentication

The easiest way to get started is to begin using SSH with password authentication. There is a more secure and ultimately more convenient (although harder to setup) method of authentication using a passphrase that we will address in a later article.

Password authentication uses the password provided to you when your account was setup. SSH encrypts the password instead of sending it in plain text across the Internet as shown above, which is a vast improvement. For example,

[tibook:~] chris% ssh -l chris myisp.com The authenticity of host 'myisp.com (123.123.123.123)' can't be established. RSA key fingerprint is 0D:dc:8B:cb:87:c8:373:e4:9g:98:fc:7a:eb:d9:95:72. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'myisp.com,123.123.123.123' (RSA) to the list of known hosts. chris@myisp.com's password: FreeBSD 4.4-RELEASE (VKERN) #9: Thu Jan 2 10:23:51 MST 2003 chris%

If this is your first time accessing this server (myisp.com) with SSH, you will be prompted to accept the unique signature or fingerprint of the server. Respond with "yes" to accept and automatically store the fingerprint in a file called known_hosts inside the .ssh directory (the .ssh directory is created automatically if it did not already exist) within your home directory (e.g., ~/.ssh/known_hosts).

This fingerprint is stored so that you do not have to accept it each time; more importantly, the fingerprint on file is compared against the fingerprint of the server on subsequent future access attempts. This comparison is done to verify the server as "known" and trusted. If the fingerprints were different it might indicate that someone has inserted a server in between you and the trusted server thereby masquerading as your trusted server to intercept your private information. Because of this comparison, you will receive a warning message if this masquerading is taking place. Quickly exit from the ssh session if you receive this warning and you think there is a security problem. This situation is unlikely, but it is important for you to know about the possibility and why storing the fingerprint is useful beyond making your daily life easier.

Secure File Transferring (SFTP)

Secure file transferring involves encrypting the "data session" as well as the "command session". The command session represents the commands while the data session represents the data sent back and forth--files in this case. Some programs that encrypt FTP sessions only shred the command session. This might be acceptable if the only sensitive information were your username and password. However, a few of the files I transfer back and forth have passwords in them! If these files are "in the clear" then passwords in the files will also be "in the clear". Thus, it is safest to secure the data as well as the commands.

Secure FTP (SFTP) is basically the same as FTP but is built on top of SSH. In order for SFTP to work, compatible SSH applications must reside on the client and the server for a shredding dialog to take place. SFTP uses the same command structure and known host keys, so we can jump right in with:

[tibook:~] chris% sftp chris@myisp.com
Connecting to myisp.com...
chris@myisp.com's password:
sftp>

As you can see, SFTP command line is similar to command line FTP. For more command line SFTP options visit the man pages with the following command, man sftp. Some of you (especially graphic artists and HTML taggers) are probably saying, "Come on, I never use command line FTP". I know! Most of us Mac users typically use an FTP client with a nice graphical interface. In order to keep this article useful for all users, it's important to recognize that SFTP can be automated and scripted to perform file transfers while you sleep. This is often hard to do with other applications and sometimes not possible if you are automating processes on remote computers where the command line is all you've got. Indeed, automating processes is the domain of all lazy and productive computer users.

Fortunately, SSH and SFTP are beginning to make it into more and more graphical FTP client programs on Mac OS X due to Jaguar's UNIX under-the-hood. This is fortunate for the obvious reason of security as well as the fact that some ISPs are turning off regular, insecure FTP leaving you out in the cold if you are not using SSH and SFTP.

I typically use Interarchy by Stairways Software as my graphical SFTP client because Interarchy supports the SSH/SFTP included with Jaguar, making my configuration of SSH at the command line integrated and consistent with the graphical client. Interarchy goes one step further by storing the SSH/SFTP information in the keychain so that it's readily accessible and transparent to transfer files securely . I do not even know that SFTP is happening; this is the way to do security.

In addition, Interarchy integrates with BBEdit which I find indispensable despite some of the groovy (albeit slow) features of Dreamweaver. The other classic Mac FTP client is Fetch which is now out of Dartmouth's hands and in the hands of Fetch Softworks. An SFTP supported version is on the drawing board. I will leave it up to you to investigate how well your favorite FTP application supports SSH. If it does not, I would suggest a nice but firm letter to the developers asking them to get up to speed. Be sure to check that the client you choose shreds the command and the data session. If the product uses SSH bundled with Jaguar you're golden.

The Stealth Meter is now at level 5. Okay, on to our other achilles heel: email.

Encrypting Incoming Email

As with file transfers, we want to encrypt the email login session as well as the content. There are several complementary options for doing this. Some ISPs support SSL or Secure Sockets Layer email access. SSL email uses the same approach as SSL web serving. The email client has a unique SSL certificate hidden inside and the email server has an authorized certificate registered by a third-party. This is an acceptable form of email security that shreds your password and your message. However, not all email clients support SSL email, while SSH does not depend on email client support.

When securing your email, one question to ask is, "What happens to my email message after I securely send it?" Well, from your ISP it gets sent "in the clear" to the recipient's email server which may or may not be implementing the same security. In addition, the recipient may login "in the clear" and retrieve your message. So, you are only protected on one leg of the journey, which is to say not at all. This is similar to the reprehensible process of securely collecting a credit card online for a purchase and then emailing it in the clear to the order processing department. Sure, the little lock on your browser was shut, but the back-office process is wide open.

Shredding the email message for the complete trip to the recipient requires a file-based security mechanism like Pretty Good Privacy (PGP). PGP encrypts the email message as if it were a file before it leaves your computer. Thus, as the message goes from your computer to your ISP to the recipient's ISP to the recipient, it is encrypted the whole way. Using PGP for encrypting email messages is the topic of an upcoming article. PGP will not encrypt the username and password; thus, SSH (and SSL) are complementary to PGP.

Using SSH to encrypt the retrieval of your email requires a process called port-forwarding or tunneling. Worry not, it is not that hard if you have made it this far in the examples above. Basically, we want to take the information being sent through the port (a hole on the back of your computer) and send it to a different hole. This new hole is a special hole that has a shredder attached to it that shreds all information before it enters the hole. Another way of looking at it is that we create a private tunnel through which our information travels, but no one can look in the tunnel. Can you see a car in the chunnel (the tunnel under the English channel) from outerspace? No! Same deal with an encryption tunnel. This is what was happening in the second tcpflow example above.

Recall, we saw email retrieval information traveling through the encrypted tunnel of port 22 and not 110. So, what we do is tell our computer to send POP incoming email commands to port 22 instead of the default port 110. To do this there are two setup steps: tell our email client to send POP commands to an unused local port on your computer (as opposed to port 110 on the remote email server) and tell SSH to pick up or intercept the information on this new local port and forward it through our encryption tunnel (on port 22) to port 110 on the remote computer. Voila, a tunnel. Just a little bit of traffic routing. Okay, let's do it.

Step 1:

The following figure shows the POP incoming mail setup for Microsoft Entourage (this process is similar for most email client programs). In Microsoft Entourage, this configuration is found under the "Tools->Accounts->Mail" option.

Screen shot.
Entourage email tunneling.

Instead of putting "pop.myisp.com" in the "POP Server" field under the "Receiving Mail" section we put "localhost" or "127.0.0.1". Both of these latter values are the default internally referenced name and IP number of your computer. This tells Entourage to send the POP email commands to port 110 on the local computer (as opposed to the remote computer). If we stopped here the process would not work because our computer is not an email server. While on this screen click the button "Click here for advanced receiving options". We want to check the box for "Override default POP port" and enter a port number greater than 1024 (ports 1-1024 are reserved) and less than 65535. Let's use 2003 for this example as this is the current year. Figure 2 below is a screen capture of this advanced option.

Screen shot.
Entourage email tunneling.

Now our email client will send POP information to the local computer at port 2003. Our next step is to tell SSH to intercept this information.

Step 2:

Now we need to tell SSH to grab the information on the local port 2003, send it through the shredder on port 22, and then send it to port 110 at POP incoming mail server at our ISP. To tell SSH all this we need to create a configuration file. Recall that when we first used SSH to login to a remote server it created a file called known-hosts in the .ssh directory within our home directory (e.g., ~/.ssh/known-hosts). The configuration file we want to create goes in this directory and is called config by default. Because we want to tell SSH several things and make life easier on ourselves, it makes sense to put it in a file instead of trying to remember the growing list of command line options. Using your favorite text editor, create a config file in the ~/.ssh/ directory and add the following lines but use the domain name (i.e., myisp.com) and username (i.e., chris) specific to your account:

Host  incoming_mail 	#define a nickname or alias
                                #for use with command line '
                                #ssh incoming_mail'
Port 22                         #use the SSH default port 22
User chris                      #username for email account
HostName myisp.com              #Hostname mapped to nickname above. 
LocalForward 2003 localhost:110 #Grab information on local port 2003
KeepAlive yes                   #keep the session alive even while idle

The comments on the right (after the '#') briefly describe what each line is for. Basically, this sets up an alias or nickname called incoming_mail. If we connect with this alias (shown below) we tell SSH to watch for traffic on local port 2003. Once this is done we can transparently retrieve email securely all day long as long as our Internet connection remains alive. If the connection goes down (which my DSL line seems to do once per day) your SSH session will end and will require restarting to retrieve email.

We can start the SSH tunneling session by referring to the nickname we created in the config file with the following command,

[tibook:~] chris% ssh incoming_mail
chris@myisp.com's password:
Last login: Tue Apr 15 14:18:16 2003 from your.ip.number.here
FreeBSD 4.4-RELEASE (VKERN) #9: Thu Jan  2 10:23:51 MST 2003

chris%

The above output is from connecting to a FreeBSD server at a national ISP. The above has also been tested with Red Hat Linux 6.2 at a major managed hosting company. If you have been successful thus far it is unlikely that you will run into trouble here. If you do encounter a problem, try running the above command with ssh -v to see where the problem arose, discuss your problem with technical support at your ISP, and experiment with the configurations, making small incremental changes each time.

Personal Security Resolution

It took me quite a while from the time I recognized SSH as something I had to do to the time I actually implemented it. There is a lot of inertia to doing this sort of thing. That's just human nature, so don't be too hard on yourself for not doing it right away. Go get your exercise so you can have a clear head and make good on your New Year's resolution, then do it. Once you do it, make it a habit and live a healthy, fit and secure life. I hope that this article has made implementing personal security (almost) as easy as buying a paper shredder for your office.

Where to go from here?

If this is not enough for you then experiment with the commands. Create other client configurations, setup another Mac as an SSH server, or script SSH with Perl or AppleScript to startup the tunnel when your email client starts up. There are many possibilities and four more Stealth Meter levels to go. If you create a good script or have an idea, please join the TalkBack below. I'll do my best to respond. More importantly, there are many people out there with a wealth of experience and knowledge to draw from. We will all learn something from your questions, ideas and comments.

Summary

In this article we have used the OpenSSH program included with Jaguar to secure our local-to-remote working environment by encrypting remote command line sessions, remote file transfers and email retrieval. While this is not the end of the story we are certainly more secure than before. The next big step (look for the next article) is to use pass-phrase authentication integrated with an ssh-agent (a keychain-like piece of software) and a scripting language like Perl or AppleScript to automate and ease our security process even further.

Books

SSH, The Secure Shell: The Definitive Guide by Daniel J. Barrett and Richard Silverman

PGP: Pretty Good Privacy By Simson Garfinkel

Practical Unix & Internet Security, 3rd Edition By Simson Garfinkel, Gene Spafford, Alan Schwartz

Web Security, Privacy & Commerce, 2nd Edition By Simson Garfinkel with Gene Spafford

Web Resources: SSH

Excerpt from: SSH, The Secure Shell: The Definitive Guide by Daniel J. Barrett and Richard Silverman

Secure Mail Reading on Mac OS X by Jason McIntosh

SSH on Mac OS X for Worry-Free Wireless by Derrick Story and Rob Flickenger

VersionTracker.com--Search on "ssh" and "sftp" to get the latest info on Macintosh SSH/SFTP applications.

Web Resources: PGP and GnuPG

Mac OS X GnuPG (Public License version of Pretty Good Privacy)

PGP Corporation

PGP For Apple Mail

Chris Cochella currently works as a Internet Programmer and Information Architect for StreamCapture, LLC an Internet Applications and Web Services development company.

Return to the Mac DevCenter.