Re: Can't get X forwading working

Kaloian Doganov <[email protected]> writes:

> (I'm not sure whether this mailing list the apropriate place to report
> bugs or problems with GNU lsh.  If it is not, please point me to the
> right place.)

This is the right place, the only reason [email protected] isn't pointed
directly at this list anymore, is that posting has been restricted to
members-only, to reduce the amount of spam a little.

> Using GNU lsh 2.9-exp to login on a remote host ("mafra", running
> OpenSSH server with X11 forwarding enabled, of course), I end up with
> no DISPLAY environment variable on the remote host:

The experimental version doesn't yet support X11 (so the --x11-forward
flag should probably give an error). One reason is that in the split
of work beteen "lsh" an "lsh-transport", I'd like lsh-transport to do
all the cryptogrpahic work, so that the lsh program isn't even linked
with cryptographic libraries.

But for X11 forwarding, the client needs a cryptographic
pseudorandomness generator to create a "fake" cookie to use for the
forwarding. So I have to decide to either let "lsh" do some crypto
stuff anyway, or have it ask "lsh-transport" for the random cookie.

> The same example case goes a little further when I try to execute it
> with GNU lsh 2.0.3:

It is intended to work with lsh-2.0.3, but I can reproduce this
problem...

When I try it, with --verbose --debug, I get

  lsh: write_buffer: do_write length = 44
  lsh: write_buffer: do_write closure->length = 44
  lsh: do_read_packet: length = 36, pad_length = 4
  lsh: DEBUG: Received CHANNEL_OPEN lsh: (size 31 = 0x1f)
  00000000: 5a000000037831310000000400010000  Z....x11........
  00000010: 00004000000000033a3a31000086ba    ..@.....::1....
  
  lsh: handle_connection: Received packet of type 90 (CHANNEL_OPEN)
  lsh: Allocated local channel number 2
  lsh: x11 connection attempt, originator: ::1:34490
  lsh: Registering local channel 2.
  lsh: Taking channel 4 in use, (local 2).
  lsh: check_rec_max_packet: Reduced rec_max_packet from 32768 to 32668.
  lsh: format_open_confirmation: rec_window_size = 48,
                            rec_max_packet = 32668,
  lsh: DEBUG: Sent CHANNEL_OPEN_CONFIRMATION lsh: (size 17 = 0x11)
  00000000: 5b00000004000000020000003000007f  [...........0...
  00000010: 9c                                .
  
  lsh: write_buffer: do_write length = 52
  lsh: write_buffer: do_write closure->length = 52
  lsh: do_read_packet: length = 68, pad_length = 10
  lsh: DEBUG: Received CHANNEL_DATA lsh: (size 57 = 0x39)
  00000000: 5e00000002000000304200000b000000  ^.......0B......
  00000010: 12001000004d49542d4d414749432d43  .....MIT-MAGIC-C
  00000020: 4f4f4b49452d3100002f7785325c9bbf  OOKIE-1../w.2\..
  00000030: fae709686e8e4fa095                ...hn.O..
  
  lsh: handle_connection: Received packet of type 94 (CHANNEL_DATA)

when I attempt to start xclock, and then nothing more happens. (Be
careful with sharing debug output. But the secret cookie in the above
message is no longer valid.)

The next thing that should happen is that the client connects to the
local X server, and then sends an SSH_MSG_CHANNEL_WINDOW_ADJUST to
allow the remote end to send more than the initial 48 bytes of the X11
protocol connection message.

Regards,
/Niels