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.