39

When I ssh into a remote server that's not running any type of X11 desktop environment I get the following message.

$ ssh user@server
X11 forwarding request failed

$ ssh user@server ls
X11 forwarding request failed on channel 1
file1
file2
...

How can I get rid of these messages?

Improve this question

10 Answers 10

Reset to default
46

These messages can be eliminated through 1 of 3 methods, using just SSH options. You can always send messages to /dev/null too but these methods try to deal with the message through configuration, rather than just trapping and dumping them.

Method #1 - install xauth

The server you're remoting into is complaining that it cannot create an entry in the user's .Xauthority file, because xauth is not installed. So you can install it on each server to get rid of this annoying message.

On Fedora 19 you install xauth like so:

$ sudo yum install xorg-x11-xauth

If you then attempt to ssh into the server you'll see a message that an entry is being created in the user's .Xauthority file.

$ ssh root@server
/usr/bin/xauth:  creating new authority file /root/.Xauthority
$

Subsequent logins will no longer show this message.

Method #2 - disable it via ForwardX11

You can instruct the ssh client to not attempt to enable X11 forwarding by inclusion of the SSH parameter ForwardX11.

$ ssh -o ForwardX11=no root@server

You can do the same thing with the -x switch:

$ ssh -x root@server

This will only temporarily disable this message, but is a good option if you're not able to or unwilling to install xauth on the remote server.

Method #3 - disable it via sshd_config

This is typically the default but in case it isn't, you can setup your sshd server so that X11Forwarding is off, in /etc/ssh/sshd_config.

X11Forwarding no

Of the 3 methods I generally use #2, because I'll often want X11Forwarding on for most of my servers, but then don't want to see the X11.... warnings

$HOME/.ssh/config

Much of the time these message won't even show up. They're usually only present when you have the following entries in your $HOME/.ssh/config file, at the top.

ServerAliveInterval 15
ForwardX11 yes
ForwardAgent yes
ForwardX11Trusted yes

GatewayPorts yes

So it's this setup, which is ultimately driving the generation of those X11.. messages, so again, method #2 would seem to be the most appropriate if you want to operate with ForwardX11 yes on by default, but then selectively disable it for certain connections from the ssh client's perspective.

Security

It's generally ill-advised to run with ForwardX11 yes on at all times. So if you're wanting to operate your SSH connections in the most secure manor possible, it's best to do the following:

  1. Don't include ForwardX11 yes in your $HOME/.ssh/config file
  2. Only use ForwardingX11 when you need to via ssh -X user@server
  3. If you can, disable X11Forwarding completely on the server so it's disallowed

References

Improve this answer
2
  • Can you help me with unix.stackexchange.com/questions/470331/…?
    – overexchange
    Commented Sep 20, 2018 at 17:44
  • For the record, I received that message when I was trying to run X clients on the remote server. They wouldn't launch because $DISPLAY was not set. I managed to fix it with your first suggestion: install xauth.
    – Tom Ellis
    Commented May 17, 2019 at 11:00
18

Ran across this today and beat my head for a while until I stumbled across an ssh setting:

If it's RHEL 7 (centOS, OEL, etc), and it has ipv6 disabled, it needs:

AddressFamily inet

set in /etc/ssh/sshd_config.

Improve this answer
3
  • if only the error message related to this...
    – Jack Wasey
    Commented Aug 2, 2018 at 20:51
  • 2
    you know what's funny? I ran into this today and googled it, found this article, and found my own comment from four years ago and said "OH YEAH THAT'S THE PROBLEM."
    – Systemspoet
    Commented Jul 25, 2019 at 20:03
  • This was the solution in debian 10.
    – isaaclw
    Commented Mar 13, 2020 at 19:00
15

In my case adding this string to /etc/ssh/sshd_config solved the problem:

X11UseLocalhost no
Improve this answer
2
  • This worked for me (the server already had xauth installed). Thanks.
    – Paul Higgins
    Commented Aug 27, 2015 at 16:30
  • 2
    This appeared to solve my issue, but I don't understand why, which is concerning. I have what should be three identical Debian 7 machines, one of which suddenly stopped accepting locahost X11 forwarding. X11 forwarding on the other two still works. Any idea what could have changed?
    – Kyle Strand
    Commented Oct 28, 2016 at 18:27
