[Bug 1682] New: verbose log message unclear when X11 forwarding denied

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=1682

           Summary: verbose log message unclear when X11 forwarding denied
           Product: Portable OpenSSH
           Version: 5.3p1
          Platform: All
        OS/Version: NetBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ssh
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: jklowden at schemamania.org


When sshd is configured to deny X11 forwarding, the failure can be
mysterious.  Even very verbose logging produces non-obvious messages. 
A simple change to the (very clear) code will make diagnosis easier.  

Here is a fragment:

debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: channel 0: request x11-req
debug1: Sending command: nedit
debug1: channel 0: request exec
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug1: channel 0: read<=0 rfd 5 len 0
debug1: channel 0: read failed
debug1: channel 0: close_read
debug1: channel 0: input open -> drain
debug1: channel 0: ibuf empty
debug1: channel 0: send eof
debug1: channel 0: input drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
NEdit: Can't open display

At no point does the log say the server denied the X11 request.  The
reason is to be found in ssh.c as recently as v 1.328:

    /* Request X11 forwarding if enabled and DISPLAY is set. */
    display = getenv("DISPLAY");
    if (options.forward_x11 && display != NULL) {

If display is not NULL, x11_request_forwarding_with_spoofing() is
called.  If it fails, the error is logged.  

However, if display is NULL, processing continues.  The command
("nedit" in this case) is executed and complains DISPLAY isn't set, but
it's completely unclear why not.  

One reason sshd won't create a DISPLAY variable is when X11Forwarding
is set to No in /etc/ssh_config.  The version currently used in cygwin,
which is where I encountered it, behaves that way.  

Ideally the client would interrogate the server, asking whether or not
X11Forwarding is enabled and log the response.  If that can't easily be
done, the above && condition could be split and a warning produced,
something along the lines of:

    if (options.forward_x11) {
            if (display == NULL) 
                logit("Warning: no DISPLAY set.  Remote host might not
permit  X11 forwarding.");

I hope the above provides sufficient information.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.