slac3.gif (1664 bytes)Telnet and r-commands Blocked

July 7, 1999, last updated September 8, 1999

Passwords that transit local networks or the Internet as unencrypted text present a major security exposure. Telnet, rlogin, ftp and many e-mail applications still use clear-text passwords. SLAC blocks applications using clear-text passwords as soon as alternatives are available.

SLAC blocked telnet and r-commands (rlogin, rsh, rexec, and rcp) access to SLAC on September 1, 1999. Incoming telnet and r-commands were blocked in the external router. Telnet and r-command daemons were removed from centrally maintained systems. Secure Shell (SSH) is the supported alternative software (see the Unix SSH web page and more tips on replacing the r-commands is available on a BaBar page). If this  severely impacts your work, contact Bob Cowles, SLAC Computer Security Officer.

Use of ftp with clear-text passwords will be stopped as soon as an adequate, secure alternative is available (perhaps early 2000). Data still may be sent or received using anonymous ftp (using a restricted set of servers); in fact, SLAC Computer Services (SCS) is setting up anonymous ftp servers for physics experiments where data can be freely distributed without password authentication.

Upgrades to the SLAC POP and IMAP email services to support secure access will take place this fall. Assuming a successful test, we hope to terminate the use of clear-text email passwords around the end of the year. Although a preferred email client has not been selected, leading contenders support SSL encryption, e.g. Netscape Messenger or Microsoft Outlook. Pine and Eudora email clients are problematic and we are still trying to find a solution allowing their continued operation. Users will be encouraged to use IMAP rather than POP – IMAP’s central storage of email is easier to manage and is more convenient for many users who want email access from multiple machines (e.g. home and work) and multiple platforms.

 

Contents:
Finding SSH client software
General SSH questions (and answers)
Use of SSH with X-windows and X-Win32
SSH Version information
Access to SLAC when at conferences or traveling

 

Finding SSH client software

If you need a Unix or Linux client, look for the references on the SLAC web page referenced above. SLAC users on-site can find a distribution tailored for the SLAC environment in the AFS file system at /afs/slac/package/ssh (due to U. S. export restrictions on encryption technology, SLAC cannot make SSH available for download from our web site.).

The web page also directs you to a page where you can purchase a license for F-Secure, a commercial SSH product for Macintosh, Windows 9X and NT platforms. Thirty-day evaluation copies can be downloaded from the web at http://www.datafellows.com/gallery (select the appropriate SSH product from the "Cryptography Products" section). Freeware versions of SSH extensions can be used in conjunction with Tera Term Pro downloaded from http://hp.vector.co.jp/authors/VA002416/teraterm.html (you must download and install both Tera Term and the Tera Term SSH extension) or from standard  NT systems connected to the SLAC network from the X:\Applications\Supported\TeraTerm directory, run Install_TeraTermProSSH.bat (this must be run by someone with Administrator privileges). As of this writing, the Tera Term freeware version has satisfied the most needs of users on the Windows platforms. From Bob Jacobson, BaBar Collaborator: "There's also a free SSH for the Macintosh, called NiftyTelnet 1.1 SSH, see  http://www.lysator.liu.se/~jonasw/freeware/niftyssh/    It doesn't do X11 forwarding, but can do secure copy (unlike Data Fellows version, which I also have)."

There are also several Java-based implementations that may run across some number of platforms – perform a web search with the keywords "java" and "ssh".

Note that some of these programs claim to be illegal to use in the United States without paying a license fee for the RSA encryption algorithms. The U. S. government has the right to use RSA algorithms without paying a royalty; also: "In the U.S., a license is needed to ‘make, use or sell’ RSA. However, RSA Data Security usually allows free non-commercial use of RSA, with written permission, for academic or university research purposes." [emphasis added]  Since SLAC is a U. S. government funded facility, we are assuming the right to run software containing the RSA algorithms (the patent expires in August, 2000).

 

General SSH questions (and answers)

Q. Often when I connect from Tera Term to vesta, flora or morgan, I get a message about a possible attack.  Should I be worried? How do I get the message to stop coming out?

