[Bug 3965] SSH sessions not recorded in utmp/utmpx on non-PAM systems (OpenSSH 9.x regression)
bugzilla-daemon at mindrot.org
bugzilla-daemon at mindrot.org
Sun May 31 01:20:12 AEST 2026
https://bugzilla.mindrot.org/show_bug.cgi?id=3965
--- Comment #2 from Cary Lewis <cary.lewis at gmail.com> ---
(In reply to Damien Miller from comment #1)
> record_login is still called during PTY allocation, see
> monitor.c:mm_answer_pty()
>
> My understanding was that these files were updated only when the
> login had a PTY assigned. Is this different on SCO OpenServer?
On further investigation, the issue is not that privsep is absent on
SCO — privsep does work and the sshd user is used for the
pre-authentication phase. The explanation is different.
In 8.5p1, the post-auth session child ran as the unprivileged sshd
user throughout the session. Because it was unprivileged it could not
allocate a PTY directly, so it sent MONITOR_REQ_PTY to the monitor. The
monitor handled PTY allocation via mm_answer_pty(), which called
mm_record_login() — that is how utmpx was updated.
In 9.8p1 with the new sshd/sshd-session split, the session child
(sshd-session: user at ttyp) runs as root throughout the session
(confirmed from ps output on SCO). Because it is already root it
allocates the PTY directly without sending MONITOR_REQ_PTY to the
monitor. mm_answer_pty() and mm_record_login() are therefore never
reached.
This is likely not SCO-specific. Any non-PAM platform where the 9.x
session child runs as root would have the same problem — PAM-based
systems simply don't notice because pam_session records the utmp entry
independently. On SCO there is no PAM, so the broken monitor path is
the only thing that was providing utmpx updates.
--
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
More information about the openssh-bugs
mailing list