Installation instructions are on the main TTSSH page.
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:
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.
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.
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, "ttermpro pink-floyd:22 /ssh" starts an SSH connection to pink-floyd. Don't forget to explicitly specify port 22.
Connection forwarding is only available from the command line. The options are similar to the vanilla "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). Connection forwarding has not been tested enough; it is functional, but perhaps not very robust. You can specify multiple ports for forwarding by giving multiple options. (Yes, I know there should be a user interface for this. Sorry.)
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 if you know what you are doing.
Due to a bug in Teraterm, TTSSH does not read options from any alternative
configuration files specified with the Teraterm "/F" option. As a workaround,
ttssh.exe provides a command-line option: "/ssh-f=
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 (in NT, that means using the System control panel). This will speed up the startup a little bit.
The About TTSSH dialog box shows you various bits of information about the status of the connection.
In order to provide rhosts authentication for those who want it, TTSSH tries to allocate itself a "priviledged port" on the client machine. This can cause some problems, for example with firewalls that won't let any packets on such ports through the firewall. You can disable the priviledged port search by setting the environment variable TTSSH_DISABLE_RHOSTS to 1. This will stop rhosts authentication from working properly, but it will cause TTSSH to use a non-privileged port (with a number >= 1024).