Starting and Terminating Telnet_SSH

You can start Telnet_SSH by double-clicking on the Telnet_SSH icon in the WinaXe Plus Programs' folder:

The Telnet Connect Host dialog box will appear on your display:

A session is a connection to a remote machine made with a number of connection-specific settings assigned to it. These settings are saved in an ini-file and profiles and allow you to have different preferences for different hosts (using different ini-files and profiles).

All Telnet session settings are stored in the [TELNET] section of the xwp.ini file.

All SSH1 session settings are stored in the [tSSHPro] section of the tsshpro.ini file.

All SSH2 session settings are stored in the [tSSH2Pro] section of the tsshpro.ini file.

Also you can specify some initial settings for the session with the Details button (that is described in section Details of a Session).

The first thing you should do to initiate a session is to establish a connection to a remote machine. In the dialog, you must specify the protocol you will be using, the hostname or IP address, and the port number of the service.

Pressing OK will store current settings (for the next session) and will establish a connection, using them.

You can cancel any changes you have made to the dialog box by clicking on Cancel. This will also close the dialog.

Telnet

This button specifies whether to use the standard TELNET protocol over an insecure channel to provide an interface for communications between clients and servers. In the Telnet mode, Telnet_SSH works as the Telnet client on your PC.

Note: a Telnet session is not encrypted; so it will transmit your user name, password and other sensitive or private information in an easily readable format.

SSH-1
SSH-2

These buttons specify whether to use the SSH1 (or SSH2) protocol over an insecure channel to provide secure communications between clients and servers. In the SSH1/SSH2 modes, Telnet_SSH works as the SSH1/SSH2 client on your PC.

Note: SSH is a tool for secure remote login over insecure networks. It provides an encrypted terminal session with strong authentication of both the server and client, using public-key cryptography. An SSH session provides maximum security and privacy on the Internet and local networks. It encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks.

SSH is an acronym for the Secure Shell protocol - a secure communications protocol used to encrypt network traffic between clients and servers that replaces existing TCP/IP protocols such as TELNET, RSH and RLOGIN. SSH must be supported by both the client and the server. SSH1 is the first version of the SSH protocol and SSH2 is the second one.

Host

This field specifies a hostname or IP address (network node specification) for the remote machine you want to connect to (and which provides the Telnet or SSH1/SSH2 service).

When you click on the scroll arrow beside the Host box, a drop-down box will display host definitions located in your hosts file. To select a host, click on an appropriate definition.

Port

This field specifies the port number of the Telnet or SSH1/SSH2 service on the remote machine you want to connect to.

For the Telnet mode, the default port number of the Telnet service is decimal 23.

For the SSH1/SSH2 mode, the default port number of the SSH1/SSH2 service is decimal 22.

Starting a Telnet Session

To establish Telnet connection, specify the Telnet mode, enter the network name or IP address for the host you want to connect to, then change the default Telnet port number if required, and press OK. Telnet_SSH connects and logs into the specified hostname.

Once you have connected to the host, the host name or IP address you specified appears at the top of the Telnet window (with the terminal emulation mode), and the host login prompt appears in the window:

You must prove your identity to the remote machine using some authentication method (e.g., password authentication). Specify the login information required for your host system. You can then interact with the host by choosing commands from displayed menus, or by typing commands in the window and starting remote applications.

You can customize your Telnet session with the Settings and/or Keyboard Mapping items in the Options menu (described below).

The following sequence of commands can be used as an example of working in the Telnet session (depends on the remote shell used):

login: arsexam
$ DISPLAY=xtp2:0; export DISPLAY;
$ xterm&
$ mwm&

To capture the screen output of Telnet commands to a file, Telnet_SSH writes the log to the telnet.out file in the home directory (in case of fatal errors or due to the 'trace' command line parameter).

Starting an SSH Session

The SSH1/SSH2 protocol mode provides secure communication over an insecure channel by encrypting the data channel with a cipher algorithm. The cipher selected for the session is used to encrypt network traffic between the local PC and the remote host, thus providing data privacy. Encryption is started before authentication, and no passwords or other information is transmitted in the clear.

