TTSSH: An SSH Extension to Teraterm

Version 1.5

By Robert O'Callahan (roc+tt@cs.cmu.edu)

Installation Instructions

Installation instructions are on the main TTSSH page.

Logging in and Authenticating

When TTSSH is installed and activated, the New Connection dialog box will show three buttons for the "service type": Telnet, SSH and Other. Select SSH.

Once an SSH connection is established, a dialog box will pop up asking for authentication information. This is where you identify yourself to the server. Enter your username, and select one of the authentication methods:

Password only: The password you type in the 'passphrase' box is sent directly to the server. (It is sent over a secure channel, so no-one will be able to read it simply by listening on the network.)
RSA: Select an file containing your RSA private key. You can select a file by clicking on the button or by typing its name directly into the box provided. This file must be generated by ssh-keygen, which is not supplied with TTSSH (but almost certainly can be run on whatever server machine you're connecting to). If this file is protected with a passphrase (definitely recommended!) then you should type the passphrase in the 'passphrase' box.
rhosts and rhosts with RSA: Enter the local user name that the remote side is expecting. If you wish to prove the identity of the local machine to the server using an RSA key, select the private key file as with plain RSA authentication. The passphrase from the 'passphrase' box will be used to access the key.
As of TTSSH version 1.5, to use rhosts with or without RSA, you need to set it as the default authentication option before starting the session. This is so that TTSSH can allocate the right port (a privileged port less than 1024). This is not done by default because it creates problems for some people using firewalls.
TIS challenge/response: Select TIS. You cannot specify a password. The server will send a challenge message and let you enter a response.

If the server accepts your authentication, your shell session will start. The Teraterm icon changes to a screen with a key under it to let you know when you have a secure connection. If the server rejects you, then you can try again to authenticate some other way (perhaps by sending a different password). Note that you can only specify your user name the first time, and after that it can't be changed --- this is a limitation of the SSH protocol.

You can use the SSH Authentication command on the Setup menu to choose default settings for the authentication dialog. However, you cannot enter a default password; that would be quite insecure and we don't want people to create security problems accidentally.

Host Key Management

To protect you from hostile machines pretending to be your server, TTSSH checks the server's "host key" to see if it is correct. To do this, it maintains an "ssh_known_hosts" file containing the host keys of all machines it knows about.

By default, it uses the file "ssh_known_hosts" in the Teraterm directory. Therefore if you have an ssh_known_hosts file that you want to use, copy it into your Teraterm directory and it will be used automatically.

When TTSSH contacts a server that is not mentioned in the known-hosts file, it will display a warning message. You can choose to ignore the warning and continue, or disconnect. If you continue you must be aware that TTSSH was not able to verify the identity of the server machine. If you continue, you can also specify that the key should be saved in the known-hosts file. This will prevent the warning from being displayed again for this server.

When TTSSH contacts a server that gives it a different key to the one mentioned in the known-hosts file, it will display a similar warning message. However, you should be aware that this situation is more serious from a security point of view; either the server's key has changed for a legitimate reason, or some machine is attempting to impersonate the server. Proceed with extreme caution.

In the TTSSH Setup dialog box, accessible from the Setup menu, you can choose which known-hosts file(s) to use. You can specify one file that will be used as the "read-write" file; this file is consulted to check host keys, and if you request to have a host key added, it is added to this file. You can specify additional multiple read-only files that are consulted to check host keys but are never added to. The names of the read-only files must be separated by ';'s. If you leave the read-write file box blank, then host keys cannot be added --- this might be a good idea in some environments.

Command-line Parameters

You can give the command-line option "/ssh" (or "-ssh") to cause SSH to be enabled automatically. This is particularly useful in shortcuts. For example, "ttssh pink-floyd:22 /ssh" starts an SSH connection to pink-floyd. Don't forget to explicitly specify port 22.

You can give the command-line option "/ssh-v" (or "-ssh-v") to make TTSSH dump a log file to TTSSH.LOG. This can help to find problems.

Port Forwarding

Connection forwarding is available from the command line and through the "SSH Forwrding" command on the Setup menu.

In "Setup/SSH Forwarding", you can configure which forwardings will be performed. There are really three kinds of forwardings:

You can request that connections to certain ports on the local machine be forwarded across the secure channel to some port on a remote machine. For example, you could request that the local "pop3" port be forwarded to the "pop3" port on some remote machine "mailserver". Then you could select "localhost" as your mail server and use your email program as normal. When the email program tries to fetch mail, it will contact the local machine, and its connection will be redirected to the remote "mailserver". The redirected connection will pass over the secure SSH connection between your local machine and the SSH server you logged into. Note that if the final destination of the forwarding (in this case, "mailserver") is not the same machine as the SSH server, the last step of the redirected connection (from the SSH server to the mailserver) will not be secured. Furthermore, "mailserver" will think that the connection is coming directly from the SSH server.
You can request that connections to certain ports on the SSH server be forwarded across the secure channel to some port on a local machine. For example, you could request that the remote port "12345" be forwarded to the "ftp" port on some local machine "fileserver". Then you could connect to the SSH server on port 12345 with an FTP client, and it would be redirected to access the "ftp" port on "fileserver". As in the previous case, the last leg of the connection, from the local SSH client (TTSSH) to "fileserver", will not be secured, and "fileserver" will think that the connection is coming directly from the machine running TTSSH.
You can request that X sessions on the remote machine be forwarded to your local X screen. This is very simple and basically just works. Configure your local X server to use "xhost" authentication and accept only connections from "localhost". Then, when X forwarding is enabled, the connections will be redirected and appear to come from the local machine, and the X server will therefore allow them. Users with advanced needs should note that, if the DISPLAY environment variable is set, then TTSSH will try to forward the X session to the specified X screen (over an insecure channel). Also, if you need to use xauth-style authentication data, you can supply it to TTSSH by setting the environment variable TTSSH_XAUTH_PROTOCOL_NAME to the name of the protocol and the environment variable TTSSH_XAUTH_PROTOCOL_DATA to the protocol-specific data (given as a string of hex digits). I should also point out that TTSSH does "xauth spoofing", so that your authentication data (if any) is not revealed to the SSH server; TTSSH generates and checks for its own xauth cookie for each SSH session.

If you want to use the command line, the command-line options are similar to the Unix "ssh" forwarding options. Instead of "-L port:remotehost:remoteport" use "/ssh-Llocalport:remotehost:remoteport" (no space). Instead of "-R remoteport:localhost:localport" use "/ssh-Rremoteport:localhost:localport" (no space). You can specify multiple ports for forwarding by giving multiple options. You can also use the option "/ssh-X" to request X11 forwarding from the remote server to your local X server.

Security of forwarded connections: Connections to forwarded ports on the local host (i.e. the Windows machine) are rejected unless the connection comes from an IP number that is listed as an IP number of the local host. Therefore a blind spoofing attack is possible, but I don't see how to remove this possibility without disabling forwarding altogether. Connections to forwarded ports on the remote host are not checked by the client; I assume that the server controls access to them. Therefore, only use port forwarding, in particular server-to-client forwarding, if you know what you are doing.

In version 1.5, I introduced an option to allow anyone to connect to forwarded ports. This is VERY STUPID. If you use it you are quite likely to create a gaping wide security hole. It is only accessible by setting the variable "LocalForwardingIdentityCheck" to 0 in the .INI file.

Other Tricks

For machines that you log into frequently, it's often convenient to create a shortcut that you can use to start a session --- e.g.


ttssh pink-floyd:22 /ssh

as mentioned above. Also, you can setup Teraterm and TTSSH differently for each machine by saving settings into different .INI files (using the Save Settings command on the Setup menu), and then using the /f option to load the right settings file:


ttssh pink-floyd:22 /ssh /f=pink-floyd.ini

You can also tell TTSSH to try logging in with your default authentication settings, as follows:


ttssh pink-floyd:22 /ssh /f=pink-floyd.ini /ssh-autologin

This has basically the same effect as automatically pressing "OK" when the Authentication dialog box appears. Note that, to avoid security problems, TTSSH will never store a default password/passphrase for you, so for autologin to work, you will have to set things up so that you don't need a password. This basically means that you need to use RSA authentication with a keyfile that has no passphrase. This is dangerous and I'm not going to explain how to do it; this is for advanced users only.

You can bypass TTSSH.EXE and enable the SSH extension whenever you run Teraterm. To do this, make sure that the environment variable TERATERM_EXTENSIONS is set to 1. You might as well make this change in your user profile, as it will speed up the startup a little bit. To set the environment variable in Windows NT, use the System control panel. In Windows 95, edit AUTOEXEC.BAT and add the line

set TERATERM_EXTENSIONS=1

The About TTSSH dialog box shows you various bits of information about the status of the connection.

Robert O'Callahan