A. The machines you mention are actually families of machines so you don't always get assigned to the same one -- this can make the host validation code within ssh very confused and think someone else is spoofing the machine you're connecting to.   This problem doesn't appear if your "known hosts" file is created at installation using the standard script in the Pub drive (for standard configurations it is X:\Applications\Supported\TeraTerm).   If you did not use that script, you can create the known hosts file by running the 'update.bat' command from the TeraTerm installation directory.  If you installed Tera Term in a non-standard location, you may have to edit the script so it creates the known hosts file in the proper directory.

Q. We imported a few procedures (batch-like) which use some of the r-commands (rsh, rcp) in combination with a .rhosts file to avoid entering a password.   Does the procedure outlined on the BaBar web page using .rhosts still work?

A. Yes, both .rhosts and .shosts files continue to work, but only with ssh; be sure to read the information about the "known_hosts" file to increase the security of this type of authentication.

Q. Encrypting and decrypting the data is very CPU intensive; what will be the impact on response time?

A. Interactive sessions like telnet and rlogin normally transmit relatively small amounts of data and reasonably powered machines should see no impact from the additional work. With underpowered machines running a Java-version of the code, there may be a noticeable impact. Because ssh has to negotiate encryption methods and keys, the session initiation may be noticeably slower -- it is particularly noticeable compared with rsh.

 

Use of SSH with X-windows and X-Win32

Q. I use the Xwin32 program to connect from Windows NT to Unix and it only gives options of rsh and rexec for making the initial connection.  How do I use Xwin32 if the r-commands are blocked?

A. Len Moss has written a FAQ on using Xwin32 with ssh.

Q. I use Xwin32 application from my NT machine to gain access to xterm windows on Unix machines like flora or vesta. In the past, I could configure the xterm command from Xwin32 and then each session would automatically startup when I logged in. Now that rexec and rsh are going away, how can I configure the xdmcp window using Xwin32? When I select xdmcp there is no place to input the window parameters that I want (i.e. -sb -geometry 80x24 -name <userid>, etc., etc). The only thing that's the same is auto-startup but that's not very useful if I have to reconfigure the window manually each time.

A. (Courtesy of Len Moss)  When using XDMCP you are starting a session, which may include a variety of different X applications, rather than just a single xterm window. You control the set of applications, and their parameters for each one, from the UNIX side, not from X-Win32. When your XDMCP session starts, it looks for a script named ".xsession" in your UNIX home directory; if not found, it uses a system-defined default script instead; this default script is /usr/lib/X11/xdm/default.xsession on the vestas or /usr/openwin/lib/xdm/default.xsession on the floras. You can copy the default script and modify it to launch whatever set of X applications you want. All but the last one should have an ampersand appended to put them into the background; the last one must _not_ have an ampersand, because that would permit the script to complete and when the script completes your session ends (i.e., all your X applications are closed). The default.xsession script at SLAC (set up years ago by Len Sweeney) makes the clock the last, and thus controlling, application for the session.

If all you want to do is set some window parameters, however, I suggest you do that in your .Xdefaults (or .Xresources) file rather than on the command line in a script, since then they will be used automatically whenever, and however, you start that particular X application (unless you override on the command line). For example, instead of issuing the command, xterm -sb -geometry 80x24 & you could put:

XTerm*VT100*geometry: 80x24
XTerm*VT100*scrollBar: True

in your .Xdefaults file, and then just say "xterm &". See the xterm man page for the X resource equivalents for other command line options.

Q. What about XDM sessions?  They transmit clear text passwords so will they also be blocked?

A. XDM sessions are already blocked at the SLAC firewall.  The XDM servers will still be available for use within the SLAC network.

Q. Can I use ssh to replace mxconns for tunneling X-sessions into SLAC?

A. Certainly, in fact it is very easy to get ssh to provide a secure, encrypted "tunnel" for X-sessions. See the ssh web page at SLAC for instructions. If a system on the other end of the connection is compromised, the secure link won’t help – ssh helps but is not a guarantee.

Q. May I telnet or rlogin to my system at my home site from SLAC?