The ciphers provided for use with the SSH1 protocol and supported by Telnet_SSH are DES, 3DES, RC4, and Blowfish. The ciphers provided for use with the SSH2 protocol and supported by Telnet_SSH are 3DES, Blowfish, CAST128, ARCFOUR, AES128, AES192, and AES256-cbc. The DES and 3DES (triple DES) ciphers are slow. The RC4 and Blowfish ciphers are considerably faster (less CPU intensive) than 3DES. You can specify ciphers Telnet_SSH will try to use with the SSH1 protocol. Telnet_SSH will try 3DES as the first cipher (by default).

Telnet_SSH supports optional compression of all data with gzip (including forwarded X11 and TCP/IP port data), which may result in significant speedups on slow connections. You can specify the compression level from 1 to 9 (default). Level 1 gives you fastest performance (with lowest compression) and level 9 - slowest performance (with highest compression).

Note: to work in the SSH1 protocol mode, you need the SSH1 daemon, .sshd, being run on the remote machine you want to communicate with (the SSH2 daemon, .sshd2, for the SSH2 mode respectively).

To establish SSH1/SSH2 connection, specify the SSH1/SSH2 mode, enter the hostname or IP address for the host you want to connect to, then change the default SSH1/SSH2 port number if required, and press OK. Telnet_SSH connects and logs into the specified hostname.

You can customize your SSH1/SSH2 session with the Settings and/or Keyboard Mapping items in the Options menu.

See the Forwarding item of the Option menu on how to specify necessary port forwarding and X11 forwarding settings to customize your SSH1/SSH2 session.

Once you have connected to the host, the SSH Authentication window appears:

Authentication is the process of verifying that an individual truly is who he or she claims to be. You must prove your identity to the remote system, using one of the three methods of authentication that Telnet_SSH supports for connecting to SSH servers: password authentication, RSA authentication, or keyboard-interactive authentication (for the SSH2 protocol).

Password authentication transmits the user's password to the server to authenticate the connection. The transmitted password is protected from network eavesdropping due to the cipher encryption of the data channel.

Keyboard-interactive authentication is a flexible authentication method using an arbitrary sequence of requests and responses. It is not only useful for challenge/response mechanisms, but it can also be used for asking the user for a new password when the old one has expired (for example).

RSA authentication uses a public/private key pair to authenticate the connection.

The scheme is based on public-key cryptography: there are cryptosystems where encryption and decryption are done using separate keys, and it is not possible to derive the decryption key from the encryption key. RSA is one such system. The general mechanism behind RSA authentication is that each user creates a public/private key pair for authentication purposes. The SSH server knows the public key, and only the user knows the private key. The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the client SSH program tells the SSH server which key pair it would like to use for authentication. The server checks if this key is permitted, and if so, sends the user (actually the client SSH program running on behalf of the user) a "challenge", a random number, encrypted by the user's public key stored on the server. The challenge can only be decrypted using the proper private key. The user's client then authenticates the connection by successfully decrypting the challenge using the user's private key, proving that he/she knows the private key but without disclosing it to the server.

SSH server implements the RSA authentication protocol automatically. Normally the user creates his/her RSA key pair by running the ssh-keygen utility on the remote host. This stores the private key in $HOME/.ssh/identity and the public key in $HOME/.ssh/identity.pub in the user's home directory. The user should then copy (or append) the identity.pub file to $HOME/.ssh/authorized_keys in his/her home directory on the remote system.

The private key is often stored encrypted at the client machine in an identity file. The user should specify the identity file to be used for RSA authentication.

Passphrase is a password used to protect a private key from unauthorized use. The passphrase is firstly used when generating the public/private key pair by the ssh-keygen utility to encrypt the private key (i.e. the identity file at the server machine). The user must supply the passphrase before the digital signature can be generated.

RSA authentication offers a higher level of authentication security than password authentication by requiring both the private key and the passphrase that protects the private key in order to complete authentication.

In the SSH Authentication dialog, you should specify necessary settings for authentication.

User name

This field specifies the username used to log on to the remote machine.

Passphrase

If password authentication is selected (with Use plain password to log in enabled), you can enter your password in this field.

If RSA authentication is selected (with Use RSA key to log in enabled), you can enter your passphrase here.

It is recommended that a passphrase be assigned to all private keys to prevent unauthorized use, especially in environments where multiple individuals have access to the machine on which the private key files are stored. When using public key authentication, a private key with an assigned passphrase will not be available if the correct passphrase is not supplied during the authentication process.

Use plain password to log in

When enabled, this radio button specifies to use password authentication.

If password authentication is selected, you can enter your password in the Passphrase entry field. If a password is not entered here, you will be prompted to enter it during the connection process.

