Secure Computing: Secure Remote Login
Overview
From a security perspective, the Internet is a hostile environment. In the absence of special precautions, it is prudent to expect that data transmissions can be monitored and possibly altered by third parties. Because Stanford's academic mission depends upon free communication, the campus network is largely open and should be considered as dangerous as the Internet.
The most important piece of information to protect when remotely logging in is your SUNet password. You should never type it unless you are certain it will be transmitted securely. Traditional "telnet" applications are completely insecure in this respect - any password you type could be read by anyone along the path from you to the destination system.
In order to safely communicate with Stanford's Unix systems across the campus or across the Internet we recommend using version 2 of the SSH protocol, which provides resistance to both eavesdropping and active attack.
Client software
SSHv2 clients are available for a variety of platforms.
For Windows, Stanford has a volume license for SecureCRT.
OpenSSH is available for most flavors of Unix and comes pre installed in many of them, including Stanford's SULinux.
MacOS X comes with OpenSSH pre installed. You can run ssh from the command prompt in the Terminal application. A free SSHv2 client for all MacOS versions since 7.5.1 is MacSSH.
We recommend avoiding the free NiftyTelnet client because of its dependence on SSH protocol 1 (see caveat below).
Other software
The Essential Stanford Software collection includes other remote login clients such as Samson and MacSamson. These clients encrypt your password but do not necessarily protect the rest of the data in your login session. Samson clients are only recommended for people who need to connect with the Forsythe mainframe.
A popular free SSH client for Windows is Putty. If you are using the latest version of Putty configured for protocol 2, your communications are as safe as with SecureCRT.
Caveats
The original SSH protocol 1 has a number of serious flaws which could lead to a connection being intercepted. All up-to-date implementations of the SSH server support protocol 2, so it would be wise to avoid the use of protocol 1 altogether. Unfortunately, the difference between the two protocols is not visible to the user in normal operation. To be certain, follow the instructions for configuring clients for protocol 2.
The security of the SSH protocol ultimately depends upon trusting the validity of both the client's and the server's credentials. It is therefore vitally important for the user to verify that the server they are trying to contact has a public key that is correct and trusted. The Leland Systems Group provides a list of host keys for the public cluster machines in section 3 of their Installing SSH Kits page.