What does "Warning: untrusted X11 forwarding setup failed: xauth key data not generated" mean when ssh'ing with -X?

Question

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

`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: http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg17927.html … you can ignore this warning — slubman, May 26 '11 at 20:00
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 04:15

score 193 · Accepted Answer · edited May 25 '21 at 12:36

193

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.

edited May 25 '21 at 12:36

StackzOfZtuff

1,754
12
21

answered Feb 01 '12 at 22:02

user5336

2,369
1
15
9

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 02 '12 at 01:44
is there any case when you wouldnt want to use -Y instead of -X ? – Rooster Jul 03 '15 at 19:06
@Rooster for very old systems where -Y isn't supported I would say – Petr Jan 15 '16 at 07: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
4

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`. – Lutz Prechelt Dec 19 '18 at 10:02
Two factor auth administered by linux side, with client side macbook seems to suddenly require `-Y` wheras in the past, either by cheese shoppian edict from apple HQ devs: before, and without two factor auth, `-X` works fine and without warning. – Eric Leschinski Feb 25 '19 at 19:05

score 34 · Answer 2 · edited Jun 11 '20 at 10:02

34

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

using ssh -Y means here having fake xauth information which is bad!
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:

Enable the first option in Security tab of preferences (Cmd-,) which enables authenticated connections
add the following to $HOME/.ssh/config

XAuthLocation /opt/X11/bin/xauth
ssh -X you_server works in a secure maner

edited Jun 11 '20 at 10:02

Community

1

answered Jan 31 '18 at 13:16

Koko

441
4
2

Works for me today with macOS Big Sur 11.6, xquartz 2.8.1 installed through homebrew. Thanks! – dokkaebi Sep 29 '21 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 Aug 18 '22 at 13:07

Will Angley · Answer 3 · 2016-08-29T22:09:18.687

25

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.

edited Aug 29 '16 at 22:09

answered May 13 '15 at 15:09

Will Angley

351
3
5

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 07 '15 at 04:57
Worth noting that `brew install xquartz` presently installs the out of date 2.7.7 version. – Martin Cleaver Jan 09 '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
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
I'm coming here from 2021, I implore you: get off the planet! 2021 Earth is crazy, friend. – aggregate1166877 Apr 29 '21 at 04:37

score 18 · Answer 4 · edited Jan 27 '18 at 10:57

18

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.

edited Jan 27 '18 at 10:57

Kuba hasn't forgotten Monica

237
1
13

answered Jul 17 '13 at 08:35

Flup

7,688
1
31
43

score 18 · Answer 5 · answered Feb 17 '16 at 17:36

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

DomQ · Answer 6 · 2017-09-01T09:06:41.740

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:

export DISPLAY=:44 # (Bourne shell) or
setenv DISPLAY :44 # (csh / tcsh)
xauth add $DISPLAY MIT-MAGIC-COOKIE-1 1234 # Bogus cookie just for this test
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,

Take note of where on your client system, the xauth command resides:
```
which xauth
```
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

score 9 · Answer 7 · answered Jun 13 '11 at 20:03

9

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.

answered Jun 13 '11 at 20:03

Michael Lowman

3,584
19
36

One can use `ssh -Y` to do trusted X11 forwarding but how can one fix the untrusted one? – Pavel Šimerda Oct 01 '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 – Buddybear Apr 18 '18 at 15:25

score 6 · Answer 8 · edited Oct 18 '16 at 12:43

6

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.

edited Oct 18 '16 at 12:43

kenorb

5,943
1
44
53

answered Aug 01 '14 at 17:43

hildred

216
1
3
8

score 6 · Answer 9 · answered Nov 08 '18 at 17:12

6

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)

answered Nov 08 '18 at 17:12

shepster

61
1
1

score 1 · Answer 10 · answered Nov 12 '20 at 20:12

1

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

answered Nov 12 '20 at 20:12

EdoBarroso

11
1

score 0 · Answer 11 · answered Apr 01 '17 at 12:52

0

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.

answered Apr 01 '17 at 12:52

Ulmo

11

Marc Williams · Answer 12 · 2016-06-11T05:31:40.783

-3

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

edited Jun 11 '16 at 05:31

answered Jun 11 '16 at 04:27

Marc Williams

1
1

1

I don't understand ... – Pierre.Vriens Jun 11 '16 at 06:59

What does "Warning: untrusted X11 forwarding setup failed: xauth key data not generated" mean when ssh'ing with -X?

12 Answers12

Try ssh -Y

Rule out server-side problems

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

Examine `ssh -vv -X` output

Related

What does "Warning: untrusted X11 forwarding setup failed: xauth key data not generated" mean when ssh'ing with -X?

12 Answers12

Try ssh -Y

Rule out server-side problems

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

Examine ssh -vv -X output

Related

Examine `ssh -vv -X` output