SSH: Do You Know Where Your Password Is?

 

News on the Net

WWW Everyone

You've listened when we told you to be careful with your password, haven't you? You never write it down, you don't tell it to your friends, you don't save it in Eudora, and you don't enter it on the Web except when you use WebMail or when you're asked for it by the UIC WWW Identification Service, a.k.a. Bluestem. When you choose your passwords you don't use your spouse's name or your dog's name and you don't use a dictionary word that could be guessed.

That means your password is safe, doesn't it?

Well, not really. Each time you login to your borg, icarus, or tigger account, after you type your password and press Enter, your password is sent out over "the network." That ******* stuff you see as you type your password is just to fool anyone who's looking over your shoulder -- your actual password is sent over the network "in the clear," exactly as you typed it. That means that it could be intercepted and read by anyone else who's on the same network.

Bluestem logins and all of WebMail are safe;

they use SSL (Secure Sockets Layer), the secure Web protocol that encrypts all Web traffic to and from the server. You can tell they're secure because your browser's lock icon will be locked and because their URLs begin with https://, rather than http://. We talked about SSL and Bluestem in the March/April 1997 A3C Connection. Security and convenience is why you probably should read your email with WebMail when you're traveling.

To be completely safe when you use WebMail on a borrowed personal computer, you probably should delete the browser's "temporary Internet files" when you're done:

