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
    May 26 '11 at 9:17
  • sudo apt-get install xauth tells me "xauth is already the newest version" May 26 '11 at 19:00
  • When logged in on the ubuntu server, what is the output of 'which xauth' ?
    – slubman
    May 26 '11 at 19:50
  • Indeed I think you should read this explanation: mail-archive.com/cygwin-xfree@cygwin.com/msg17927.html … you can ignore this warning
    – slubman
    May 26 '11 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
    Aug 22 '12 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. Feb 2 '12 at 1:44
  • is there any case when you wouldnt want to use -Y instead of -X ?
    – Rooster
    Jul 3 '15 at 19:06
  • @Rooster for very old systems where -Y isn't supported I would say
    – Petr
    Jan 15 '16 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. Apr 11 '17 at 21:21
  • 3
    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. Dec 19 '18 at 10:02

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
    Aug 7 '15 at 4:57
  • Worth noting that brew install xquartz presently installs the out of date 2.7.7 version. Jan 9 '16 at 23:03
  • brew install Caskroom/cask/xquartz should get you the latest XQuartz with HomeBrew
    – Nick
    Jun 10 '17 at 22:49
  • Or shorter brew cask install xquartz. Sep 28 '18 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
    Aug 26 '20 at 17:21

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.


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


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


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.

  • One can use ssh -Y to do trusted X11 forwarding but how can one fix the untrusted one? Oct 1 '15 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 Apr 18 '18 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`


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.