A. Yes, but this is not recommended since it puts your home system in jeopardy along with any other system with the same password or which is accessible through ".rhosts" files. If you use the Unix ‘ssh’ command and your home system is not running ssh, the command will issue warnings and eventually timeout and fail with connection refused messages. You should do the right thing and install the ssh daemon on your home system.

Q. If I try to use telnet to a SLAC system, what error will I see?

A. From inside the SLAC firewall connecting to a centrally maintained machine, you will receive a message to the effect "Connection refused". From outside the SLAC firewall and trying to access any SLAC machine, the message may vary by client but it will be to the effect "Host not responding" after some significant delay.

Q. The local system admins at my site don't want to install ssh everywhere.  It is OK if I just telnet to the system where they have ssh and then use ssh from there?

A. That would work, but it would defeat what we are trying to accomplish with eliminating clear-text passwords.  You will still be sending unencrypted data (and passwords) between your local machine and the one running ssh.  Problems with passwords being "sniffed" occur on the local networks at the endpoints and that is precisely where you are exposing your password with the telnet session.

 

SSH Version information

Q. Which version of SSH should I use, version 1 or 2?

A. We will be using SSH servers implementing version 1 of the protocol, so be sure to get a version 1 protocol client.  Please note that the current release of Tera Term is 2.x, but the extension still implements Version 1 of the ssh protocol.

Q. I love using the latest stuff and have installed ssh version 2 client on my system – will I be able use that software to access SLAC?

A. No, we hope to have ssh version 2 servers available on the centrally maintained Unix systems later in 1999.

 

Access to SLAC when at conferences or traveling

Q.  I only use telnet to our Unix machines when I am away from SLAC. What should I do when I am at a conference and all the computers in the temporary computer room for the conference use telnet? The same question applies to when I go to work at another laboratory for extended periods and they also do not have ssh.

A. We make available the free ssh client on all Unix machines, and are seeing widespread use of a free ssh client called Tera Term, which can currently be found on SLAC NT fileserver in the X:\Applications\Supported\TeraTerm directory. For your travel, contact the SCS Help Desk for a copy of Tera Term on a floppy disk that you could then use from any Windows computer.  Most other labs are also adopting ssh as a standard, so I think you should expect to find it on the computers at other labs. Many conferences, such as Lepton-Photon 99 hosted by SLAC, are now equiping all their public work machines with ssh clients. If you find a conference that is not doing so, tell them about the security risk that they are creating for all their attendees. Some of our most serious security problems came immediately after conferences where hackers had infiltrated the workroom machines and captured passwords.

Q. I am a novice on Unix, but I really need telnet or an equivalent to read my mail (PINE) when I am away from SLAC. Can you give me some extra help on this?

A. As as replacement for telnet, SLAC is recommending use of the ssh program. This is a replacement for both the r-commands and telnet that encrypts the data. For unix at SLAC, typing ssh will get your an encrypted session. It is just like telnet, but the data (and your password)  never goes across the wires unencrypted. While ssh is being installed at many sites, it is a third party application, and it is not part of the operating system. So, it is possible that it is not installed where you might travel. You did not say what systems you use when you are away from SLAC; because of that, I am going to suggest a couple of different options.

If you take a portable computer with you, it should have a copy of the ssh program installed on it before you leave SLAC. Your system admin should be able to install it for you. Ssh is available at SLAC on the public applications folder for desktop systems. For PC's and Mac's, there are two versions of ssh available, a commercial version (which costs about $50), and a freeware version. If you commonly use a sites "public lab", you should ask if they have ssh installed somewhere. But just in case they do not, we recommend that you carry a floppy with you that contains a copy of ssh. Of course that floppy must be made before you leave SLAC. If you know you will be visiting a site, and you know they have a "public lab" or "computer cluster", you should try to ssh to that location from SLAC before you leave. If the ssh connection is sucessful, it means they have ssh installed (and you should have not problem sshing out). Lastly, we can point you to the source for ssh, (see references above) from which  a unix sysadm can download his or her own copy.

One problem that you should be aware of (and is why we can't make this a lot easier) is that SLAC cannot provide a downloadable version of ssh from wherever you might be. Because ssh uses strong encryption, it is categorized as munitions by the United States federal government (and is export controlled).


Owner: Bob Cowles