Using SSH

This document explains how to use SSH to make secure connections from outside the CS department (for example, from home or other sites on campus).

Secure Connections With SSH

Using SSH for secure connections to CSL Unix workstations is similar to using telnet for remote access:

On Unix systems: ssh <remote-hostname>

On Windows

• From Home: Use an ssh client. We recommend PuTTY as a free ssh client for windows.

• From CSL Windows XP workstations: SSH Secure shell is available from the Start menu under SSH, in addition to SecureCRT. This is our recommended ssh client on Windows XP, as it provides a GUI file transfer mode that supports drag and drop file transfers.

Secure Application Connections Using SSH

This answer is from the SecureCRT documentation, modified for the specific case of the Computer Sciences Department. It applies to all versions of SSH.

Port forwarding allows you to secure application-specific TCP/IP traffic using SSH. This means that you can encrypt application data using protocols such as FTP and POP3. For example, if you read your e-mail using POP, you could encrypt the communication between your home computer runningg the email client and the CS Department's POP server. SSH also supports X11 fowarding, which allows X Windows traffic between the X server and X client to be encrypted.

Port forwarding works by forwarding data from a local network port to the remote host and port. For example, to secure FTP traffic through your ftp client, set up port forwarding with the following configuration:

• local port = 21
• remote hostname = < remote >.cs.wisc.edu
• remote port = 21

< remote >.cs.wisc.edu is the hostname of the remote ftp server where you have an account.

Users with accounts on the CS Windows XP Instructional workstations can use route66.cs.wisc.edu for FTP access.

Note: If your local computer is already running an FTP server, you can not use port 21 for the local port. In that case, pick an unused port number above 49152.

Hostname and port configuration needs to be done in both SSH and the client application (e.g., FTP). After connecting with this session, FTP traffic is encrypted to the SSH server as long as the SSH connection to the remote computer is running. To connect using FTP, however, you will need to FTP in PASV mode to your computer on the local port specified above. This can be done in the following manner (using the default port number 21):

• with a web browser using the URL:

  ftp://<username>@localhost:21/

• with an FTP client using localhost instead of the remote hostname

Note: In order you use port forwarding you need to be able to login (to a shell account) to the remote FTP server. For this reason you can not use port forwarding to secure FTP sessions to anonymous FTP sites on which you do not have a personal login.

Using SSH on Unix Computers

Getting and Installing SSH for Unix Systems

SSH is already installed on all CSL Unix workstations. If you need to install SSH on another Unix system, a free Unix implementation of SSH is available for non-commercial use from: ftp://mirror.cs.wisc.edu/pub/mirrors/OpenBSD/OpenSSH/portable/. Get the lastest version.

For more information on using the Unix SSH package, please see the manual pages included in the package.

Setting Up Port Forwarding With SSH on Unix

To set up port forwarding, follow these steps:

1. Start an SSH session, specifying the local and remote ports: ssh -L <local-port>:localhost:<remote-port> <remote-host>
   • <local-port> should be either the standard port number (if not otherwise in use) or an unused port number above 49152.
   • <remote-port> should be the standard port number
   • <remote-host> should be the name of the remote computer
   • In order to use FTp, it is necessary to specify <remote-host> instead of localhost
2. Start the client application, using localhost and <local-port> as your connection options.

See Also:

• Security Considerations with SSH

Using SSH on Apple Macintosh Computers

OSX includes ssh

Using SSH on Windows 95/98/ME and Windows NT/2000/XP Computers

Getting and Installing SSH for Windows 95, 98, ME, NT, 2000 and XP Systems

The CSL recommends PuTTY^?, available from http://www.chiark.greenend.org.uk/~sgtatham/putty/

See Also:

• Security Considerations with SSH

Using SSH Through A Browser With Mindterm

As an alternative to the above options, the CSL also offers Mindterm, an SSH Java applet. Mindterm is not intended for regular use, but rather when the above options are unavailable; for example, when you are out of town and can't install a standalone SSH client. We strongly recommend using one of the other options detailed above whenever possible.

Mindterm supports use from Netscape 4.7x and Internet Explorer 5.x web browsers. It also runs with Mozilla 1.0. It may or may not work with other browsers.

The first time you use Mindterm, you will be asked to agree to the license, and a few questions about preferences. The default answers should work fine in most cases. The SSH Server/Alias prompt will default to route66.cs.wisc.edu, but can be changed to any host you have permission to log in to. Anyone with a CS account can log in to route66.

For more information on Mindterm, including extensive documentation, see the Mindterm home page.

Security Considerations With SSH

Note: The security issues in this section apply equally to any SSH program. This answer is mostly from the SecureCRT documenation, modified for the specific case of the Computer Sciences Department.

There are important network factors in understanding SSH Security, especially when using Port Forwarding.

It is important to understand that the client data is only encrypted between the computer that is running SSH (local or client computer) and the SSH server (remote computer) that SSH is connected to. Any data moving from the SSH server across the network to another server is not encrypted. Three configurations are presented below to illustrate different computer/network configurations and their effect on security. Your evaluation of the connection between Servers A and B is the critical factor in deciding whether the aggregate security meets your needs.

Configuration 1

SecureCRT (SSH) forwards the FTP connection to a remote ftp server which is a different computer than the SSH server.

• Between the Windows PC and Server A the data is encrypted.
• Between Server A and Server B the data is not encrypted.
• Since the SSH server and FTP server are on different computers your data on this connection can be viewed by others.

In Configuration 1, the connection between Servers A and B could be:

• on the Internet - an unsecure network.
• on an internal LAN - a network which may or may not deliver a satisfactory level of security.

Configuration 2

SecureCRT (SSH) forwards the FTP connection to an FTP server which is running on the same computer as the SSH server.

* Between the Windows PC and Server A the data is encrypted. * Since there is no network traffic between the SSH server and FTP server, security is increased over Configuration 1.

Configuration 3

A SecureCRT (SSH) connection is made between a Windows PC and a Unix server. A telnet session is then made from the Unix server to another site.

• Between the Windows PC and Server A the data is encrypted.
• Between Server A and Server B the data is not encrypted.
• Your data on the connection from Server A to Server B can be viewed by others.
• This is a variation on Configuration 1

Other Operating Systems

There are ssh implementations for may other architectures. http://www.ssh.com and http://www.openssh.com have source code availability. You may be able to compile either or both for your operating system. Some other helpful links are listed here, by OS:

• For MacOS X:
  • http://downwardspiral.net/macosx/fixing_ssh_in_macosx_10-0-4.php
  • http://www.stepwise.com/Articles/Workbench/2001-05-02.03.html

SSH Protocol Version 1 Disabled

Because of inherent problems in the ssh version 1 protocol, ssh1 will be disabled on all Computer Sciences Department hosts as of July 1, 2005. In order to maintain connectivity to remote sites that support only ssh1, CS ssh clients will continue to support ssh1 after that date. Please see the appropriate section in this document (based on your client operating system) if you need to upgrade your ssh client to support the ssh version 2 protocol (ssh2).

Technical discussions of the specific problems in ssh1 can be found at the following sites:

• http://www.corest.com/common/showdoc.php?idx=131&idxseccion=10
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-1085
• http://www.kb.cert.org/vuls/id/13877
• http://www.openssh.com/security.html