X11 Forwarding troubles with OpenSSH client and OpenVMS host

[scott rankin]

Hello,
I searched through the mailing list archives here, at
securityfocus.com, at HP and google and have come up dry. Sorry in
advance if my search was not complete enough or I missed something but
I sure as heck didn't see anything.

ENV: Slackware 10 w/ ssh (SSH-2.0-OpenSSH_3.8.1p1) connecting to an
alpha with OpenVMS 7.3-2  w/ sshd (Remote protocol version 2.0, remote
software version 2.4.1 SSH Secure Shell OpenVMS V1.0)

I have also tried using the 3.9p1 ssh client in cygwin and it fails in
the same manner.

The problem I am seeing is that when issued as a remote command over
X11 forwarding, I get an X Toolkit Error: Can't Open display. If I
just connect with X11 forwarding enabled, get an interactive shell and
then run the X client, it displays back.

$ ssh -X BOZO at vmshost
BOZO at vmshost's password:
 Welcome to OpenVMS (TM) Alpha Operating System, Version V7.3-2

Hello BOZO
Welcome to vmshost
 vmshost_[BOZO]> run sys$system:decw$clock

Works great and I get a clock.


$ ssh -X BOZO at vmshost 'run sys$system:decw$clock'
BOZO at vmshost's password:
X Toolkit Error: Can't Open display
%DWT-F-NOMSG, Message number 03AB8204

I initially tried forcing tty allocation. 
$ ssh -X -t BOZO at vmshost 'run sys$system:decw$clock'

No help. Same error failure.


I turned on some more verbosity in the SSH client and notice a couple
differences.
In the successful case,
...
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
[trim tty_make_modes]
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 10000 rmax 16384

 Welcome to OpenVMS (TM) Alpha Operating System, Version V7.3-2

Hello BOZO
Welcome to vmshost
 vmshost_[BOZO]> run sys$system:decw$clock

debug1: client_input_channel_open: ctype x11 rchan 1 win 30000 max 1024
debug1: client_request_x11: request from 192.168.21.33 51560
debug2: fd 7 setting TCP_NODELAY
debug2: fd 7 setting O_NONBLOCK
debug3: fd 7 is O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 2 win 30000 max 1024
debug1: client_request_x11: request from 192.168.21.33 51561
debug2: fd 8 setting TCP_NODELAY
debug2: fd 8 setting O_NONBLOCK
debug3: fd 8 is O_NONBLOCK
debug1: channel 2: new [x11]
debug1: confirm x11


However in the failing case (with or without forcing a tty allocation) I see,

debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
debug1: Sending command: run sys$system:decw$clock
debug2: channel 0: request exec confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 10000 rmax 32768

debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: output open -> drain
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close

%DWT-F-NOMSG, Message number 03AB8204
debug3: channel 0: will not send data after close
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)

debug3: channel 0: close_fds r -1 w -1 e 6 c -1
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.6 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0

It's like the exec request is not being handled properly (in the
failing case)? Or perhaps the new channel request is not happening? Or
the proxy $DISPLAY equivalent handled by sshd on the VMS box isn't
setup?

Does anyone know if this works (i.e. running a remote command over SSH
without an interactive shell) or does OpenVMS require an interactive
shell in order to run a remote command over SSH? I am not that saavy
on OpenVMS enough to know the best way to troubleshoot.

As a test I modifyied ssh_session2_setup() in ssh.c to force
requesting a shell before and after (in addtion to issuing) the exec
request to no avail.

Any thoughts or suggestions greatly appreciated.

cheers,
scott rankin