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" – Daryl Spitzer 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

11 Answers 11


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.

| improve this answer | |
  • 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. – Daryl Spitzer 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. – Curtis Yallop Apr 11 '17 at 21:21
  • This solution also worked with Cygwin/X. – linux64kb Feb 14 '18 at 20:34

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.

| improve this answer | |
  • 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. – Martin Cleaver 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. – Franklin Yu Sep 28 '18 at 13:27

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.

| improve this answer | |

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

| improve this answer | |

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

| improve this answer | |

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.

| improve this answer | |
  • One can use ssh -Y to do trusted X11 forwarding but how can one fix the untrusted one? – Pavel Šimerda 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 – Gangadhar Jannu Apr 18 '18 at 15:25

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
| improve this answer | |

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.

| improve this answer | |

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)

| improve this answer | |

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.

| improve this answer | |

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

| improve this answer | |

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.