Re: X11forwarding yes: how to debug/setup after xauth fix

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



On Thu, 12 Oct 2017, Michael Felt wrote:

> On 08/10/2017 23:32, Michael Felt wrote:
> > On 04/10/2017 11:07, Michael Felt wrote:
> >> I do not often use X11 - but when I do I prefer to enable 
> >> X11forwarding, and when finished - turn it off. This is preferable, 
> >> imho, to having "clear" X11 processing when local - and otherwise 
> >> impossible when working remote.
> >>
> >> Working with openssh-7.5p2 I cannot figure out what (extra) I need to 
> >> do with sshd_config to get it working.
> >>
> >> I know that there is a security-fix starting with openssh-7.2 
> >> (https://www.openssh.com/security.html, March 9, 2016) - and when I 
> >> load any version of openssh prior to Openssh-7.2 I get the expected 
> >> X11 behavior over an ssh(d) X11forwarding tunnel.
> >>
> >> So, what should I be looking at on my server or client-side. Is there 
> >> a different setting I should be using? I am still using the "putty" 
> >> setting of: MIT-Magic-Cookie-1. (I'll test, in a moment using 
> >> XDM-Authorization-1). However, the hint I am hoping for is the flag 
> >> to set for sshd (e.g., -ddddd) and what debug string - to see if 
> >> X11forwarding is attempted, and if so, why it is rejected by the sshd.
> >>
> >> Again - no changes to client-side - openssh-7.1 and earlier work, 
> >> openssh-7.2 and later do not.
> >>
> > If you need more verbose debug data - please say what you need 
> > specifically.
> 
> No comments? Is the data in the wrong format?
> 
> IMHO - any comment is better than no comment. If it will take time - I 
> will wait. But being held up because the data is wrong - and noone 
> saying so - is counterproductive.

I took a look at it and can't see any obvious error, nor could I reproduce
the failure with 7.6p1 locally. 

Looking at the server log:

> debug3: receive packet: type 98
> debug1: server_input_channel_req: channel 0 request x11-req reply 1
> debug1: session_by_channel: session 0 channel 0
> debug1: session_input_channel_req: session 0 req x11-req

sshd receives the request

> debug3: send packet: type 4

sshd sends a SSH2_MSG_DEBUG back to client, probably indicating
why the request failed

> debug3: send packet: type 100

sshd sends SSH2_MSG_CHANNEL_FAILURE.

The debug message would probably give you the reason it fails. You could
try to wheedle it out of PuTTY, apply the patch below to have it shown
at LogLevel=debug3 or try to guess which of one of likely ones it is
from session.c:session_setup_x11fwd()

> packet_send_debug("X11 forwarding disabled in user configuration file.");
> packet_send_debug("X11 forwarding disabled in server configuration file.");
> packet_send_debug("No xauth program; cannot forward with spoofing.");
> packet_send_debug("Can't get IP address for X11 DISPLAY.");

-d

diff --git a/packet.c b/packet.c
index f114ea52..5dda4243 100644
--- a/packet.c
+++ b/packet.c
@@ -1774,6 +1774,8 @@ ssh_packet_send_debug(struct ssh *ssh, const char *fmt,...)
 	vsnprintf(buf, sizeof(buf), fmt, args);
 	va_end(args);
 
+	debug3("sending debug message: %s", buf);
+
 	if ((r = sshpkt_start(ssh, SSH2_MSG_DEBUG)) != 0 ||
 	    (r = sshpkt_put_u8(ssh, 0)) != 0 || /* always display */
 	    (r = sshpkt_put_cstring(ssh, buf)) != 0 ||
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux