Running an strace on the remote system where xauth is failing will show you what's tripping up xauth.
For example
$ strace xauth list
stat("/home/sam/.Xauthority-c", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0x7fff6c4430e0) = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0x7fff6c4430e0) = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
So xauth is attempting to open a file and it already exists. The culprit file is /home/sam/.Xauthority-c. We can confirm the presence of this file on the remote system:
$ ls -l .Xauthority*
-rw------- 1 sam sam 55 Jul 12 22:04 .Xauthority
-rw------- 1 sam sam 0 Jul 12 22:36 .Xauthority-c
-rw------- 1 sam sam 0 Jul 12 22:36 .Xauthority-l
The fix
As it turns out. Those files are lock files for .Xauthority, so simply removing them resolves the issue.
$ rm -fr .Xauthority-*
With the files deleted, exit from the SSH connection and then reconnect. This will allow xauth to re-run successfully.
$ ssh -t skinner ssh sam@blackbird
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-44-generic x86_64)
* Documentation: https://help.ubuntu.com/
Last login: Sun Jul 12 22:37:54 2015 from skinner.bubba.net
$
Now we're able to run xauth list and X11 applications without issue.
$ xauth list
blackbird/unix:10 MIT-MAGIC-COOKIE-1 cf01f793d2a5ece0ea58196ab5a7977a
The GUI
$ xeyes
Alternative method to resolve the issue
I came across this post titled: xauth: error in locking authority file .Xauthority [linux, ssh, X11] which mentions the use of xauth -b to break any lock files that may be hanging around. xauth's man page seems to back this up:
-b This option indicates that xauth should attempt to break any
authority file locks before proceeding. Use this option only to
clean up stale locks.
References
Best Answer
When
xauthis updating the.Xauthorityfile, it will initially write a new version of it as.Xauthority-n. Once the file is completely written, it will move/rename it to.Xauthority, causing the old version of the file to be deleted at the same time.This relies on the fact that rename/move operations within a single POSIX-compliant filesystem are supposed to be atomic: the operation cannot ever stop half-way, but either it will complete successfully or the old file will be left unchanged.
If the
xauthcommand finds that the.Xauthority-nfile is already present, it assumes it means another instance ofxauthcommand is already doing some changes, and refuses to do anything. So this also protects the file from corruption caused by multiple instances ofxauthrunning at the same time as the same user.The fact that a
.Xauthority-nfile remains in your home directory suggests that an earlier copy ofxauthwas terminated in mid-operation before it could execute the rename/move operation for some reason.You should log out of the X GUI, then login either remotely or using the text-based virtual console, and then delete both
.Xauthorityand.Xauthority-n. After that, the GUI login should work normally, unless you have some other problem that prevents the system from creating/overwriting the.Xauthorityfile in your home directory.