On Tue, 23 Dec 2008, Matt Johnston wrote: > 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?
i hacked into the flashed system, and simply added a mount of the /dev/pts filesystem and, upon reboot, an attempt to ssh to the system caused dropbear to allocate /dev/pts/1. so this is progress. apparently, mounting that filesystem manually before didn't work, but having it mounted as part of the normal boot process was sufficient. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ========================================================================