Add Exit Point for *SSHD

A client explained to me that exit points were necessary for blocking certain types of access in real time, rather than analyzing a log file retrospectively, after the potential damage was done. Lack of exit points inhibited their adoption of SSH and tools based on SSH.

The CAAC has reviewed this requirement and recommends that IBM view this as a “nice to have” low priority feature. As KristerK points out below, work-arounds have already been documented by IBM.

Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.

For more information about CAAC, see www.common.org/caac

For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/

Nancy Uthke-Schmucki - CAAC Program Manager

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Power Systems
Product - IBM i
Component - Open Source, PASE
Operating system - IBM i
Source - None

For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - Power Systems
Product - IBM i
Component - Security
Operating system - IBM i
Source - None

We use a layered approach to security which includes both object level security and exit points. For us, the advantage of the exit point is to allow custom controls, so as jlhall touched on below, the exit point would allow for constraints such as allowing an *allobj profile (or any other permitted user/group) to connect only from specific ip addresses and/or time frames. So, the exit point would allow a user from SSHUSER02 group access during working hours from a permitted local ip list but deny access during off hours. I had forgotten about activating syslog for the extra detail, so thank you for the reminder/feedback.

While correct object authority is vital, it may not be the solution for this item. It doesn't allow an organization to limit remote access to certain users or based upon other conditions. For instance, we use exit points on our FTP server to prohibit access by any user with any special authority unless the remote IP address is in the local network. This allows us to restrict *ALLOBJ users from using remote access. If you're relying on object authority alone, there is a potential exposure if an *ALLOBJ user's password has been compromised.

Missed the logging part of this RFE. As openSSH was original created for unix system, you need to enable syslog to get the logs for SSH access: https://www.ibm.com/support/pages/syslog-syslogd-pase-ibm-i

Exit point is IBM i platform specific, while SSH is an open source product for several different platform. So why not use SSH built in functions to restrict access by user or usergroups?

https://www.ibm.com/support/pages/allowing-or-denying-access-ibm-i-secure-shell-daemon-sshd-using-group-profiles

Hello Jeff,

After having had a look at your RFE, I did give it a try out of curiosity. After all the proof of the pudding is in the eating.

When starting the *SSHD server with the STRTCPSVR command and afterwards starting a session with IBM i ACS => SSH Terminal I can signon without leaving a trace in the history log.
The SSH Teminal will kick off a job in my case 049375/QSECOFR/QP0ZSPWP, when doing a dsplog job(049375/QSECOFR/QP0ZSPWP) I get no result. So I think this RFE needs some more attention. It is not just an exit point only question I think. Please let me know if you agree with this.

Greetings Rudi

Using exit-programs is a first defense but it will be a never ending fight… correct object authority is the way to go.