None of the posted solutions worked for me. My client (desktop) system is running macOS 10.12.5 (Sierra). I added -v to the options for the ssh command and it told me,

debug1: No xauth program.

which means it doesn't have a correct path to the xauth program. (On this version of macOS the path to xauth is nonstandard.) The solution was to add this line to /etc/ssh/ssh_config (may be /etc/ssh/config in some setups) or in ~/.ssh/config (if you don't have admin rights):

XAuthLocation /opt/X11/bin/xauth

Now the warning message is gone.

Found the cause, my ~/.ssh/config was incomplete, you need both:

Host *
    ForwardAgent yes
    ForwardX11 yes

My mistake was that I included only the ForwardX11 option.

Letting Ubuntu bash on Windows 10 run ssh -X to get a GUI environment on a remote server

• First

Install all the following. On Window, install Xming. On Ubuntu bash, use sudo apt install to install ssh xauth xorg.

sudo apt install ssh xauth xorg

• Second

Go to the folder contains ssh_config file, mine is /etc/ssh.

• Third

Edit ssh_config as administrator(USE sudo). Inside ssh_config, remove the hash # in the lines ForwardAgent, ForwardX11, ForwardX11Trusted, and set the corresponding arguments to yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes

• Forth

In ssh_config file, remove the front hash # before Port 22 and Protocol 2, and also append a new line at the end of the file to state the xauth file location, XauthLocation /usr/bin/xauth, remember write your own path of xauth file.

# /etc/ssh/ssh_config

#   IdentifyFile ...
    Port 22
    Protocol 2
#   Cipher 3des
#   ...
#   ...
    ...
    ...
    GSSAPIDelegateCredentials no
    XauthLocation /usr/bin/xauth

• Fifth

Now since we are done editing ssh_config file, save it when we leave the editor. Now go to folder ~ or $HOME, append export DISPLAY=localhost:0 to your .bashrc file and save it.

# ~/.bashrc
...
...
export DISPLAY=localhost:0

• Last

We are almost done. Restart your bash shell, open your Xming program and use ssh -X yourusername@yourhost. Then enjoy the GUI environment.

ssh -X yourusername@yourhost

The problem is also in Ubuntu subsystem on Windows, and the link is at

https://gist.github.com/DestinyOne/f236f71b9cdecd349507dfe90ebae776

Note: the linked text includes 2 typos (XauthLocaion instead of XauthLocation)

As noted, it seems that xauth on OS X Yosemite has regressed to an old version that doesn't work with XQuartz's $DISPLAY setting:

% xauth -V
1.0.9
% xauth generate $DISPLAY .
xauth: (argv):1:  bad display name "/private/tmp/com.apple.launchd(...)/org.macosforge.xquartz:0" in "add" command

I would add this as a comment, but I don't have enough rep. Adding one more line to sorin's solution worked for me.

On the client machine, edit your ssh config file with vim ~/.ssh/config

Then add these lines to it:

Host *
    ForwardAgent yes
    ForwardX11 yes
    XAuthLocation /opt/X11/bin/xauth

You can double check your xauth location with:

which xauth

There is a bug in MacOS at the moment. I came across this too. The fix for me involved adding the following to my .bash_profile

dispdir=`dirname $DISPLAY`
dispfile=`basename $DISPLAY`
dispnew="$dispdir/:0"
if [ -e $DISPLAY -a "$dispfile" = "org.x:0" ]; then
  mv $DISPLAY $dispnew
fi
export DISPLAY=$dispnew

Essentially the name for the file pipe associated with your X root can't be handled correctly, and thus needs correction. :-)

i just removed ~/.Xauthority (destination machine) from my root folder and ssh -X 192.168.123.1 again and ik worked.

Including

XAuthLocation /opt/local/bin/xauth in ~/.ssh/config

in my macOS Sierra 10.12.6 worked for me. A small change from answer 7).

This started happening to me after moving my Cygwin installation from one PC to another. The issue seemed to be the hostname change: the magic cookie no longer corresponded to the hostname of the new PC.

Running

touch ~/.Xauthority
xauth add :0 . `mcookie`

on the local Cygwin installation fixed the problem for me -- xauth list now listed a magic cookie associated with the correct hostname of the new PC, and the warning stopped appearing.

In my case it was the problem of .Xauthority containing the Magic cookie not forwarded, Fabby on http://askubuntu.com/questions/571116/ recommends on 2014-11-14 to add this line at the end of the .bashrc or . profile to allow forwarding of xauth keys between users when calling su:

export $(dbus-launch)

I added also previously:

export XAUTHORITY=~/.Xauthority 

to ensure remote called with ssh -X ̍@ will find it.

In my case .Xauthority is a symlink to original user /home//.Xauthority I su from...

  cd /home/<child_user>;ln -sf /home/<parent_user>/.Xauthority .xAuthority

with correct rights:

  sudo chown <parent_user> /home/<parent_user>/.profile
  chmod a+rw /home/<parent_user>/.profile 

so it is accessible to and to . will be able to trigger apps on and display X-windowed result on its local screen throughout proxy account !

TIP : Check xauth list...if reflects magic cookie on .