Use RSA key to log in

When enabled, this radio button specifies to use RSA authentication.

If RSA authentication is selected, you should enter your passphrase in the Passphrase entry field. Also you should specify a location of the identity file to be used for this process. You can enter the filename in the entry field or select it with the Private key file button.

Private key file

When you press on this button the standard Open File window will appear. You can select your identity file for RSA authentication. RSA authentication will only be attempted if the identity file exists.

In order to use your private key you must transfer the identity file created by the ssh-keygen utility on the SSH server machine to a secure location on your PC for this file such that you are the only individual with access to it.

One way to transfer the identity file from the remote machine to your PC is to use an FTP client (in ASCII mode). Another way is to copy the contents of the identity file to the clipboard using a remote text editor and then to paste the contents of the clipboard to a file you created using a local text editor (e.g., Notepad).

Also, prior to using RSA authentication, the public key must be made available to the SSH server.

Use Keyboard-Interactive Mode

When enabled, this radio button specifies to use keyboard-interactive authentication.

Disconnect

You can immediately close a communication connection with this button.

Specify the login information required for your host system. When your identity has been accepted by the SSH server, the server either executes the given command, or logs into the machine and gives you a normal shell on the remote machine. All communication with the remote command or shell will be automatically encrypted.

Example of Initiating a Telnet Session via SSH

First, make sure that:

• your PC is accessible from your remote host (e.g., by using Ping)
• your remote host is accessible from your PC
• sshd-daemon (or sshd2-daemon) is running on your remote host.

If OK, then you may initiate the Telnet session via SSH like the following steps:

1. Double-click on the Telnet_SSH icon from the WinaXe Plus Programs' folder to start Telnet_SSH (the Telnet Connect Host window should appear)
   
   
2. Choose SSH-1 (or SSH-2) in the Interface section
   
   
3. Enter the network name or IP address for the remote host you want to connect to
   
   
4. Change the default SSH port number if required
   
   
5. Click OK to establish connection with the remote host (the SSH Authentication window should appear)
   
   
6. Choose to Use plain password to log in
   
   
7. Specify the login information required for your host system: User name and Password in the Passphrase field
   
   
8. Click OK to log in to the remote host (the Telnet_SSH window should appear).

Terminating a Session

You can terminate a Telnet_SSH session by choosing the Close command on the Control Menu box, or by selecting Exit on the Telnet_SSH Commands menu.

If you select Exit while a connection to a remote system is still active, Telnet_SSH disconnects you from the remote system automatically (properly closing all applications used).

Telnet/SSH2 as SOCKS4 Proxy

Telnet/SSH2 provides the "Dynamic Forwarding" feature that allows FTP, XStartup, and XServer/LbxLoxy to access protected hosts via SSH2-connection. Really "Dynamic Forwarding" is a well-known standard SOCKS4 proxy server. This means that it can be used to access remote hosts by a "crooked" way.

A typical sample example

Suppose that:

• You work on HOST1 (say, in Australia) under MS Windows and can use Telnet/SSH2
• You have an intermediate HOST2 (say, Labtam-inc.com in USA) with the modern SSH2-daemon
• You want to access (from HOST1 using MSIE, Netscape...) the "overparticular" site (say, "http://www.sho.com/" in USA) on HOST3 accessible only from USA hosts.

You can do the following:

1. Connect from HOST1 to HOST2 via SSH2 using Telnet/SSH2.
   With command "netstat -na", check that there created the "16001" LISTEN port.
2. Tune MSIE on HOST1 so as it will use the SOCKS proxy on the local PC.
3. Run MSIE on HOST1 and try to connect to site "http://www.sho.com/" on HOST3.

Some notes

• Why only now.
  

  All described above was possible all the time, but old SSH2-daemons have a bug which we had to work around in FTP, XStartup, and XServer/LbxLoxy. We did this via additional delay after successful connection. It was our specific. We know that the bug still existed in SSH-daemon of Linux RH 7.1. Now we see that the Linux RH 9 does not have this bug.

• What is this - port 16001 (is it always 16001 ?). NO !
  

  Each Telnet/SSH2 session automatically creates one "Dynamic Forwarding" (i.e., SOCKS4) port starting at number 16001. If 16001 is busy (say, you connected to HOSTxxx via Telnet/SSH2), then the 2nd Telnet/SSH2 session will create the 16002 port number, and so on. Closing a session makes the corresponding port free.