Kaloian Doganov kaloian@doganov.org 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 bug-lsh@gnu.org 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