X11forwarding yes: how to debug/setup after xauth fix

Michael Felt
Fri, 13 Oct 2017 11:40:37 -0000

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