107

Every time I initiate an ssh connection from my Mac to a Linux (Debian) I do get this warning:

No xauth data; using fake authentication data for X11 forwarding.

This also happens for tools that are using ssh, like git or mercurial.

I just want to make a local change to my system in order to prevent this from appearing.

Note: I do have X11 server (XQuartz 2.7.3 (xorg-server 1.12.4)) on my Mac OS X (10.8.1) and it is working properly, I can successfully start clock locally or remotely.

sorin
  • 7,668
  • 24
  • 75
  • 100
  • 1
    What command are you using to ssh? – DerfK Aug 30 '12 at 14:43
  • @DerfK just `ssh hostname` but in my `~/.ssh/config` I added `ForwardX11 yes` some time ago. Still this is something that I do want to have there. – sorin Aug 30 '12 at 14:45
  • Using Ubuntu 16.04 LTS (August 2017) I give up. Bottom line is that even though it gives the error, it works. I use `ssh -Y hostname` from Linux, and `ssh -x hostname` when using OpenSSH on Windows. – SDsolar Aug 31 '17 at 05:55

12 Answers12

118

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.

SebMa
  • 275
  • 1
  • 9
nmgeek
  • 1,281
  • 2
  • 7
  • 4
  • 22
    OMG. Years I’ve been trying to find a solution, and this worked. Years I say! Note that I did this by adding that line under the `Host *` entry in my `~/.ssh/config` file instead of editing `/etc/ssh/ssh_config`. The only documentation I found for this was in `man sshd_config`. – Demitri Jul 10 '17 at 06:07
  • This worked for me as well. I understand that at the moment XQuartz is not being well maintained due to lack of funding. So I think porting issues like this are actually fewer than I would expect. – AlanObject Jul 23 '17 at 17:09
  • On High Sierra; this is the one that worked for me too. – mklein9 Mar 10 '18 at 23:52
  • 2
    Note you may experience this issue _even when your shell can find xauth_ in your PATH! I guess the ssh client is sanitizing your PATH for security reasons? – MarcH May 24 '18 at 15:55
  • 2
    This solution didn't work for me. I'm using Cygwin on Win7. Adding "XAuthLocation /usr/bin/xauth", either under the "Host *" entry, or before that line, in ~/.ssh/config , made no difference. – David M. Karr Jan 24 '19 at 21:22
  • @DavidM.Karr It's not working for me, either. I'm using "terminal" on Ubuntu 16.04. Did you find a solution, Mr. Karr? – Nathan Aug 21 '19 at 07:22
  • This is the correct solution to the real problem in the question. Obviously you can turn the message of by disabling the X11 forwarding, but this is probably not what you want to do. You would have X11 forwarding on in your ssh config for a reason... – thoni56 Dec 04 '19 at 09:29
  • I also had issues to connect from a MacOS to a Linux box. In my case I also had to install `xauth` on the remote host. It was a CentOS box, so `yum -y install xauth` did the trick. – nelsonspbr Feb 10 '21 at 16:58
24

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.

sorin
  • 7,668
  • 24
  • 75
  • 100
  • 19
    I'm not sure why this is needed/relevant. `ForwardAgent` is used to allow keys cached in `ssh-agent` to pass through multiple nested SSH connections. It should not have any relevance to X11. And fwiw, according to some, it's not a good idea security-wise: https://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-considered-harmful/ – underscore_d Sep 24 '15 at 21:08
  • 3
    That does not sound right, what helps is to actually turn off X11 forwarding or fix the xauth configuration to set it up. It is not related to ssh agents. – eckes Sep 22 '17 at 06:42
  • This solution did not work for me. – David M. Karr Jan 24 '19 at 21:23
  • Is this `~/.ssh/config` on the macOS client or the Linux server? I have these files on neither. I do have a similar `/etc/ssh/sshd_config` – Max Coplan Sep 11 '19 at 01:30
  • 2
    On Mac OS, I also had to add "XAuthLocation /opt/X11/bin/xauth" – beOn Oct 16 '20 at 20:25
  • My cause was different. This solved my problem: https://stackoverflow.com/a/44100171/1139559 – fchen Feb 17 '22 at 14:28
