xauth not creating .Xauthority file

Question

When I ssh into a headless Linux Mint 17 system, it doesn't create update / create an .Xauthority file.

Moreover, when I run xauth I get the reply:

marty@N40L ~ $ xauth
xauth:  file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority
xauth>exit
marty@N40L ~ $ xauth
xauth:  file /home/marty/.Xauthority does not exist
Using authority file /home/marty/.Xauthority
xauth>

It doesn't create the file.

EDIT:

When I connect monitor, then log in locally, the file is created but when I try to add an entry (because my SSH doesn't do it for me):

marty@N40L ~ $ xauth list
N40L/unix:0  MIT-MAGIC-COOKIE-1  34eee3b15cdb281021502d40dfba1cf2
localhost.localdomain/unix:0  MIT-MAGIC-COOKIE-1  34eee3b15cdb281021502d40dfba1cf2
marty@N40L ~ $ ls -d .X*
-rw------- 1 marty marty 115 Sep  3 12:03 .Xauthority
marty@N40L ~ $ xauth generate $DISPLAY .
PuTTY X11 proxy: wrong authorisation protocol attemptedxauth: (argv):1:  unable to open display "localhost:10.0".

Incidentally, doing a netstat --listen shows the port listening:

tcp 0 0 localhost:6010 *:* LISTEN

AGH, more info. I logged out of the X session on the server, and now the .Xauthority file has disappeared. It seems the file is ONLY there when logged in locally. Can anyone tell me why, or how I can fix this?

NEW DEVELOPMENT:

I created a virgin user on the system called "test". I then logged in, and without ANY other commands, ran xeyes. Which worked! So it's ONLY the user "marty" that cannot xforward. How do I copy the settings from test to marty?

Answer 1

Just to report, I did have a similar problem. But in my case I just follow those steps:

Follow these steps to create a $HOME/.Xauthority file.

Log in as user and confirm that you are in the user's home directory.

# Rename the existing .Xauthority file by running the following command
mv .Xauthority old.Xauthority 

# xauth with complain unless ~/.Xauthority exists
touch ~/.Xauthority

# only this one key is needed for X11 over SSH 
xauth generate :0 . trusted 

# generate our own key, xauth requires 128 bit hex encoding
xauth add ${HOST}:0 . $(xxd -l 16 -p /dev/urandom)

# To view a listing of the .Xauthority file, enter the following 
xauth list 

After that there are no more problems with .Xauthority file since then.

Thanks and credits to srinivasan.

Answer 2

Under root privileges open /etc/ssh/sshd_config and uncomment the following lines if they are commented:

X11Forwarding yes

X11DisplayOffset 10

X11UseLocalhost yes

Then logout and login again with -X flag in ssh. You do not have to set or unset DISPLAY environment variable.

Answer 3

Just to complement the excellent ton's answer.

I have once had exactly the same problem because my home directory had become 100% full. Upon connection, ssh created an empty ~/.Xauthority and was unable to write any single entry to it (so that xauth list had always produced an empty output).

So I suggest one always checks the free space (e. g.: df -h) and verifies that xauth generate and xauth add have indeed had any effect (xauth list).

Answer 4

Found another potential cause of xauth not creating the .Xauthority file by following a couple of the answers above. Should become immediately obvious if you are following Ton's answer:

$ touch ~/.Xauthority
touch: cannot touch ‘/nethome/jdoe/.Xauthority’: Disk quota exceeded

The above will happen if you exceed the "number of files" quota for your user. If you exceed the space quota, you will likely see that error message at a different step. Or, to test if its a space disk quota issue, type:

echo "hello, world" > ~/hello.txt

If the echo gives you a Disk quota exceeded message, then you know that you are using too much space in your home directory (as opposed to too many files or inodes).

Solution in either case? Clean up your home directory!

Answer 5

Moving the .ssh directory out of the way made X forwarding work for me.

Through process of elimination, I found a file in ~/.ssh that was called "rc", and contained:

echo "Wecome to $(hostname), $(whoami)"

I never created this, and have no idea where it came from. Removing it fixed the issue, and my authorized_keys, known_hosts, and key files can all stay intact.

Answer 6

I came across this same issue on two servers that were technically sister nodes. Pain in my tail, as I couldn't figure out what was different. Turns out the /home directory was full, so .Xauthority files couldn't populate properly. Once I located the file(s) taking up too much space and purged them, new .Xauthority files were created properly.

Answer 7

Here goes another answer, which I would have liked to find (handling the case of forwarding from a VM host to its VM guest):

There may be certain VM images (in my case a KVM image for Ubuntu 18.04) in which for some reason, the default in /etc/ssh/sshd_config for AddressFamily is set to any (I stumbled across this as a possibility here on Redhat's Bugzilla platform after googling an error from running journalctl -xe, with substring "Failed to allocate internet-domain X11 display socket.").

The assumption of course being, that xauth is installed/running.

So, what can be found in the other answers here was not sufficient for me, I needed the settings:

AddressFamily inet
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no

The 10 should depend on your host machine's configuration, I had to use X11UseLocalhost no, because otherwise the KVM guest would try to forward to its own displays, not the host machine's displays.

If you are using ssh-agent, then there is

AllowAgentForwarding yes

as well, which probably should be activated.

Answer 8

After finding out that it wasn't the system, by adding a test user (which x forwarding worked "out the box"), I thought I'd start copying the .bash* startup files across to virginise the "broken" user.

None of the files were different, so next I deleted the users .ssh directory. When I ssh'd in, it moaned about "Server refused our key", but I could log in using password. Once logged in, I could x forward perfectly.

I'll now try to setup the key again and see if I can get that working too. Then it'll be back to normal.

Answer 9

Another possible reason:

no space left on device (df shows 0 bytes)

Possible fix: e.g. removing python-pip cache.

Answer 10

I fixed this issue:

I opened an ssh connection to my server with the -X command option like this

ssh -X user@ip

then I got the Xauthority error. So I just ran this command on the ssh server

touch .Xauthority

Just run this

After that just

nano /etc/ssh/sshd_config

Uncomment the following and replace <username> with your username

Match User <Username>
    X11Forwarding yes
#    AllowTcpForwarding yes
#    PermitTTY yes
#    ForceCommand cvs server