4

If running the client in verbose mode (ssh -v user@host) gives you

debug1: Remote: No xauth program; cannot forward with spoofing.

but xauth is indeed installed on the server, then it is probably because sshd looks for xauth executable in wrong location (/usr/X11R6/bin/xauth usually). One can fix that by setting

XAuthLocation /usr/bin/xauth

in /etc/sshd/sshd_config (or whatever your server is configured with).

Improve this answer
2
  • This worked for me on CentOS 7. That's the exact error message I was seeing.
    – Brian Minton
    Commented Apr 6, 2017 at 16:07
  • This was my problem, trying to log in remotely to a Mac. There the correct incantation was XAuthLocation /opt/X11/bin/xauth
    – Leon Avery
    Commented May 30, 2018 at 22:36
2

Another slight variation would be if you wanted to stop seeing this message (i.e. stop trying to forward X11) for certain servers but yet keep the default to ForwardX11 yes for all other connections.

For this scenario, you could disable X11 forwarding for a specific host (or range) in your ~/.ssh/config. Something like this:

host 10.1.1.*
ForwardX11 no

Acknowledgment: This is a slight embellishment to the existing (and very complete) existing answer - since I couldn't comment!

Improve this answer
2

Configuring X11 forwarding on a per host basis

In addition to all of the excellent answers already here, you can configure ForwardX11 on a per host basis, so if only server fails like this, you can add an entry to your ~/.ssh/config file of the following form:

Host server server.domain.dom
    ForwardX11 no

You can even use entries like this as alliases for whole sets of configurations

Host my.server
    HostName server.domain.dom
    User user
    Port 1234
    ForwardX11 no

This is especially useful if you have set up Autocomplete server names for SSH and SCP.

Improve this answer
2

I came across this question after a run in with an sshd-xauth bug nearly a decade old. Two solutions are reported, the first bypassing xauth, the second addressing the bug.

Solution 1 - bypass xauth

  • local -- the local machine serving an Xserver.
  • remote -- the remote machine serving the application which drives the data going to the Xserver

Remote /etc/ssh/sshd_config:

X11Forwarding no
X11DisplayOffset 10
X11UseLocalhost yes

Remote ~/.Xauthority is empty or does not exist

On local:

Xephyr -ac -screen 1280x800 -br -reset   :2 &
DISPLAY=:2 ssh  -fR 6010:/tmp/.X11-unix/X2  user@remote "DISPLAY=:10 xeyes"

In the test, local was running Ubuntu 18.05, remote was running Debian Jesse.

I also posted this solution as an answer another question.

Solution 2 - address the sshd/xauth bug

This solution is close to @systempoet 's solution above, although that alone was not enough.

In addition to modifying /etc/ssh/sshd_config on remote:

AddressFamily inet

/etc/hosts on remote was also modifed:

::1     localhost ip6-localhost ip6-loopback

If either were commented out, the error message 

X11 forwarding request failed on channel 0

appeared after the ssh -X ... call. In addition the /var/log/auth.log showed the error:

sshd[...]: error: Failed to allocate internet-domain X11 display socket

Test to produce the bug (before fix):

Local machine:

$ Xephyr -ac -screen 1280x800 -br -reset -terminate  :2 &
$ DISPLAY=:2 ssh -X  user@remote
X11 forwarding request failed on channel 0
Improve this answer
0

One important point to note after making the configuration changes is that you'll have to kill sshd so that it picks up the changes:

cat /var/run/sshd.pid | xargs kill -1

being the root user.

Improve this answer
0

For those who have IPv6 disabled through /etc/sysctl.conf, try using the boot option disable.ipv6=1 instead.

The strange interaction with IPv6 seems to be a bug in OpenSSH: https://bugzilla.mindrot.org/show_bug.cgi?id=2143. Related Debian bug reports: https://bugs.debian.org/422327, https://bugs.debian.org/595014.

Improve this answer
-2

  1. Set the following 2 options in /etc/ssh/sshd_config in your RHEL host

    X11Forwarding yes X11UseLocalhost no

  2. sudo /etc/init.d/sshd reload

  3. sudo yum install xauth
  4. ssh back to your RHEL host with -X switch: ssh -X yourname@rhelbox
Improve this answer

You must log in to answer this question.

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