On 13/10/2017 08:03, Damien Miller wrote:> 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,I'll try an iptrace trace - to see what putty is masking with XXXXX.> 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.");My 'quess' is that it somehow related to 'auth' - as there was a security-fix for auth that was introduced in version 7.2 (as I mentioned before: https://www.openssh.com/security.html, March 9, 2016) and https://www.openssh.com/txt/release-7.2p2 * sshd(8): sanitise X11 authentication credentials to avoid xauth command injection when X11Forwarding is enabled. My guess is that AIX is still sending either one of '\n', '\r', or even both.> -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); > +Will also try this!> 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 at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
On 13/10/2017 13:40, Michael Felt wrote:>> >>> 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, > I'll try an iptrace trace - to see what putty is masking with XXXXX. >> 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."); > > My 'quess' is that it somehow related to 'auth' - as there was a > security-fix for auth that was introduced in version 7.2 (as I > mentioned before: https://www.openssh.com/security.html, March 9, > 2016) and https://www.openssh.com/txt/release-7.2p2 > > ?* sshd(8): sanitise X11 authentication credentials to avoid xauth > ?? command injection when X11Forwarding is enabled. > > My guess is that AIX is still sending either one of '\n', '\r', or > even both. > >> -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); >> + > Will also try this!This verifies it is xauth related: debug3: sending debug message: No xauth program; cannot forward with spoofing. so, added an extra debug - and this is what I see: debug1: session_input_channel_req: session 0 req x11-req debug3: setup_x11fwd: xauth_location == /usr/X11R6/bin/xauth debug3: sending debug message: No xauth program; cannot forward with spoofing. but the xauth_location should be: # which xauth /usr/bin/X11/xauth and fyi: # ls -l /usr/bin/X11 lrwxrwxrwx??? 1 bin????? bin????????????? 16 Aug 31 17:40 /usr/bin/X11 -> /usr/lpp/X11/bin # ls -ld /usr/X11R6 drwxr-xr-x??? 2 bin????? bin???????????? 256 Aug 29 12:16 /usr/X11R6 # ls -l /usr/X11R6 total 0 lrwxrwxrwx??? 1 bin????? bin????????????? 19 Aug 31 17:40 lib -> /usr/lpp/X11/lib/R6 so, obviously - the stat() calls for /usr/X11R6/bin/xauth return -1. # ls -l /usr/X11R6/bin/xauth ls: 0653-341 The file /usr/X11R6/bin/xauth does not exist. And, I expect noone from IBM has ever said anything - as they still use OpenSSH-6.0 as a base, although they are also using OpenSSH-7.1, both of which are not affected by the fix for OpenSSH-7.2. Studying further - but maybe you already know what needs to be done.>> ????? 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 ||
On 13/10/2017 15:29, Michael Felt wrote:> This verifies it is xauth related: > > debug3: sending debug message: No xauth program; cannot forward with > spoofing. > > so, added an extra debug - and this is what I see: > > debug1: session_input_channel_req: session 0 req x11-req > debug3: setup_x11fwd: xauth_location == /usr/X11R6/bin/xauth > debug3: sending debug message: No xauth program; cannot forward with > spoofing. >...> And, I expect noone from IBM has ever said anything - as they still > use OpenSSH-6.0 as a base, although they are also using OpenSSH-7.1, > both of which are not affected by the fix for OpenSSH-7.2. >Or - MY error is more likely. By chance I must of had the fileset bos.X11.config installed - so configure was able to find a value for xauth. Now I know I need to add the configure option --with-xauth=/usr/bin/X11/xauth Many thanks for the hints - to get this resolved!> Studying further - but maybe you already know what needs to be done.