I have a gateway to ssh into from the bad world wide web. No problem, I get:

remote ~$ ssh -X ingo@gateway
Debian GNU/Linux 10 (buster)
0:ingo@gateway ~$

Now I manage my other hosts, for example the fileserver:

0:ingo@gateway ~$ ssh -X ingo@fileserver
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Debian GNU/Linux 10 (buster)

I get that Warning.

But if I ssh from my management host on the local network direct into the fileserver, it works without the Warning. I have verified this with other logins. I only get the Warning when ssh from a ssh.

Why do I get
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
only on nested ssh logins?

How can I avoid this warning and can successful use the more secure untrusted X11 forwarding?

And no, I do not want to use the less secure -Y option on ssh for trusted X11 forwarding instead of the used -X option.

  • You should either use trusted X11 forwarding for the 1st forwarding, or use the intermediate host(s) as jump host(s) via the -J option. Otherwise it will not work. I'm sorry if you don't like it.
    – user313992
    Apr 3, 2020 at 22:18

1 Answer 1


When your only connection to an X11 server is untrusted, you cannot forward it further.

The untrusted X11 forwarding works by the ssh client connecting to the local display, and using the xauth generate $DISPLAY . untrusted command to generate an untrusted key / cookie.

But for that, the xauth command needs the SECURITY extension to be present on the display, which, like most extensions is hidden and/or disabled when a client like xauth was authenticated with an untrusted cookie.

You can easily check that with:

$ touch /tmp/junk1 /tmp/junk2
$ chmod 600 /tmp/junk*
$ xauth -f /tmp/junk1 generate :0 . untrusted
$ XAUTHORITY=/tmp/junk1 oclock
   # get a square oclock because the Shape extension is disabled
$ XAUTHORITY=/tmp/junk1 xdpyinfo | grep -A2 extensions
number of extensions:    2
   # vs 28 or so on a trusted display
$ XAUTHORITY=/tmp/junk1 xauth -f /tmp/junk2 generate :0 . untrusted
xauth: (argv):1:  couldn't query Security extension on display ":0"

The latter step will cause the warning you get in ssh.

So at least the first X11 forwarding should be trusted, otherwise it would not work.

Alternatively, you should "jump" through the intermediate host, which will do a single X11 forwarding:

ssh -X -o ForwardX11Trusted=no -J ingo@gateway ingo@fileserver

Notice that explicit ForwardX11Trusted=no, because on Debian, the -X and -Y options are equivalent, and you'll get a trusted X11 forwarding by default no matter which one you're using.

You must log in to answer this question.

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