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

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 2

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 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

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 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.