Hi Whit, Did you solve the riddle already? When not, maybe use another approach? My favorite is: "HAL: I would recommend that we put the unit back in operation and let it fail." (http://miscel.wikidot.com/2001-transcript) Could you enable the old state with the spurious login being possible again (maybe blocking external SSH access to the machine for a moment), attach to the SSH root process by calling something like strace -o x.dump -s1024 -vvv -f -tt -p [pid] and then try yourself to perform a password login as backup to the machine? Then hook SSH on another machine in the similar way and login there too. Then compare the two dumps. If you you do not easily see the difference try focusing only on the output of the PID running the login process. Maybe also create to text files with only the syscall names from both attempts and "diff" them to see when things start getting weird. If the syscall sequence is identical, the mmaps might be interesting to compare. With same software version, the PROT_x flags and also the file offsets should be identical. Differences indicate backdoored libraries, sometimes even unmasking kernel root kits hiding that changes with normal command line ls/stat - what might be unlikely on a host just used for spamming. For that kind of analysis grep "mmap" and sed works best (get rid of ASLR entropy with sed). Kind regards, hd _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
