On Mon, Dec 22, 2008 at 10:51:26AM -0500, Robert P. J. Day wrote: > > We do have /dev/pts mounted, that may or may not make a difference > > (didn't check the code). > > i may do that at the earliest possible opportunity, but here's > what's happening. certainly, without mounting /dev/pts, i expect a > login failure since all of /dev is read-only. > > however, after i mount /dev/pts RW, i can see that i have two char > device files under there: /dev/pts[01]. and i've verified i can > change their permissions with "chmod". so that's a good sign -- that > the contents under /dev/pts are modifiable, at least to that extent. > > however, when i try to ssh into that system from elsewhere and i > watch the destination system /var/log/messages, i can see that the > password authentication succeeds, after which i get an authpriv.warn > log message complaining about syslogin_perform_logout: logout(pts/2) > returned an error: No such file or directory
Devices in /dev/pts get "automatically" created by the openpty() call made by Dropbear - you don't create files there yourself. The usual tool I use for debugging things like this is strace - run "strace -f" on the main Dropbear process, if it's available. Are there any other log messages suggesting why it's failing? The "logout" log warning isn't something to worry about - that just means that it couldn't write user login/logout details to /var/log/wtmp or /var/log/utmp. You can configure Dropbear with --disable-loginfunc to avoid it trying that. Also to eliminate other factors, check that "ssh -T" to the host works. That will skip the tty allocation stage entirely, you should still be able to run commands like "ls" and get output. Cheers, Matt
