[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 15:43:22 AEST 2026
https://bugzilla.mindrot.org/show_bug.cgi?id=3965
--- Comment #3 from Damien Miller <djm at mindrot.org> ---
(In reply to Cary Lewis from comment #2)
> (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 isn't correct. sshd-session forks and keeps a UID 0 monitor
process around but runs mostly as the user. PTY allocation still
happens via a monitor call, that was the code I pointed you to in my
previous reply.
Can you please post a debug trace from sshd (e.g. sshd -ddd) - I think
that would clear a lot of things up. Please also try to use the current
version - openssh-10.3 as it would be frustrating to go through a
debugging exercise for something that has already been fixed since
9.8p1.
--
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
More information about the openssh-bugs
mailing list