The adoption of the Secure Shell (SSH) file transfer protocol has gained a lot of momentum over the last few months. Major financial institutions are migrating from proprietary transfer systems, and from the Secure Sockets Layer FTP protocol (SSL FTP) to Secure Shell implementations. We’ve had support for Secure Shell file transfer automation in our Managed File Transfer solution, Alliance FTP Manager, for many years and our customers are making the switch with no difficulties.

But what about running the Secure Shell server on the IBM i platform? What do you need to know about securing the SSH server when it runs on the IBM i?

One of the most important things you can do is create a CHROOT jail for the SSH server.

I can see you raising your collective eyebrows right now! Let’s talk about what a CHROOT jail is, why you would want to do this, and how you can make it happen.

Without creating some additional controls, your implementation of the SSH server will leave your system very exposed to abuse. For example, if you SSH to a server and log in, you will be presented with a command line. For any of you Linux geeks, you know what a command line means. It’s free reign to wander all over the system. On any SSH server without good controls, you can change directory (CD) to any library or IFS file on the system. And then you can do a lot of damage!

CHROOT to the rescue!

The Linux CHROOT facility is designed to keep users in a tightly controlled area, or “jail”. It’s been a part of UNIX and Linux for decades, and is very well implemented in those systems. But we also have it on the IBM i platform. If set up correctly, your IBM i SSH server with CHROOT implemented will keep those users from wandering around your system. They will only be able to see the directories you give them, and they won’t be able to change to other directories. They are in the little jail that you created.

Fortunately, the IBM i OpenSSH licensed software provides full support for implementing CHROOT jails. You can enable CHROOT support in the SSH server configuration file, and IBM provides a Shell script to create all of the directories and objects you need for each user. And there are good instructions on how to set this up.

But there is one little piece of CHROOT that can be a challenge. For CHROOT to work properly, the SSH server has to be running as “root” when it starts. On an IBM platform, that means it has to be running under the QSECOFR user profile. But you can’t submit the job and specify the QSECOFR profile, so how does this bit of logic get automated?

In Alliance FTP Manager we’ve solved that problem for you. When you specify that you want to run in a CHROOT environment, we submit the job and perform a profile swap to QSECOFR. Voila! You have everything you need to use the SSH server with CHROOT enabled.

If you want to run the SSH server on your IBM i you can contact our technical support group to receive the added software for the Alliance FTP Manager product. You can be up and running with CHROOT’ed SSH in no time at all.

Patrick

---

Townsend Security’s FTP Manager has been helping IBM i (AS/400) users meet compliance regulations by securing and automating their data in motion to trading partners, customers, employees, and internal systems. Download our podcast “Secure Managed File Transfer on the IBM i – An Introduction” for more information on how we can help your organization save time and money by securely automating your file transfers.