I'm attempting to reproduce some of the reported bugs on early Linuxes and I've 
found the following problem with privsep enabled (Debian slink, kernel 2.0.38, 
libc6 2.0.7).  It seems to be related to file descriptor passing.

$ ./sshd -ddd -p 2022
[snip]
debug3: mm_answer_pty entering
debug1: session_new: init
debug1: session_new: session 0
debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY
debug3: mm_request_receive_expect entering: type 26
debug3: mm_request_receive entering
debug3: mm_request_send entering: type 26
mm_receive_fd: expected type 1 got 1074276337

It seems to be a bug in 2.0 kernels, cmsg_level and cmsg_type returned by 
recvmsg() make no sense.  I built a test program (which I will attach) from code 
from monitor_fdpass.c.

After the fd pass, a 2.0.38 kernel gives:
(gdb) print *cmsg
$1 = {cmsg_len = 16, cmsg_level = 134514016, cmsg_type = -1073742828,   
__cmsg_data = 0xbffffc08 "\005"}

A 2.4.18 kernel gives:
(gdb) print *cmsg
$1 = {cmsg_len = 16, cmsg_level = 1, cmsg_type = 1, __cmsg_data = 0xbffff5fc 
"\a"}

If you comment out the "if (cmsg->cmsg_type != SCM_RIGHTS)" test in 
mm_receive_fd(), privsep seems to work OK on 2.0 kernels.

I will reduce the test program to an autoconf test, add "#ifndef 
BROKEN_CMSG_TYPE" and attach the resulting patch.