By Rich Loeber
Updated March 2, 2020 for Access Client Solutions emulator.
I was recently asked to secure remote access for 5250 terminal sessions for one of my customers. I did not have any experience securing Telnet on the IBM i, but I located some good documentation from IBM and was able to get the Telnet connection secured fairly quickly and easily. This tip will show you how.
Many IBM i shops still use the 5250 terminal interface for administration and operation of their systems. For them, the interface is well known and comfortable. The problem is that when used for remote access, the Telnet data stream is passed as open text and it is easy for someone with malicious intent to snoop in on the data stream and capture user profile and password information.
Fortunately, there is a way on the IBM i to encrypt your 5250 terminal sessions by implementing SSL (Secure Sockets Layer) for your Telnet connections. The IBM i uses a Telnet connection to support your 5250 terminal sessions.
There are two steps that you need to complete in order to set up SSL for Telnet. Part one involves configuration work on your IBM i server. Part two is what is needed on your client (your PC) in order to use the SSL connection.
The server configuration will require that you have option #34 (Digital Certificate Manager or DCM) of the base OS installed along with the HTTP server functions. On our 6.1 test box, the HTTP Server is 5761DG1. Before plunging into the project, I strongly recommend that you make sure that you have the latest HTTP server PTFs installed. When we first tried to use DCM after upgrading our OS, it would not work and we needed the PTFs.
To do the configuration work on your host, we found the following article with step by step instructions from IBM and I recommend that you use this procedure:
This process will require you to set up a self-issued digital certificate on your system and then assign it to several applications, including Telnet. If you have never used the Digital Certificate Manager on your system, be prepared to take some time to get used to it. The instructions from IBM are actually quite good.
After you get this configuration work done, make sure that you update the Telnet Attributes on your system using the CHGTELNA (Change Telnet Attributes) command. When starting, make sure that the Allow Secure Socket Layer (ALWSSL) parameter is set to *YES. This will allow both SSL and non-SSL Telnet connections. Once you are satisfied with the way the SSL connection is working, you can consider changing this setting to *ONLY which will then refuse non-SSL connection attempts.
Once the server configuration work is done, you can move on to the client configuration work. Again, I found a good set of instructions from IBM on this that you can access here: (These instructions are for IBM i Access For Windows.)
This process may require that you install additional Client Access components on your PC, so access to your Client Access install CD may be required. The process will call for your to import the certificate you created into your PC and then reconfigure your terminal session to use SSL. When importing the certificate, there is a standard password to use. That instruction is easily missed, so watch out for it.
If you are using IBM i Access Client Solutions (ACS), the Java based access software, the instructions for the 5250 emulator are easier once the digital certificate has been established using DCM (above). Using ACS, create a terminal session. When the session has been created, select the Configuration option under the Communications drop down menu. Update the “Protocol” to look as follows:
Note that when the Protocol is changed to “Telnet – TLS/SSL”, the “Destination Port” will be changed to 992. Click on OK and the session configuration change will be set correctly. Make sure that you now save it.
In addition to setting this up for my customer, I also took the long delayed step of setting this up for my own server. It is something I should have done long ago and I encourage all IBM i shops to adopt this standard for remote access Telnet session.
After initially posting this tip, a friend contacted me to suggest that implementing SSL on Telnet also helps customers with their PCI compliance requirements. PCI requires 2 factor authentication. He reported that one of his customers was able to meet this requirement using SSL. The two factors involved are the password and the digital certificate. Two factor authentication calls for something you know and something you have. SSL for Telnet does just that. (They also require use of VPN for any remote access.)
If you have any questions about this topic, you can reach me at rich at kisco.com, I’ll give it my best shot. All email messages will be answered.