openssh unix dev - Sep 2004 - X11 Forwarding troubles with OpenSSH client and OpenVMS host

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

scott rankin wrote:
[about a problem w/ssh + OpenVMS]
> 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.
I suspect your VMS system's SSH server does not pass $DISPLAY or (its 
equivalent) to the commands run non-interactively.

Try the VMS equivalent of "ssh yourhost 'echo $DISPLAY'"
("SHOW DISPLAY"
?) to display the variables and compare it with the same command run in 
an interactive session.

Not much to suggest other than talking to the vendor of that software...

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.