IBM Power Ideas Portal
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Post your ideas
Start by posting ideas and requests to this portal to enhance a Power product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas and add comments to ideas that matter most to you
Get feedback from the IBM team to refine your idea
Help IBM prioritize your ideas and requests
The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The Power teams will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.
Receive notification on the decision
Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.
Specific link you will want to bookmark for future use
IBM Unified Ideas Portal - https://ideas.ibm.com/ - Use this site to create or search for existing Ideas across all IBM products that are outside of Power, and track all of your personal interactions with all Ideas.
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.