Skip to Main Content
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,

  1. Post an idea

  2. Upvote ideas and add comments to ideas that matter most to you

  3. 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 - - 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.

Status Future consideration
Workspace IBM i
Created by Guest
Created on Sep 18, 2019

Add Exit Point for *SSHD

Add an exit point to *SSHD for logon validation that would enable rejection of the ssh connection by UserID and/or IP address.

Use Case:

We need to be able to log access to the system. As it stands, an end user can use ssh to shell or sftp into the system circumventing exit point restrictions that exist for FTP, ODBC, TELNET, etc... This new exit point would allow for audit / controls on which users can successfully connect to the system through SSH.

Idea priority High
  • Guest
    Nov 26, 2019

    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

    For more details about CAAC's role with RFEs, see

    Nancy Uthke-Schmucki - CAAC Program Manager

  • Guest
    Oct 25, 2019

    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

  • Guest
    Sep 21, 2019

    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.

  • Guest
    Sep 19, 2019

    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.

  • Guest
    Sep 19, 2019

    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:

  • Guest
    Sep 19, 2019

    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?

  • Guest
    Sep 19, 2019

    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

  • Guest
    Sep 19, 2019

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