You may also want to change some of the default settings in your SSH configuration file. For example, I recommend that you do not let QSECOFR use SSH. (QSECOFR is a well-known profile. If someone is going to try to access your system, that’s a profile they know exists on all IBM i systems like root exists on all UNIX/Linux systems.) To disallow QSECOFR login, set PermitRootLogin to No.
Other configuration options to set:
- Your organization (likely your lawyers) may require all logins to display a banner stating access is for management-approved uses only. Specify the path to the banner (Banner /your pathname) where the banner is located.
- Only allow the more secure SSH2 protocol (Protocol 2).
- Use Session idle time-out (ClientAliveInterval 300).
- Session keep-alive number is the number of times users get a warning message that their session is about to time-out. If your time-out value is 300 and you set the keep-alive to 5, users will get a warning every 5 minutes, and if the session is idle, it will time-out after 25 minutes. It’s a bit like the QINACTITV and QINACTMSGQ system values. For SSH, it’s recommended that you just time-out the inactive session and don’t have a keep-alive (ClientAliveCountMax 0).
- Set a max number of sign-on attempts (MaxAuthTries). Match your QMAXSIGN system value, typically 3-5.
- Consider using public/private keys for authentication and disallowing the use of passwords on the connection. Here’s a link to the support page describing how to configure this: https://www.ibm.com/support/pages/configuring-ibm-i-ssh-sftp-and-scp-clients-use-public-key-authentication
- Disallow host-based authentication, which is different from and even less secure than user ID/password authentication (HostbasedAuthentication no).
Finally, consider configuring chroot. chroot is a UNIX/Linux method of setting a process’s root directory to restrict what the process can access. You may also see it referred to as a “container” or “jail.” Containers are often used when implementing automated SSH and SFTP processes. You know that I’m all for multiple layers of defense, and I do appreciate using chroot to provide at least a speedbump in the road to limit what users of SSH can access. But, just as prisoners can tunnel under prison walls or find other means of escape, users can escape the confinements of chroot. I’m not saying not to use it; please do. Just don’t depend on it as your single method of securing SSH access. Also, if you’re set up to allow a specific group, don’t forget to add this group profile to the profiles you’ve set up in your chroot configuration. For more information on chroot and IBM i, see this support page: https://www.ibm.com/support/pages/using-chroot-ibm-i-restrict-ssh-sftp-and-scp-specific-directories