how to run dropbear on a system with a R/O /dev?

Robert P. J. Day rpjday at crashcourse.ca
Wed Dec 24 03:30:10 WST 2008


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?

  to summarize what i'm seeing via "strace -f dropbear" (and i'm
reproducing this manually looking from one system to another):

 *  stat64("/dev/ttyp0", ...)
 *  ...
 *  lchown32("/dev/ttyp0", 0, 5) = -1 EROFS (Read-only file system)

  can i take a guess at what's happening?  dropbear wants to open a
session on /dev/ttyp0, it stat's that device file, finds it and
commits to it, only to find later that it can't modify the file
attributes and craps out.  is that remotely accurate?

  and i don't see how dropbear gets around to working with anything
under /dev/pts.  on another system that is NFS-mounted and on which
dropbear works fine, any ssh session always corresponds to a
/dev/ttyp* file.  so what does /dev/pts/? have to do with any of this?

rday
--



========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================



More information about the Dropbear mailing list