Technical Notes |
|
This technical note briefly describes Secure Shell (SSH) and explains how to configure Reflection for Telnet port forwarding, by creating a telnet connection through a secure SSH tunnel.
SSH is a set of computer applications based on the IETF Internet-Draft for the Secure Shell protocol. SSH provides strong, encrypted authentication and a secure encrypted tunnel through which users can execute commands and move data. The current version of Secure Shell is ssh-2. (The ssh-1 protocol is deprecated; therefore, it is highly recommended that you use ssh-2.)
For more information about Secure Shell, see "Fortified SSH: A Cost-Effective Way to Safeguard Your Network" on the Attachmate web site at http://www.attachmate.com/WhitePapers/Literature_0954.htm.
Note: Beginning in Reflection 13.0, the SSH connection is called Secure Shell. Earlier Reflection versions called the SSH connection OpenSSH.
The Reflection Secure Shell Client is included in Reflection versions 11.0 or higher. If you use Reflection 10.x, you must have the Reflection OpenSSH Client feature of Reflection Security Components version 10.0.x to enable Reflection OpenSSH support.
To tunnel a Telnet session through an SSH connection, you must establish the SSH connection, then configure Reflection to redirect Telnet through the SSH tunnel. To do this, you must create two Reflection settings files, one to configure and start SSH, and one to configure and start the Telnet session.
Figure 1 - Telnet Port ForwardingNote: Both connections must remain open for port forwarding to be available. The SSH connection window may be minimized. If the user tries to log off or close the SSH connection while the Telnet session is being tunneled, they will be unable to do so. The SSH session will remain open until the Telnet session is terminated.
Follow the steps below to create a settings file that opens a Secure Shell connection to your secure host.
For earlier Reflection versions: Click Port Forwarding. On the Local tab, click Add.
Important: Localhost is used for the remote machine if the Telnet server you are connecting to is running on the same server where the SSH daemon resides, which is often the case.
If the SSH daemon resides on a different host than the host you are connecting to with telnet, enter the name of the host you are connecting to with telnet in the 'to remote' field. In this instance, the telnet connection between the Reflection Secure Shell client and the SSH daemon is secure, but the telnet connection between the SSH daemon and the target host is not secure.
Figure 2 - Add Local Port ForwardingFollow the steps below to create a settings file that starts a Telnet session over the port you have redirected to connect through SSH.
Once you have created the Secure Shell and Telnet settings files, follow these steps to tunnel Telnet through the secure pipe.
Follow the steps below to verify that your Telnet session is running through the SSH tunnel.
Note: If the netstat command is not recognized, navigate to the C:\Windows\System32 directory and enter the command again.
If the port forwarding is successful, you should see a response similar to the following:
Active ConnectionsProto Local Address Foreign Address State TCP MY_PC:2460 my.server.com:22 ESTABLISHED TCP MY_PC:1025 localhost:2461 ESTABLISHED TCP MY_PC:2461 localhost:1025 ESTABLISHED |
In the example above, the first TCP row shows the SSH connection from port 2460 (a random port) on the workstation to port 22 (the default SSH port) on the SSH server.
The second and third TCP rows show the Telnet connection between port 1025 on the workstation, the port that has been configured to redirect Telnet connections (port 23) through the SSH tunnel (port 22), and a random port (2461) on the SSH server.
Note: If the second or third row shows the actual host name, such as my.server.com, instead of localhost, the tunnel has failed and the Telnet connection is not encrypted.