Issues with trusted X11 forwarding and VcXsrv

[sjevtic]

Background/Setup

SupportX11 Forwarding (#1515) was recently and delivered as part of OpenSSH 8.1.0.0. However, the appear to be some problems with this functionality. Here is how I set up for my test.

1. Install OpenSSH 8.1.0.0.
2. Install VcXsrv 1.20.6.0.
3. Add configuration to C:\ProgramData\ssh\ssh_config: XAuthLocation "/C:/Program Files/VcXsrv/xauth.exe"
4. Update environment variable: set PATH=%PATH%;C:\Program Files\OpenSSH;C:\Program Files\VcXSrv.
5. Update environment variable: set DISPLAY=localhost:0.0.
6. Verify VcXsrv installation by running vcxsrv.exe :0 -multiwindow and then local xclock.exe.

Problems

I encountered two issues when exercising this functionality.

ForwardX11Trusted Does Not Work

I tried three mechanisms to enabled trusted X11 forwarding:

1. Supplying the configuration option on the command line (e.g., ssh.exe -vvv -o "ForwardX11Trusted yes" user@host). The debug output contains no references to X11 forwarding, and the DISPLAY environment variable is not set in the resulting session.
2. Supplying the configuration option in the config file (C:\ProgramData\ssh\ssh_config). The debug output contains no references to X11 forwarding, and the DISPLAY environment variable is not set in the resulting session.
3. Using the -Y command line option. This does work, subject to mishandling of Xauth described below.

Mishandling of Xauth and DISPLAY Environment Variable

When running ssh.exe -vvv -Y user@host, the following the following is seen in the debug output:

debug2: x11_get_proto: /C:/Program Files/VcXsrv/xauth.exe  list unix:0.0 2>NUL
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.

Apparently, ssh is trying to convert localhost in the DISPLAY environment variable to unix, as implemented in client_x11_get_proto() (clientloop.c):

if (xauth_path != NULL) {
    /*
     * Handle FamilyLocal case where $DISPLAY does
     * not match an authorization entry.  For this we
     * just try "xauth list unix:displaynum.screennum".
     * XXX: "localhost" match to determine FamilyLocal
     *      is not perfect.
     */
    if (strncmp(display, "localhost:", 10) == 0) {
        if ((r = snprintf(xdisplay, sizeof(xdisplay), "unix:%s",
            display + 10)) < 0 ||
            (size_t)r >= sizeof(xdisplay)) {
            error("%s: display name too long", __func__);
            return -1;
        }
        display = xdisplay;
    }

This does not make much sense, since, unlike on Linux, VcXsrv apparently does not accept DISPLAY to be set to :0.0 or unix:0.0; even the bundled xclock.exe will not run with DISPLAY set to this. Running xauth independently without redirecting stderr further makes this point:

C:\Users\username>xauth list unix:0.0
xauth: (argv):1:  bad display name "unix:0.0" in "list" command

I tried to thwart this logic by setting DISPLAY differently:

set DISPLAY=127.0.0.1:0.0

When running ssh.exe again (as before) I now get:

debug2: x11_get_proto: /C:/Program Files/VcXsrv/xauth.exe  list 127.0.0.1:0.0 2>NUL
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.

So, while the xauth command now looks reasonable, the result does not. I even tried creating my own authorization entry for the display:

C:\Users\username>xauth
xauth> generate 127.0.0.1:0.0 . trusted
authorization id is 121
xauth> exit
Writing authority file \users\username\.Xauthority

Then I verified that xauth would send info to stdout about it:

C:\Users\username>xauth list 127.0.0.1:0.0 2>NUL
hostname/unix:0  MIT-MAGIC-COOKIE-1  69f77dc9eba6e054cffc6f1b48ca853b

But I still received the same debug messages. Looking at the code I found:

if (trusted || generated) {
    xasprintf(&cmd,
        "%s %s%s list %s 2>" _PATH_DEVNULL,
        xauth_path,
        generated ? "-f " : "" ,
        generated ? xauthfile : "",
        display);
    debug2("x11_get_proto: %s", cmd);
    f = popen(cmd, "r");
    if (f && fgets(line, sizeof(line), f) &&
        sscanf(line, "%*s %511s %511s", proto, data) == 2)
        got_data = 1;
    if (f)
        pclose(f);
    free(cmd);
}
// ...
if (!got_data) {
    u_int8_t rnd[16];
    u_int i;

    logit("Warning: No xauth data; "
        "using fake authentication data for X11 forwarding.");

As evidenced by the warning, one or more of the following must be happening since got_data is clearly not being set to 1:

1. File handle f is bad.
2. xauth.exe is not being run or is not producing output for capture into line by fgets().
3. sscanf() is not properly parsing line.

Unfortunately, based on the existing debug statements, it is hard to determine more closely what is happening.

In the end, VcXsrv's default behavior is to allow connections from localhost so the fake authentication data ends up working. However, it would be nice for this to work as intended, even if for no other reason than to get rid of the warning.

[WSLUser]

It's an accepted issue in order for this feature to work. The only thing might be to hide the message from user perspective. Remember that we're relying on third party X server here. It's not probable to "fix" the actual error.

[sjevtic]

Why is this an accepted issue? The xauth application is there, and even appears to conform to the standard interface that ssh is expecting. Thus, it appears only that the "glue" between ssh and xauth isn't quite working on Windows, and that should be relatively straightforward to fix.

[WSLUser]

From #1515

Great, so now to reproduce the issue this PR fixes:
Ensure C:\dev\tty doesn't exist
Ensure DISPLAY is set, then ssh -Y user@host
Observe authentication failure
The failure is a result of ssh passing the check at line 181 (use_askpass is 1 because we don't have a tty), then entering a block of code that assumes ASKPASS is present, which fails.

[riverar]

I can take a look at this @bagajjal.

@sjevtic I'm using VcXsrv with no issues but I suspect we're hitting a few edge cases like you pointed out. Let me set up a repro and get back to you.

[riverar]

@sjevtic Regarding issue 1, you're missing -o "ForwardX11 yes". I suspect this is also why issue 2 is broken (missing from file). -y is shorthand for toggling both these options, ForwardX11Trusted alone does not turn on X11 forwarding.

Looking into the XAuth issue now.

[riverar]

Regarding the XAuth issue reported above, there appear to be several issues entangled here:

1. VcXsrv's implementation of xauth seems to be missing unix: support (xauth list unix:10.0 on a Linux machine yields expected results).

   xauth manpage:

   Display names for the add, [n]extract, [n]list, [n]merge, and remove commands use the same format as the DISPLAY environment variable and the common -display command line argument. Display-specific information (such as the screen number) is unnecessary and will be ignored. Same-machine connections (such as local-host sockets, shared memory, and the Internet Protocol hostname localhost) are referred to as hostname/unix:displaynumber so that local entries for different machines may be stored in one authority file.

   VcXsrv seems active on Sourceforge, so I'll try to reach out.

   Workaround: Use 127.0.0.1: to bypass localhost: search

2. In untrusted (-X) scenarios, mktemp_proto fails internally during cookie generation because libssh has bad defaults for Windows.

   Workaround: Set TMPDIR=C:\Users\Rafael\AppData\Local\Temp (derived from %TEMP%) or other user-writable location.

3. In trusted (-Y) scenarios, popen fails if XAuthLocation points to a path containing spaces for obvious reasons. Will fix this up and submit a patch.

   Workaround: Use C:\Progra~1 for C:\Program Files or install VcXsrv into a location without spaces.

[sjevtic]

@riverar Thanks, this is really helpful. Interestingly, adding C:\Program Files\VcXsrv to PATH and setting XAuthLocation simply to "xauth.exe" also does not work. Is disregard for PATH expected behavior?

[riverar]

@sjevtic Not sure what the expected behavior is. Scouring the filesystem for a relatively-specified XAuth program sounds a bit dangerous given how unimaginative the filename is. We'd have to test what Linux does.

But can confirm it won't work on Windows, as ssh will resolve the relative filename to an absolute path (a few layers deep with _wfullpath), prepended with the current working directory. GetFileAttributesExW then fails. (Unless you put your executable there, of course.)

https://github.com/PowerShell/openssh-portable/blob/latestw_all/contrib/win32/win32compat/fileio.c#L816-L823

if ((wpath = resolved_path_utf16(path)) == NULL)
  return -1;

/* get the file attributes (or symlink attributes if symlink) */
if (GetFileAttributesExW(wpath, GetFileExInfoStandard, &attributes) == FALSE) {
  errno = errno_from_Win32LastError();
  goto cleanup;
}