IBM i > ADMINISTRATOR > NETWORKS

Using SSHs Port-Forwarding Capabilities


 

Note: This article is part two of a two-part series. Part one ran in the September issue.

 

In the first part of this article, I introduced Secure Shell (SSH), which helps protect network communications, and specifically focused on the OpenSSH functions contained in the IBM* Portable Utilities for i5/OS*. In this follow-on article, I explain port forwarding and other SSH-related functions.

 

Port Forwarding

SSH provides "port forwarding" or "tunneling" capabilities. By using SSH port forwarding, network traffic that would normally flow in the clear is instead sent through an encrypted tunnel created by the active SSH connection. For example, say you want to connect across an insecure network to a remote iSeries* system using a 5250 Telnet session. This presents a problem since all of the Telnet traffic would normally flow across the network in the clear. However, by using SSH port forwarding, you can route the Telnet traffic through an encrypted tunnel provided by an active SSH session, thus preventing the Telnet traffic from being observed on the network (see Figure 1).

 

Here's how to set up a Telnet session through an SSH tunnel:

 

1. On the server, start the Telnet server and the SSHD server.

 

2. On the client, start an SSH session to the server (named "servername" in this example) and use the "-L" SSH command-line option to specify that traffic directed to port 12345 on the client (localhost) is to be redirected across the SSH connection to the port used by Telnet (23) on the server (servername):

 

ssh -L12345:localhost:23 -N servername

 

(Note: The "-N" option says we only want SSH to set up the port-forwarding tunnel-we don't want to issue any remote commands in the SSH session.) The preceding command syntax is what youd enter from within an i5/OS PASE session started with the CALL QP2TERM CL command. This CL command can also be used:

 

CALL PGM(QP2TERM) PARM(/QOpenSys/usr/bin/ssh

-L12345:localhost:23 -N servername)

 

As long as this SSH session remains active, other users on the client machine can Telnet to the server across the encrypted tunnel by starting a Telnet session to the localhost (127.0.0.1) IP address and port 12345 on the client. The CL incantation to start such a Telnet session looks like this:

 

TELNET RMTSYS(*INTNETADR) INTNETADR(LOCALHOST) PORT(12345)

 

As another example, the i5/OS POP3 server doesnt support SSL so passwords and e-mail messages flow across the network in the clear. We can set up a tunnel between port 12346 on the local host to port 110 (the POP3 port) on the server using this SSH command:

 

ssh -L12346:localhost:110 -N servername

 

By configuring the e-mail client to check for mail on port 12346 of the localhost, the communication (passwords and e-mail messages) will be retrieved across the network through the encrypted SSH tunnel.

 

SSH port forwarding can also help simplify firewall configuration. SSH clients connect to port 22 on the server by default (this port can be changed in the SSHD configuration file). By using SSH port forwarding, you can eliminate the need to open other ports on the firewall between the insecure network and your i5/OS system. Continuing the previous examples of routing Telnet (port 23) and POP3 (port 110) through the SSH tunnel, only connections on port 22 would need to be allowed. The communication on port 23 (or port 110) doesnt need to be opened on the firewall. It should also be noted that use of the "-g" option on SSH should be avoided. "-g" indicates to SSH to allow remote connections to any locally forwarded port. Using the earlier Telnet example, if we were to add "-g" to the SSH invocation, users of a third system could Telnet to port 12345 on the SSH client and be routed through the SSH tunnel to the remote Telnet server, too. This presents a sort of back door to the destination Telnet server since it looks like the connection is coming from the SSH client machine, not the third system.

 

 

By using SSH port forwarding, you can route the Telnet traffic through an encrypted tunnel provided by an active SSH session, thus preventing the Telnet traffic from being observed on the network.

Walt Madden, a senior software engineer at IBM, has worked on the development of i5/OS for more than 20 years.


comments powered by Disqus
Buyers Guide

Advertisement

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App
IBMi News Sign Up Today! Past News Letters

Advertisement