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?

Did you tell it to create the file? `ssh -X` enables X11 forwarding. — u1686_grawity, Sep 03 '14 at 10:47
Yes, I'm using Putty on Windows, setup for forwarding (works on connecting to another Mint server). But the file is not created, so I thought I'd add it manually, xauth doesn't create it manually either. — wkdmarty, Sep 03 '14 at 10:49
Local Xwindows creates the .Xauthority file, but Putty SSH session doesn't. Even though it shows it listening for the connection. — wkdmarty, Sep 03 '14 at 13:19

score 72 · Answer 1 · edited Sep 01 '19 at 17:56

72

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.

edited Sep 01 '19 at 17:56

Run5k

15,723
24
49
63

answered Jul 16 '15 at 04:15

ton

861
7
13

2

in my case, I had an environment variable XAUTHORITY pointing to somewhere else (a careless mistake), using this [http://prefetch.net/blog/index.php/2011/11/01/dealing-with-xauth-error-in-locking-authority-file-errors/] thread I was able to discover this and resolve the error. Using `strace xauth`, it pointed out the incorrect path specified in the variable. I should also add that I was getting locking errors aswel, amongst others – CybeX May 23 '17 at 23:32
1

In my case, I only had to do step 1 to 3. Step 4 and 5 actually made it not work. – Richard Ayotte Oct 22 '17 at 17:36
I have to do `xauth generate :0 . trusted` after every command as `user` to open a display as `root`. Can I make it fix? – Timo Mar 12 '18 at 19:43
`xhost +` helped to open x-apps as `root`. – Timo Mar 12 '18 at 20:38
43

step 3 gives me the error: `xauth: (argv):1: unable to open display ":0".` – simpleuser Jul 12 '18 at 05:33
Many postings say not to run 'xhost +' due to security implications. – MikeW Dec 12 '18 at 16:54
@simpleuser - I had the same issue, but it worked. Still I asked the question one more time: https://superuser.com/questions/1607526/ssh-x-to-machine-without-any-monitor-to-open-a-gui – Qohelet Dec 05 '20 at 10:18
@simpleuser replacing :0 with $DISPLAY worked for me as I use XQUARTZ as an X11 server on my mac laptop – Ajay Jan 06 '21 at 18:23
After this I still have issues. Whenever I run mpirun I get "Invalid MIT-MAGIC-COOKIE-1". If I remove it I go back to "No protocol specified". – Kvothe Jan 22 '21 at 16:55
For those with `xauth: (argv):1: unable to open display ":0".`, maybe your Xorg is running in another display port... check if `$DISPLAY` environment variable helps. – ton Mar 31 '21 at 12:36
When I run with $DISPLAY I have the following error: `X11 connection rejected because of wrong authentication` `xauth: (argv):1: unable to open display "localhost:11.0".` – Homero Esmeraldo Apr 07 '21 at 20:46
check this question: https://unix.stackexchange.com/questions/110558/su-with-error-x11-connection-rejected-because-of-wrong-authentication#118295 – ton Apr 08 '21 at 08:11
@ton: Any idea what is the root cause of this issue? it happens to my Gitlab server frequently (every month) and suddenly my services goes down – Amir Jul 09 '21 at 04:47
1

@Amir, as a gitlab-server is just a webapp, does no seems to make any sense Xorg to cause it to be down, I do suggest to you check how the service is setup. But in gitlab-runners it can be a problem depending on what kind of projects dependencies you are building. Probably specific to a project repo CI build. You need to check for example if the project is recreating the xauth setup inside a new container that is not so simple to integrate with host Xorg because the libs can be in different versions. Anyway it's very hard to tip without know more about your context. – ton Jul 09 '21 at 13:11

score 13 · Answer 2 · edited Jun 12 '20 at 13:48

13

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.

edited Jun 12 '20 at 13:48

Community

1

answered Sep 17 '19 at 06:35

varsh

231
2
4

score 6 · Answer 3 · answered Feb 20 '18 at 15:30

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

score 4 · Answer 4 · answered Apr 06 '20 at 21:19

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!

score 2 · Answer 5 · answered Jan 11 '19 at 14:16

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.

score 2 · Answer 6 · answered Sep 08 '20 at 17:09

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.

score 2 · Answer 7 · edited Oct 18 '16 at 22:33

2

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.

edited Oct 18 '16 at 22:33

kenorb

24,736
27
129
199

answered May 20 '15 at 14:06

billq

131
3

score 1 · Accepted Answer · edited Oct 18 '16 at 22:29

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.

score 0 · Answer 9 · edited Jun 29 '22 at 11:53

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

score 0 · Answer 10 · answered Nov 29 '22 at 10:26

0

Another possible reason:

no space left on device (df shows 0 bytes)

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

answered Nov 29 '22 at 10:26

Flo

1

2

What question are you answering? – Toto Nov 29 '22 at 10:41

xauth not creating .Xauthority file

10 Answers10

Linked