Flashes (Alerts)
Abstract
Starting OpenSSH 9.9p1 (VRMF 9.9.3015.1000), sshd daemon shows up in the process table as follows:
sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
This document explains the design changes starting with this OpenSSH release.
Content
As stated by the OpenSSH community, OpenSSH 9.9p1 (9.9.3015.1000) has the following design changes:
1. Listener binary (sshd).
2. Per-session binary (sshd-session).
2. Per-session binary (sshd-session).
When sshd server is in the listening state, only the listener binary shows up in the process table, as follows:
# ps -ef | grep sshd
root 5636544 4522392 0 17:19:14 - 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
Here are some key design changes:
1. The sshd listener binary starts up with the -D flag, enabling the debug level logging by default, compared to earlier versions, which defaulted to the INFO syslog facility.
2. When no clients are connected, only the sshd binary is started, as shown above. The whole purpose of the sshd binary in the new design is to be on the standby mode, in case of any incoming ssh connections.
3. When a client connects to the sshd server, the on-demand sshd-session binary is started.
In order to test the behavior a little further, I had to start another instance of sshd daemon, out of the SRC master support, and made it to listens on alternative TCP port 2222, as follows:
# /usr/sbin/sshd -p 2222
Now, the process table has two instances of sshd started:
# ps -ef | grep sshd
root 5636544 4522392 0 17:19:14 - 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root 15598058 1 0 17:21:12 - 0:00 sshd: /usr/sbin/sshd -p 2222 [listener] 0 of 10-100 startups
When a client connects to the sshd server, the sshd-session daemon gets started for the new session, as shown below:
# ps -ef | grep sshd
root 5636544 4522392 0 17:19:14 - 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root 11927932 16712188 0 19:14:25 - 0:00 sshd-session: root@pts/1
root 12059102 5636544 0 19:03:39 - 0:00 sshd-session: user01 [priv]
user01 13894030 12059102 0 19:03:46 - 0:00 sshd-session: user01@pts/0
root 15598058 1 0 17:21:12 - 0:00 sshd: /usr/sbin/sshd -p 2222 [listener] 0 of 10-100 startups
root 16712188 15598058 0 19:14:20 - 0:00 sshd-session: root [priv]
We can determine the following info from the process table:
- Which user is using which terminal.
- Which sshd daemon is parent to which ssh sessions.
So, it's the same as the old design, but with splitting the server activity on two daemons instead of just one.
Comparing the PIDs and PPIDs from the previous output, we notice that the "sshd-session: root@pts/1" is a child process of "sshd-session: root [priv]", which is, in turn, a child of the second sshd listener daemon that listens on TCP port 2222.
Likewise, we can trace the PIDs and PPIDs of "sshd-session: user01@pts/0" and "sshd-session: user01 [priv]" processes, back to original sshd -D listener daemon.
Bottom line:
The new sshd design divides the sshd server into two binaries: The listener daemon 'sshd' and the 'sshd-session' daemon. The former runs on standby, while the latter gets invoked on demand. Also the -D flag is not critical to the sshd server functionality.
[{"Type":"MASTER","Line of Business":{"code":"LOB08","label":"Cognitive Systems"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"ARM Category":[{"code":"a8m0z000000cvwrAAA","label":"Communication Applications"},{"code":"a8m0z000000cvzvAAA","label":"Security-\u003EOPENSSH\/OPENSSL"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]
Was this topic helpful?
Document Information
Modified date:
14 May 2025
UID
ibm17232425