Thursday, 27 October 2016

Hmmm, macOS Sierra and XQuartz and X11

I've not dug too far into this, but something has changed in the world of X11 forwarding between macOS and Linux, since I upgraded my Macs to macOS Sierra.

In the past, as long as I had XQuartz installed: -


I was able to happily tunnel over X11 between macOS and Linux, using a command such as: -

ssh -X wasadmin@was9001

but, since the update to Sierra, I see this: -

ssh -X wasadmin@was9001

which returns: -

wasadmin@192.168.1.109's password: 
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Last login: Thu Oct 27 13:47:24 2016 from 192.168.1.13


and, from Linux: -

xterm 

which returns this: -

xterm Xt error: Can't open display: 
xterm:  DISPLAY is not set


I did the needful and Google'd to find this: -


which said, in part: -

On MacOS Sierra, I use ssh -Y command , then x11 works, although got a Warning: No xauth data; using fake authentication data for X11 forwarding. client side no ~/.ssh/config file

so I tried this: -

ssh -Y wasadmin@was9001

which returns this: -

wasadmin@192.168.1.109's password: 
Warning: No xauth data; using fake authentication data for X11 forwarding.
Last login: Thu Oct 27 14:16:13 2016 from 192.168.1.13


and: -

xterm 

which JUST WORKS :-)

For the record, I also don't have a config file in ~/.ssh either 

ls -al ~/.ssh/

total 16
drwx------   3 hayd  staff   102  7 Nov  2014 .
drwxr-xr-x+ 42 hayd  staff  1428 27 Oct 13:37 ..
-rw-r--r--   1 hayd  staff  7821 27 Oct 09:33 known_hosts


From the man page for ssh we have: -

     -X      Enables X11 forwarding.  This can also be specified on a per-host basis in a configuration file.

             X11 forwarding should be enabled with caution.  Users with the ability to bypass file permissions on the remote host (for the user's X authorization database) can access the local X11 display through the forwarded connection.  An
             attacker may then be able to perform activities such as keystroke monitoring.

             For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default.  Please refer to the ssh -Y option and the ForwardX11Trusted directive in ssh_config(5) for more information.

     -x      Disables X11 forwarding.

     -Y      Enables trusted X11 forwarding.  Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls.

so I guess that's the difference :-)

2 comments:

Anonymous said...

Love how this stuff comes back around again and again... :-)

In my comment on your blog 3.5 years ago, I was suggesting to use ssh -Y. But you know what? I can't remember why I picked -Y and not -X at the time! Glad it works though :-D

Dave Hay said...

Thanks Stuart, good to hear from you, mate

As you say, it goes round and round and round :-)

Time to play some Dead or Alive :-)

Note to self - use kubectl to query images in a pod or deployment

In both cases, we use JSON ... For a deployment, we can do this: - kubectl get deployment foobar --namespace snafu --output jsonpath="{...