Christiaan Welvaart <cjw(a)daneel.dyndns.org> writes:
> Your example describes the actual problem: lsh-keygen defaults to RSA
> while midpssh only supports DSA. After switching to a DSA hostkey, I
> got:
>
> lshd: pty_open_slave: Invalid terminal modes from client.
>
> The CHANNEL_REQUEST was:
>
> 00000000: 6200000000000000077074792d726571 b........pty-req
> 00000010: 000000000576743332300000003e0000 .....vt320...>..
> 00000020: 0028000000000000000000000000 .(............
> ^^^^^^^^
> Now the RFC 4254 is a bit strange, because it lists this field as:
>
> string encoded terminal modes
>
> while the description says it is a byte stream that is terminated by
> opcode TTY_OP_END (0x00). So I'm not sure if the pty-req request from
> midpssh is valid. With the patch below applied to lshd I can get a
> shell, though.
I'm in a hurry (packing for summer vacation), but I think most of the
blame should be on midpssh.
* I'm assuming that midpssh implements some kind of terminal
emulation, presumably vt320. Otherwise, sending a pty-req doesn't
make much sense. Then it ought to tell the server what terminal
modes it is emulating, or it can expect a broken user experience.
* But on the server side, it would make some sense to allow an empty
terminal mode string, and interpret it as "I'm happy with any
random selection of terminal modes that one gets by default on
this particular operating system when requesting a new pty-pair."
In lshd, I think it would be cleaner to do that check elsewhere,
though, and never call tty_decode_term_mode at all if the provided
string is empty.
Regards,
/Niels