21

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)

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
DestinyOne
  • 311
  • 2
  • 5
  • 1
    The question isn't about Windows. – kasperd Sep 22 '17 at 07:53
  • On MacOS it is almost the same, the differences are instead of `Xming`, we should get `XQuartz`, and the `ssh_config` file is in a different location, mine is `/private/etc/ssh`. – DestinyOne Sep 22 '17 at 15:45
  • And also, the last line for `ssh_config` will be: `XAuthLocation /opt/X11/bin/xauth` – DestinyOne Sep 22 '17 at 15:58
  • 2
    Edit needed: `XauthLocaion` -> `XauthLocation` (that edit is too small for me to make). – echristopherson Mar 03 '18 at 04:05
  • 1
    Besides installing `xming`, `ssh`,`xauth`, and `xorg` (step 1), the only thing needed for me was `export DISPLAY=localhost:0` – Eponymous Mar 08 '18 at 03:35
  • Thanks. This helped me quite a bit. My mistake was so simple. The other directions I read way back for windows said to use DISPLAY=:0, but your advice to add localhost fixed my issue. – Tony B Jul 21 '18 at 22:19
  • Setting `DISPLAY=localhost:0` saved me (e.g. I do `DISPLAY=localhost:0 ssh -X host`). I don't really dig what is happening here, but it was the missing piece for me. I am connecting from WSL to an Ubuntu server. There was no need for this dance for connecting from Arch to Arch. – Vladislav Ivanishin Apr 20 '20 at 21:04
  • xauth add :0 . `mcookie` (From: https://stackoverflow.com/a/44100171/1139559) – fchen Feb 17 '22 at 14:29
14

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
guest
  • 141
  • 1
  • 2
  • 1
    I tested the same lines on OS X 10.11, and I do not get any error. Still same version of XQuartz. – sorin Mar 01 '16 at 11:48
  • 2
    @guest Your `xauth generate $DISPLAY .` command worked on my Mac OS X High Sierra (10.13), and it solved my `No xauth data; using fake authentication data for X11 forwarding.` pb. – SebMa Aug 10 '18 at 16:13
  • 1
    This isn't just OS X specific - running `xauth generate :0` made the warning disappear on my WSL/Debian client. – sandyscott May 11 '20 at 20:56
  • @sandyscott I use wsl2 with Debian and wanted the linux [gui apps on windows 11](https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps), but I probably made the mistake to use debian instead of ubuntu. So maybe `wsl --update` was the bad guy. Now I want to revert to not get the warning the OP has which is annoying. – Timo Apr 08 '22 at 19:53
3

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
clearlight
  • 153
  • 5
ssanch
  • 131
  • 1
  • Not sure if this would really work because xauth location would be different on each remote machine. Yours looks like a MacOS one, but Linux has it in different location. I mostly started to disable ForwardX11 completly because I almost never user it. – sorin Feb 23 '19 at 08:23
  • @sorin maybe he updated the question because he explains how to find the right location in the answer. BTW: This works for me! – clearlight Nov 28 '19 at 12:18
2

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. :-)

Red Tux
  • 2,074
  • 13
  • 14
  • I doubt this would solve the error in GUI OS X apps, like SourceTree. – sorin Mar 01 '16 at 11:49
  • Confirming it does work on Sierra for running emacs using X - as the Mac is the server. this should work broadly in cases where the client is on a remote machine – Mark Mullin Dec 18 '16 at 16:24
2

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

Marcel Kraan
  • 17
  • 1
  • I can confirm this is an answer on Mac OS Sierra 10.12.4. **Removing ~/.Xauthority** on SSH server does the trick: `~$ mv ~/.Xauthority ~/.Xauthority.bak` A new magic cookie was automatically put back in ~/.Xauthority once I logged in again. No Bash scripting is required at all. – Kenneth Pegasus May 31 '17 at 23:45
2

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).

Kepler Oliveira Filho
  • 21
  • 1
2

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.

Irfy
  • 123
  • 4
  • This is the only one that worked for me! I'd just like to add that the command didn't work at first try for me, I was getting a `.../.Xauthority does not exist` error. To fix it I simply had to create an empty file using `touch .Xauthority` in my home folder, and then re-run the above `xauth` command again. – Tropilio Mar 26 '20 at 09:58
  • I did have an existing `~/.Xauthority` file from tinkering around trying to find the solution, thanks for letting me know it's essential! – Irfy Apr 11 '20 at 20:27
1

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 .

all-informatic
  • 11
  • 1
1

My goal was get quiet ssh-based command line login t Linux hosts from my macOS client. E.g. I didn't want to see any banners or messages. Just setup cert-based login so I could type an alias at the and get a prompt on the host machine. To accomplish that I did the following:

  • On the Debian 10 Linux host I touched (e.g. created) ~/.hushlogin

  • However, on macOS Catalina ssh client I was getting the message:

    No xauth data; using fake authentication data for X11 forwarding.

After confirming xauth binary location, I addedXAuthLocation /opt/X11/bin/xauth to /etc/ssh/sshd_config on the macOS client, but that did not work for me when I used this command:

ssh -Y user@debian10

In the final analysis @ssanch's answer did work for me. But before I discovered that solution I stumbled on a workaround that might help some people:

ssh -Yy user@host

Adding lowercase -y flag to the ssh command line causes it to send it's log output to syslog instead of stderr, and that allows for the desired quiet login also.

clearlight
  • 153
  • 5
0

For anyone having the same trouble, I've tested all the other answers, nothing worked for me: launch xterm by ssh from local Windows 10 to Linux Debian 10 buster remote box.

The way worked for me is

  1. Install Xming.exe under Windows and run it,

  2. Then under Windows using PowerShell:

    $env:DISPLAY="localhost:0"
ssh.exe -Y user@example.com

    instead of ssh.exe -X user@example.com.

$env:DISPLAY is mandatory. Shell environment variable $DISPLAY is automatically set by xauth or similar.

I've reported the detail on stackoverflow.

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
jacouh
  • 101
  • 3