When I use ssh -X on my Mac (running OS X 10.6.7) to connect to my Ubuntu (11.04) box, I get the following warning:

Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding.

Is there something I can do to make this warning go away? If not, can I safely ignore it?

X11 forwarding seems to work fine, though I do see this message:

Xlib: extension "RANDR" missing on display "localhost:10.0".

Is that related to the warning? (I'm guessing not. If it's not, I'll file a new question about that.)

  • 1
    IS the xauth program installed on the ubuntu server ?
    – slubman
    Commented May 26, 2011 at 9:17
  • 1
    sudo apt-get install xauth tells me "xauth is already the newest version" Commented May 26, 2011 at 19:00
  • When logged in on the ubuntu server, what is the output of 'which xauth' ?
    – slubman
    Commented May 26, 2011 at 19:50
  • Indeed I think you should read this explanation: mail-archive.com/[email protected]/msg17927.html … you can ignore this warning
    – slubman
    Commented May 26, 2011 at 20:00
  • 2
    occasionally this can be caused by issues w/ your ~/.Xauthority file. If you delete it, it will be re-created the next time you attempt to login.
    – michael
    Commented Aug 22, 2012 at 4:15

12 Answers 12


Try ssh -Y

Any reason you don't want to use the -Y flag instead of the -X flag?

Quite simply, the difference between -X and -Y is that -Y enables trusted X11 forwarding.

  • 4
    No, I just wasn't aware of the -Y flag when I wrote the question. I believe that did turn out to be a solution. Change your answer so it's not a question (and it would be nice if you briefly explained the difference between -Y and -C) and I'll accept it. Commented Feb 2, 2012 at 1:44
  • is there any case when you wouldnt want to use -Y instead of -X ?
    – Rooster
    Commented Jul 3, 2015 at 19:06
  • @Rooster for very old systems where -Y isn't supported I would say
    – Petr
    Commented Jan 15, 2016 at 7:53
  • Troubleshooting tip: Run "ssh -vv ..." and look for the xauth line and any error messages. You can try running the xauth line it shows directly. For mine I needed it to be something like "xauth list :0" (trusted) not "xauth -f /tmp/ssh... list :0" (untrusted). Which -Y fixed and "ForwardX11Trusted yes" in remote host /etc/ssh/ssh_config (or ~/.ssh/config) also fixed. Commented Apr 11, 2017 at 21:21
  • 5
    Note -Y does not make your connection trusted or more trusted. Rather, it requires it to be trusted before you use the option. -Y makes ssh drop some tampering protection that it will provide when you use -X. Commented Dec 19, 2018 at 10:02

BEWARE (tired of reading incomplete answers which lead to security flaw)

  1. using ssh -Y means here having fake xauth information which is bad!

  2. ssh -X should work since XQuartz, once enabled, uses xauth. The only problem is that ssh is looking for xauth in /usr/X11R6/bin and on macos with XQuartz it is in /opt/X11/bin

Secure solving:

  1. Enable the first option in Security tab of preferences (Cmd-,) which enables authenticated connections

  2. add the following to $HOME/.ssh/config

    XAuthLocation /opt/X11/bin/xauth

  3. ssh -X you_server works in a secure maner

  • Works for me today with macOS Big Sur 11.6, xquartz 2.8.1 installed through homebrew. Thanks!
    – dokkaebi
    Commented Sep 29, 2021 at 21:03
  • I have my home directory in a git repository so I don't want to add it to my $HOME/.ssh/config. I've been adding it to /etc/ssh/ssh_config but with each update it gets clobbered. I discovered etc/ssh/ssh_config.d which is empty. I added a file and put this line in that file. It works. I hope it doesn't get clobbered with an update.
    – pedz
    Commented Aug 18, 2022 at 13:07

If you're coming here in 2015: even if everything else is set up properly, this can also happen on Mac OS X 10.10 Yosemite, when using ssh -X and running an XQuartz version <= 2.7.7. The root cause is X11 display sockets getting written outside of the xauth search path: issue #2068 in the XQuartz tracker.

Edit: A fixed XQuartz has since been released at the new homepage, xquartz.org, and installing the latest version from there (currently 2.7.9) will work around the issue.

  • 1
    Thank you! I had no idea that the XQuartz I just downloaded from the top of the XQuartz page is not actually the latest release.
    – craigds
    Commented Aug 7, 2015 at 4:57
  • Worth noting that brew install xquartz presently installs the out of date 2.7.7 version. Commented Jan 9, 2016 at 23:03
  • brew install Caskroom/cask/xquartz should get you the latest XQuartz with HomeBrew
    – Nick
    Commented Jun 10, 2017 at 22:49
  • Or shorter brew cask install xquartz. Commented Sep 28, 2018 at 13:27
  • omg finally after 5 years I'm back wtih a new version of XQuartz! they said they'd never update it... why Apple doesn't pay it the respect it deserves is beyond me.
    – Tomachi
    Commented Aug 26, 2020 at 17:21

"Untrusted" in this context means you don't trust the connection. SSH will use additional security measures to try to make X11 forwarding safer. "Trusted" means you are entirely confident that no on on the remote host will get access to your Xauth data and use it to monitor your keystrokes for instance.

This terminology actually confused me for years. I thought "Trusted" connections were safer. But actually it's an option you're supposed to use in situations where the connection IS trustworthy and you want to run stuff without extra security measures getting in your way. "Untrusted" is the one that makes it (somewhat) safer to deal with an untrusted remote host.

An "Untrusted" connection attempts to limit what a black hat could do to you by engaging the X11 security extension and disabling other extensions that you (hopefully) don't need. This is probably why RandR is disabled with -X. Do you need to be able to rotate your X display from the remote host?

It's also important to note that "untrusted" X11 forwarding turns off after a certain amount of time to keep you from accidentally leaving it on. New attempts to open windows will just fail after that. That bit me several times before I read enough docs to understand what was happening.


If you get the same message even when using -Y, the xauth program might be missing on the server. On Debian-like systems, you need the xauth package. On RedHat-like systems, you need the xorg-x11-xauth package.


Rule out server-side problems

First, you should rule out any server-side problems. Are you able to ssh -X from any other host successfully? Does ssh -Y work while ssh -X doesn't? In either case, assume ssh + X11 is set up correctly on your server and move on to the next section.

If you aren't in a position to check that (you have but your one laptop running X11, say), you can ssh from the server to itself using a fake session:

  1. export DISPLAY=:44 # (Bourne shell) or
    setenv DISPLAY :44 # (csh / tcsh)
  2. xauth add $DISPLAY MIT-MAGIC-COOKIE-1 1234 # Bogus cookie just for this test
  3. ssh -X localhost env |grep DISPLAY

Expected result: there should be a DISPLAY variable set on the remote end of the ssh-to-self session. If you get no result, your server is likely mis-configured (e.g. the X11 libraries and/or the xauth command could be missing; or the sshd configuration could be set to deny X11 access)

On Mac: check that Xquartz is up-to-date

As per Will Angley's answer

Examine ssh -vv -X output

The error message you cite is a symptom that can have many causes. Try again with ssh -X -vv remotehost, which should give you additional clues as to why the X11 tunnel setup failed.

Do you see the following message appearing?

debug1: No xauth program.
If so,

  1. Take note of where on your client system, the xauth command resides:
    which xauth
  2. Add the following at the very end of your ~/.ssh/config (and add a comment to remind yourself to keep it there in the future):
    Host *
        XAuthLocation /opt/X11/bin/xauth
    Adjust this path as per findings of step 1 — Credits to Jan-Willem Arnold

I don't have a setup that can exhibit this behavior, so this is a shot in the dark:

The warning might be suppressed if you set ForwardX11Trusted to "no" for hosts that give this warning. You can place this in either ~/.ssh/config or /etc/ssh/ssh_config, and you can make the option specific to a particular host by including Host <hostname> on the line above. the <hostname> component matches what you type on the command line (not the resolved hostname), and it can include wildcards.

  • 1
    One can use ssh -Y to do trusted X11 forwarding but how can one fix the untrusted one? Commented Oct 1, 2015 at 12:45
  • I got the same error in Redhat and now I'm able to solve it by editing the config file /etc/ssh/ssh_config at client side. Thank you Commented Apr 18, 2018 at 15:25

If installing xauth does not work right, one particularly annoying case could be a corrupted .Xauthority file. This particular case allowed some X clients to work, but not others with a greater tendency to fail with newer displays. Removing and recreating the .Xauthority file can solve that problem.


As has already been explained above, the following worked for me:

Edit ~/.ssh/config to add the lines

Host *
    XAuthLocation /opt/X11/bin/xauth

and now ssh -X hostname works (XQuartz 2.7.11, macOS 10.4 Mojave)


Using XQuartz 2.7.11 on MacOS Catalina, I had to update my /etc/ssh/ssh_config file and add XAuthLocation /opt/X11/bin/xauth after Host * for ssh -X to work


I already had the latest XQuartz 2.7.11 installed, but I think I've also updated the OS a few times since then. I reinstalled XQuartz 2.7.11, and now it is working fine.


xauth add `hostname`/unix:10 MIT-MAGIC-COOKIE-1 `openssl rand -hex 16`

  • 1
    I don't understand ... Commented Jun 11, 2016 at 6:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .