"Eric J. Schwertfeger" <[EMAIL PROTECTED]> writes:

> It's using poll().  I just tracked down the problem, but I'm not sure what
> to do with it.  Probably going to see what POSIX has to say about poll().
> Basically, if I replace POLLIN with POLLRDNORM, it reads NEW_KEY.  In
> fact, it almost works, except for 

Strange. I thought POLLIN was supposed to be an alias for POLLRDNORM.
If you find out how POSIX defines all the POLL* flags, let me know;
I'm still confused, in particular about POLLHUP.

>       lsh: Server's hostkey is not trusted. Disconnecting.
> 
> Probably because I ran both lsh and lshd as a regular user, and haven't
> set up the trust databases yet.

This is expected. The default behaviour is to never ever accept an
unauthenticated server.

> adding --sloppy-host-authentication fixes that, but now it just keeps
> prompting for the password, and the server logs 
> 
>       Raising exception Wrong password

If you use shadow passwords, this is also expected. I consider it a
bug in the shadow mechanism that there's no way for a program to
verify passwords corresponding to its own uid. If you have shadow
passwords, you'll have to either run lshd as root, like you did, or
use some other authentication method than the unix password.

> So, I ran lshd as root (I don't think programs can verify passwords under
> FreeBSD without root permissions), and this time lsh prints 
> 
>       Unhandled exception of type 0x8002: Channel request failed

And then it dumped core (looking at your log).

Looking at your server log,

: handle_connection: Received packet of type 98
: (SSH_MSG_CHANNEL_REQUEST)
: Client requesting a tty...
:  failed.
: DEBUG: Sent SSH_MSG_CHANNEL_FAILURE (size 5 = 0x5)
: 0x00000000: 6400000000

It seems the client requested a pty, and crashed when it couldn't get
one. In this case, it is supposed to just go on, but not bother trying
to do things like setting the tty into raw mode.

Running the client with --trace should give some more info about where
the exception is raised and which handlers are involved.

As a work around, try running the client with -nt to disable its
asking for a pty. To reproduce the bug here, I guess I'll have to add
an --no-pty option to lshd.

Regards,
/Niels

Reply via email to