In Internet Explorer: Tools->Internet Options…, click Delete Files…, then click OK (don't select Delete all offline content on a borrowed machine).

In Netscape: Edit->Preferences->Advanced->Cache, then click Clear Memory Cache and Clear Disk Cache.

 

Logging into the ACCC dialin lines is also safe,

someone would have to be bugging your phone to intercept your password then. Traffic over the ACCC dialin lines to the ACCC email/UNIX servers is also reasonably secure; someone would have to have broken into one of the important ACCC machines to do any damage there. (Keeping our public machines secure is a major and continuous commitment of the ACCC.) Traffic on campus from a switched LAN to the major ACCC machines is also probably not sniffable, although that comes with less of a guarantee.

 

But if you come into UIC from outside on the Internet,

either from a commercial ISP or from another organization's network,

or if you go out to the Internet from the UIC network,

then you're no longer safe. Login to a remote host system, and there goes your password out over a public computer network, probably in the clear. Your password and connection will be vulnerable in each network that it goes through.

When last we visited the idea of privacy and security on the Internet (Pretty Good Personal Privacy, January/February/March 2000), we talked about using encryption to keep email messages and files secure. The same considerations apply to remote logins -- you have every right to expect security for your interactions when you're logged in to a remote host machine:

Authenticity: Being able to tell without a doubt what the source of the data is. Your password tells the server who you are, but that's only half of the question; the server should also assure you who it is.

Privacy: Scrambling data so it can't be used by anyone except the person that it's intended for. Privacy in remote logins means encrypting your password and, for that matter, your entire login session, so only you and the server you log into can read it.

Integrity: Assurance that the server is receiving everything you send it, nothing more, nothing less. And vice versa -- assurance that you're receiving the exact messages, output, and files the server sends you, nothing more, nothing less.

Yes, remote logins are vulnerable in all these areas. Say you're going from here to there. If the route from here to there goes though someone else's network, a bad guy on that network could eavesdrop on your transmission, looking for passwords, credit card numbers, or business secrets. Or they could use IP spoofing to redirect your communications to a fake server. Or the bad guy on a machine that's somewhere in the middle of your route from here to there could intercept your traffic and respond to you as if it was there and respond to there as if it was you. That's called a "man-in-the-middle" attack, and if the man in the middle is careful, you wouldn't even know it happened to you.

But you don't have to worry about any of that. Transparent security for logins is here -- secure remote logins with secure shell or SSH. SSH provides a secure replacement for telnet (with a secure and easy way to do X Windows; see Secure X Windows with SSH); for the UNIX "r" commands, rsh, rlogin, and rcp; and for FTP.

SSH's security is transparent because it's an application layer protocol -- you use SSH software to login to a remote host instead of using telnet. And SSH really is secure. It supplies two-way authentication, including the server authenticating itself to you. After exchanging keys, your entire login session is encrypted, including your password and everything that you send to the host server and everything it sends to you.

The best thing about SSH is that all this security stuff goes on behind the scenes. From your point of view as a user, an SSH application looks like just another version of telnet.

It's no harder to switch to an SSH secure remote login application than it is to change from one vendor's telnet to another's.

Interested? We're going to include SSH Secure Shell for Windows in the new NSKit. But you don't have to go out and get the whole kit to get SSH. You can download SSH Secure Shell for Windows from the ftp.uic.edu FTP server. (See figure 2 and its caption.) Version 2.3 is on the FTP server as I write this, but it's possible that Version 2.4 will be available by the time this article is published. The information in this article and in the ACCC Web page on SSH Secure Shell, http://www.accc.uic.edu/software/ssh/, applies to both versions.

SSH Secure Shell, the software, was written in 1995 by Tatu Ylönen, a Finish computer scientist. Both "SSH" and "secure shell" are trademarks of his company, SSH Communications Security Corp. The U of I has a site license for their products.

The SSH code, however, is freely available and is used in a number of other secure remote login applications, for a wide range of operating systems; see: http://linuxmafia.com/pub/linux/security/ssh-clients for an up-to-date list and links.

SSH the protocol (which SSH Communications would prefer that we call SECSH) has not been approved as an IETF standard yet, but they're working on it; the protocol drafts are maintained by SSH Communications: http://www.ssh.com/tech/archive/secsh.html
The SSH FAQ should answer any other questions you might have about SSH: http://www.employees.org/~satch/ssh/faq/

1. Download sshwin-2.3.0.exe from ftp://ftp.uic.edu/pub/othersoftware/ssh/
   
   
2. Double-click on the file's icon to unpack and install SSH Secure Shell. The EXE file will install the program in your C:\Program Files\SSH Communications Security directory; the NSKit will install it in your C:\Program Files\UICNSkit\SSH directory.
   
   
3. If you're going to use SSH with X Windows, turn on X11 Tunneling before you connect. (Saving the settings when you close SSH will keep them to apply to future sessions.)
   1. Open SSH (see below), then click Edit->Settings…
   2. Click Tunneling under Host Settings; click in the box next to Tunnel X11 Connections, and then click OK.
   3. Close SSH. It'll ask you whether you want to save the changes you've made; click Yes. (Saving the settings when you close SSH will keep them to apply to future sessions.)

1. Open SSH using either:
   Start->Programs->SSH Security->SSH Secure Shell
   or: Start->Programs->Network Services Kit->Secure Shell->SSH Secure Shell
   
   
2. Press Enter.
   
   
3. In the Connect to Remote Host dialog box, type the host name and your login ID in the Host Name: and User Name: fields; say, for example, tigger.cc.uic.edu and your ACCC netid. Press Enter or click Connect.
   
   
4. If this is the first time you've used SSH Secure Shell to connect to this remote host, SSH will show you the host's public key and ask you: "Do you want to save the new host key to the local database?" If you trust this is the right host, click Yes to save it. (Trust is involved, as it has to be.)
   
   
5. The Enter Password dialog box opens. Type your password in the Password: box, and press Enter or click OK.

Login with SSH to the host you want to exchange files with, then select Window->New File Transfer or click the file transfer icon, a file folder with a quarter circle of blue dots over it.

The Secure File Transfer window works like Windows Explorer for the files on the remote host, with the directory tree of your account on the left and the directories and files in current the directory on the right.

To download,

select a file to download and click the download icon (down arrow).

To upload,

open the directory you want upload a file into and click (an up arrow). Or drag and drop files, up or down, as you would in Explorer.

To change a file's UNIX access permissions,

right-click on a UNIX filename and select Properties. (SSH File transfer calls them "Attributes".)

Logoff from your UNIX account, then either select File->Exit or click the Close box in the upper right corner of the SSH Secure Shell window.

I think you'll find that SSH Secure Shell works a lot like whatever telnet you've been using, but don't stop there; it can do lots more.

The SSH Secure Shell user manual is in its online help and is on the Web at: http://www.ssh.com/products/ssh/winhelp/

Or see the ACCC document: http://www.accc.uic.edu/software/ssh/

Comments are welcome; please send them
to Judith Grobe Sachs, judygs@uic.edu