PDA

View Full Version : pam_keyinit(sshd:session): Unable to change GID to 100 temporarily



libove
27th December 2006, 11:49 AM
Starting right after I upgraded an existing Fedora Core 5 system to Core 6 on December 12th, 2006, I began seeing these messages a few times a day in /var/log/secure:

"pam_keyinit(sshd:session): Unable to change GID to 100 temporarily"

Here's the full context from /var/log/secure for one specific sshd process which produced the message:

Dec 24 12:33:46 panther8 sshd[4285]: Accepted password for libove from 216.27.163.46 port 4154 ssh2
Dec 24 12:33:46 panther8 sshd[4285]: pam_unix(sshd:session): session opened for user libove by (uid=0)
[ note time difference - the two entries below are for when the SSH session ends ]
Dec 24 13:49:15 panther8 sshd[4285]: pam_keyinit(sshd:session): Unable to change GID to 100 temporarily
Dec 24 13:49:15 panther8 sshd[4285]: pam_unix(sshd:session): session closed for user libove

Searching around forums and blogs, I see several other reports of this issue, none with a resolution.

I looked in the PAM sources and found this "Unable to change..." message in the pam_keyinit module. The specific text occurs in two functions in pam_keyinit - kill_keyrings() and pam_sm_open_session(). Since the appearance of the message in /var/log/secure is at the end of the SSH session, I assume that it is actually coming from kill_keyrings(), which seems to be the sort of thing which happens at the end of an SSH session, rather than from pam_sm_open_session(), which appears to be the sort of thing which happens at the beginning of an SSH session.

GID 100 on my system is the typical "users" group.
My user ID 137 is a member of group 100.
root (uid 0) is not a member of group 100, nor is the SSH Privilege Separation user (uid 74) a member of group 100.

I've been around UNIX since the mid-1980s, and I admit that I am unfamiliar with these newfangled things like PAM. :)

I do not get the impression that this is an actual security problem, and it does not appear to cause any operational problem. Nonetheless, I prefer nice clean log files, so I'd like to understand this and get it fixed.

Thanks
-Jay Libove, CISSP
Atlanta, GA, US