Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I try to start a screen session and connect to three different machines with the same user.

Here is what I have in my .screenrc

screen -t "machine1" 0 ssh user@machine1
screen -t "machine2" 1 ssh user@machine2
screen -t "machine3" 2 ssh user@machine3

My ~/.ssh/config contains

ForwardX11 yes

I get the following error in the terminals of machine2 and machine3.

Warning: No xauth data; using fake authentication data for X11 forwarding
/usr/X11/bin/xauth: error in locking authority file /home/user/.Xauthority

If I remove only one of the machines from my .screenrc it works correctly.

How can I avoid this error and connect to multiple machines from screen.

EDIT: The user home dir is on NFS and locking doesn't work properly with NFS. To circumvent this I tried hard to either have the XAuthority file on a local file system (/tmp) or to have one file per ssh. I didn't manage, somehow my xauth seems to completely ignore the XAUTHORITY environment variable. Still puzzeled...

share|improve this question
1  
So it works fine with 2 machines? (And I assume you indeed want to use X? You only need that ForwardX11 when you want to use graphical sessions. As far as I know, screen is just character based?) –  Arjan Nov 10 '09 at 8:30
    
@Arjan: Well it sometimes works somehow with any number of machines and sometimes not. The reason seems to be a race condition in conjuction with nfs locking problems. –  user1863 Nov 10 '09 at 15:15
    
If using ssh -f -N (in some shell script, instead of using screen) would be an option, then at least you can add some sleep command in between the 3 commands? Or maybe move the 3 screen commands from .screenrc into some shell script, using sleep as well? –  Arjan Nov 10 '09 at 15:33
    
And just to be sure: you are using the graphical capabilities of X, right? So, you're not just trying to get 3 shell prompts (character based), but really use the graphical X11 interface? –  Arjan Nov 11 '09 at 7:32
    
@Arjan: sleep is also possible in screenrc. I added sleep 30 between the screen commands and it really slept 30 seconds, but it didn't solve the problem. Sometimes XAuthority is locked and stays locked longer than 30 seconds and sometimes it is not locked at all. –  user1863 Nov 12 '09 at 13:00

1 Answer 1

up vote 1 down vote accepted
/usr/X11/bin/xauth: error in locking authority file /home/user/.Xauthority

Do you ever get that same error without screen, after the first SSH session has been established? It's odd that your "If I remove only one of the machines [..] it works correctly" seems to say that 2 machines work, but a 3rd yields problems. If ssh supports multiple X-forwarded connections, then it might just be a matter of doing things more slowly? That can best be tested without screen I guess. And what if you change the order of the machines?

It guess that this .Xauthority file is on the remote machine, but I am no expert. (If /home/user in your question was in fact a more specific directory, then you can probably easily tell if it's local or remote.) So, odd question: are you sure that all 3 machines are really different machines, and that no-one else is using the same account? From man ssh:

ssh will also automatically set up Xauthority data on the server machine. For this purpose, it will generate a random authorization cookie, store it in Xauthority on the server, and verify that any forwarded connections carry this cookie and replace it by the real cookie when the connection is opened. The real authentication cookie is never sent to the server machine (and no cookies are sent in the plain).

(And couldn't you replace screen with ssh -f -N, or are you using the screen's title to be able to stop things?)

share|improve this answer
    
It happens also without screen, if I open the sshs fast enough. The machines are different, but the user is the same, and here lies the problem: The user home dir is mounted via nfs and we are still on kernel 2.6.16. There seems to be a locking problem with this configuration. Thanks for pointing me in the right direction. –  user1863 Nov 10 '09 at 15:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.