5.3 -> 5 : sshd multiple log entries & login_getclass: unknown class 'root'

[Andrew Konstantinov]

Hello,

As the topic says, I've experienced some unusual sshd behavior after I moved
some of my systems from RELENG_5_3 to RELENG_5 recently. The unusuality of the
behavior is illustrated by the following exerpt from the /var/log/auth.log on
the RELENG_5 system:

Jan 29 14:53:38 mail sshd[699]: login_getclass: unknown class 'root'
Jan 29 14:53:38 mail last message repeated 3 times
Jan 29 14:53:38 mail sshd[699]: Accepted publickey for root from 192.168.0.1 port 60094 ssh2
Jan 29 14:53:38 mail sshd[698]: Accepted publickey for root from 192.168.0.1 port 60094 ssh2
Jan 29 15:32:15 mail sshd[836]: login_getclass: unknown class 'root'
Jan 29 15:32:15 mail last message repeated 3 times
Jan 29 15:32:15 mail sshd[836]: Accepted publickey for root from 192.168.0.1 port 53837 ssh2
Jan 29 15:32:15 mail sshd[835]: Accepted publickey for root from 192.168.0.1 port 53837 ssh2
Jan 29 16:40:16 mail sshd[1034]: login_getclass: unknown class 'root'
Jan 29 16:40:16 mail last message repeated 3 times
Jan 29 16:40:16 mail sshd[1034]: Accepted publickey for root from 192.168.0.1 port 54714 ssh2
Jan 29 16:40:16 mail sshd[1033]: Accepted publickey for root from 192.168.0.1 port 54714 ssh2
Jan 29 17:10:27 mail sshd[1125]: login_getclass: unknown class 'root'
Jan 29 17:10:27 mail last message repeated 3 times
Jan 29 17:10:27 mail sshd[1125]: Accepted publickey for root from 192.168.0.1 port 54337 ssh2
Jan 29 17:10:27 mail sshd[1124]: Accepted publickey for root from 192.168.0.1 port 54337 ssh2

All of the systems have login.conf which contains entry for a root class. I've
rebuild the login.conf.db database to make sure that it's not a filesystem
glitch and even copied the default login.conf from /usr/src followed by
rebuilding the login.conf.db database, but none of that helped. The manual page
for the login_getclassbyname() explicitely states:

  In addition, if the referenced user has a UID of 0 (normally, "root", although
  the user name is not considered) then login_getpwclass() will search for
  a record with an id of "root" before it searches for the record with the id of
  "default".

So, the "root" entry IS there but for some reason either sshd is being buggy or
login_getclassbyname() is behaving strangely because as far as I know this
shouldn't be happening.

Also, for some reason, for each successful login attempt there are two
identical entries apparently made by two different instances/fork's of sshd
since they have different PID's. This started happening the same time when the
first problem appeared, which is after recent upgrade from RELENG_5_3 to
RELENG_5.

I've taken a diff between RELENG_5_3 and RELENG_5 but didn't find any obvious
changes that could have led to this unusual situation. I guess that only
somewhat related change could be the addition of "logpriv" mechanism for
protection against consequences of syslogd flooding.

To convince myself that all of this is specific to RELENG_5_3 -> RELENG_3
upgrade, I've just reversed one of the systems back to RELENG_5_3 and all of
the above mentioned problems have disappeared. All of the upgrades and
downgrades have been accompanied with mergemaster.

Some addition info about the "mail" system above:

mail# uname -rs
FreeBSD 5.3-STABLE
mail# grep ssh /etc/rc.conf
sshd_enable="YES"
mail# grep syslog /etc/rc.conf
syslogd_flags="-4 -s -b 192.168.0.7"
mail# grep root /etc/master.passwd | head -1
root:*:0:0::0:0:Andrew Konstantinov:/root:/bin/csh
mail# grep -EA 3 '^root:\\' /etc/login.conf
root:\
	:ignorenologin:\
	:tc=default:

mail# 



Am I missing something obvious here? Any pointes on debugging this? Please, let
me know if additional info is needed.

Thanks,
  Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20050130/8c9c20ef/attachment-0001.bin