SSH XForwarding fails - xauth bad display name

Question

I'm trying to setup XForwarding over ssh, but it fails. The same result happens whether I use the argument -X or -Y for ssh. The error I get.

a@ASUS-N53SM:~$ ssh -X -p 6623 [email protected]
[email protected]'s password: 
Last login: Sun Feb  2 18:42:08 2014 from 192.168.0.201
/usr/bin/xauth: (stdin):1:  bad display name "pinker-server:10.0" in "remove" command
/usr/bin/xauth: (stdin):2:  bad display name "pinker-server:10.0" in "add" command
xdpyinfo:  unable to open display "pinker-server:10.0".

In the client file ~/.ssh/config

ForwardX11 yes

In the client file /etc/ssh/ssh_config (comments removed).

Host *
ForwardX11 yes
ForwardX11Trusted yes
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes 
GSSAPIDelegateCredentials no

In the server file /etc/ssh/sshd_config (comments removed).

Port 6623
Port 6624
Port 6625
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
X11UseLocalhost no
AllowTcpForwarding yes

I found this similar Question, but none of the answers work.

UPDATE:

On the server, I added to the file /etc/hosts.

127.0.0.1       pinker-server

On the server, I installed the package xbase-clients. On the ssh connection echo $DISPLAY outputs :0.0.

Now I'm getting a new error.

X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
xdpyinfo:  unable to open display "pinker-server:10.0".

Solution 1

This error occurs when the remote machine doesn't know it's own hostname, or has an incorrect hostname associated with 127.0.1.1 (NOTE: Not 127.0.0.1 which should always resolve to localhost).

To correct it, ensure that the entry in /etc/hosts for 127.0.1.1 matches the machine's FQDN and short hostname.

Solution 2

On the remote machine, edit the file /etc/ssh/sshd_config. Change X11UseLocalhost to yes.

Source http://www.pclinuxos.com/forum/index.php?topic=109487.0

Solution 3

Any time I run into an SSH issue I almost immediately re-run the command with more verbose messaging enabled. I like to use this technique to collect the log file on the server I'm running ssh from. If you need to get more details simply add more -v switches (the maximum is 3).

$ ssh -v user@remoteserver |& tee /path/to/sshv1.log
-or-
$ ssh -vv user@remoteserver |& tee /path/to/sshv2.log

X11 connection rejected because of wrong authentication.

This message is almost always indicative of a permissions problem with your .Xauthority file. You can either move the existing one out of the way temporarily or attempt to fix its ownership & permissions.

$ chown user:group ~/.Xauthority
$ chmod 0600 ~/.Xauthority

If the issue isn't resolved by either of these operations then you can attempt to diagnose the xauth magic cookies themselves.

as local user running ssh

$ xauth list
localhost/unix:13 MIT-MAGIC-COOKIE-1 c77169a6fa8139ea36f538e1c72e1b98

as pinker on server

$ xauth
Using authority file /home/pinker/.Xauthority

Then add the key manually:

xauth> add localhost/unix:13 MIT-MAGIC-COOKIE-1 c77169a6fa8139ea36f538e1c72e1b98

References

• Linux X11 Connection Rejected Because of Wrong Authentication Error and Solution

Solution 4

I got most of this information from http://openvz.org/X_inside_VE#X_forwarding

Verify X in SSH

After login via SSH, verify that X forwarding is working by looking for the DISPLAY environmental variable:

echo $DISPLAY

The answer should be something like localhost:8.0

Make sure sshd allows X forwarding

Edit /etc/ssh/sshd_config and make sure it has X11Forwarding yes

If not, edit or add the line with X11Fordwarding then restart sshd:

service sshd restart (/etc/init.d/sshd restart is using CentOS 5)

Then log out and in again

Make sure xauth is set up

Make sure the xauth package has been installed. In Debian, this is part of the xbase-clients package.

It's still not working

In the question I am answering, the error message is this: /usr/bin/xauth: (stdin):1: bad display name "pinker-server:10.0" in "remove" command

One possible solution, suggested below, is making sure the relevant line in sshd_config looks like this:

X11UseLocalhost yes

Solution 5

Bumped into this problem after Gentoo upgrade. This page is the first google result for 'add display name unix in add command'. None of the solutions described here helped. The workaround is written in the debian bug description (second link in the fore-mentioned google search page):

sethostname any-name-here

after execution of 'sethostname vvk' I can log in with X-forwarding as before. This answer is typed from the browser which is being run in the very first proper shell logged in on remote server.

View more solutions

Comments

[Rucent88]

It looks like we might be getting closer to the solution? I have updated the info above. Thank you.

[slm]

It's generally a bad idea to add a hostname to 127.0.0.1.

[samiam]

I've edited the answer to reflect that.

[slm]

Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.

[Vladimir Kunschikov]

typical sshd config, nothing special.

[Jason Robinson]

Thanks, that was exactly the case for me on my OpenBSD 5.9 (-current) desktop.

[Kevin]

a good clue that this is the case, is when "xauth list" shows two difference hostnames. root@sdi-playout:~# xauth list ubuntu-NANOCOM-BT/unix:1 MIT-MAGIC-COOKIE-1 ... sdi-playout/unix:0 MIT-MAGIC-COOKIE-1 ...

[llinfeng]

Thanks! This helped me solve the X-forwarding failure for my VPS.