(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.)
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:
--------------------8<-------------------- $ /usr/local/bin/lsh --x11-forward --verbose mafra.doganov.org lsh: Enabling default escape character `~' lsh: Could not open gateway: (errno = 2): No such file or directory lsh: Starting /usr/local/bin/lsh-transport. Passphrase for key `kaloian@millenium-falcon': lsh-transport: Connecting to mafra.doganov.org:22.... lsh-transport: ... connected. lsh-transport: Server version string: SSH-2.0-OpenSSH_4.3p2 Debian-9 lsh-transport: Received KEXINIT message. Key exchange initated. lsh-transport: Selected keyexchange algorithm: diffie-hellman-group14-sha1 with hostkey algorithm: ssh-rsa lsh-transport: Selected bulk algorithms: (client to server, server to client) Encryption: (aes256-cbc, aes256-cbc) Message authentication: (hmac-sha1, hmac-sha1) Compression: (none, none) lsh-transport: SPKI host authorization successful! lsh-transport: Requesting authentication using the `publickey' method. lsh-transport: Received USERAUTH_SUCCESS. lsh: Allocated local channel number 0 lsh: pty request succeeded Linux mafra 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Sun Jun 3 22:52:11 2007 from 141.201.pppoe.intech.bg kaloian@mafra:~$ echo $DISPLAY
kaloian@mafra:~$ --------------------8<--------------------
The same example case goes a little further when I try to execute it with GNU lsh 2.0.3:
--------------------8<-------------------- $ /usr/local/bin/lsh --x11-forward --verbose mafra.doganov.org lsh: Enabling default escape character `~' lsh: Using local X11 transport `/tmp/.X11-unix/X0' Passphrase for key `kaloian@millenium-falcon': lsh: garbage collecting... lsh: Objects alive: 88, garbage collected: 24 lsh: Client version: SSH-2.0-lsh-2.0.3 lsh - a GNU ssh Server version: SSH-2.0-OpenSSH_4.3p2 Debian-9 lsh: Received KEXINIT message. Key exchange initated. lsh: Selected keyexchange algorithm: diffie-hellman-group14-sha1 with hostkey algorithm: ssh-rsa lsh: Selected bulk algorithms: (client to server, server to client) Encryption: (aes256-cbc, aes256-cbc) Message authentication: (hmac-sha1, hmac-sha1) Compression: (none, none) lsh: SPKI host authorization successful! lsh: Received NEWKEYS. Key exchange finished. lsh: Setting session key lifetime to 2400 seconds lsh: Requesting authentication using the `none' method. lsh: Requesting authentication using the `publickey' method. lsh: Requesting authentication using the `publickey' method. lsh: SSH_MSG_USERAUTH_PK_OK received lsh: Sending `publickey' signature. lsh: User authentication successful. lsh: Allocated local channel number 0 lsh: Registering local channel 0. lsh: Taking channel 0 in use, (local 0). lsh: Requesting a remote pty. lsh: Requesting X11 forwarding. lsh: pty request succeeded lsh: X11 request succeeded Linux mafra 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Sun Jun 3 22:52:22 2007 from 141.201.pppoe.intech.bg kaloian@mafra:~$ echo $DISPLAY localhost:10.0 kaloian@mafra:~$ xclock lsh: Allocated local channel number 1 lsh: x11 connection attempt, originator: 127.0.0.1:50836 lsh: Registering local channel 1. lsh: Taking channel 3 in use, (local 1). --------------------8<--------------------
xclock hangs forever at this point and xclock's window is not displayed on the X server.
The same test with openssh -X leads to xclock's window actually displayed on the X server.
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
Kaloian Doganov kaloian@doganov.org writes:
The same example case goes a little further when I try to execute it with GNU lsh 2.0.3:
It seems this was a bug introduced in the string reorganization before lsh-2.0. With the below patch, x11 forwarding works again, at least for me. I'll see when I get the time for a lsh-2.0.4 bugfix release.
(I thought I wrote some proper X11 testcase a long time ago, using some fake x11 server, but appearantly there's nothing like that... Suggestions for automatic regression testing of the x11 forwarding are appreciated).
Regards, /Niels
diff -u -a -p -r1.26 client_x11.c --- src/client_x11.c 16 Nov 2003 18:40:37 -0000 1.26 +++ src/client_x11.c 4 Jun 2007 20:55:02 -0000 @@ -211,6 +211,7 @@ do_client_channel_x11_receive(struct ssh /* The small initial window size should ensure that all the data fits. */ lsh_string_write_string(self->buffer, self->i, data); + self->i += lsh_string_length(data); lsh_string_free(data);
buffer = lsh_string_data(self->buffer);
-
Kaloian Doganov -
nisse＠lysator.liu.se