2014-09-03 10:44:44 +0000 2014-09-03 10:44:44 +0000
30
30

xauth not creating .Xauthority file

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:

Kiedy podłączam monitor, a następnie loguję się lokalnie, plik jest tworzony, ale kiedy próbuję dodać wpis (ponieważ mój SSH nie robi tego za mnie): 

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

Nawiasem mówiąc, robiąc netstat --listen pokazuje słuchanie portu: 

tcp 0 0 localhost:6010 *:* LISTEN

AGH, więcej informacji. Wylogowałem się z sesji X na serwerze, a teraz plik .Xauthority zniknął. Wygląda na to, że plik ten jest TYLKO tam, gdy jest zalogowany lokalnie. Czy ktoś może mi powiedzieć dlaczego, lub jak mogę to naprawić?

NOWY ROZWÓJ:

Stworzyłem w systemie dziewiczego użytkownika o nazwie “test”. Następnie zalogowałem się, i bez żadnych innych poleceń, uruchomiłem xeyes. Co zadziałało! Więc to tylko użytkownik “marty” nie może xforwardować. Jak mogę skopiować ustawienia z testu na marty?
Źródło

Odpowiedzi (6)

35
35
35
2015-07-16 04:15:44 +0000

Tylko po to, by zgłosić, miałem podobny problem. Ale w moim przypadku po prostu wykonuję te kroki :

Wykonaj te kroki, aby utworzyć plik $HOME/.Xauthority.

Zaloguj się jako użytkownik i potwierdź, że jesteś w katalogu domowym użytkownika. 

# 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

Od tego czasu nie ma już problemów z plikiem .Xauthority.

Dzięki i podziękowania dla srinivasan .
Źródło
4
4
4
2018-02-20 15:30:16 +0000

Aby uzupełnić doskonały ton ’s odpowiedź .

Kiedyś miałem dokładnie ten sam problem, ponieważ mój katalog domowy stał się w 100% pełny. Po połączeniu, ssh stworzył pusty ~/.Xauthority i nie był w stanie napisać do niego żadnego pojedynczego wpisu (więc xauth list zawsze dawał puste wyjście).

Proponuję więc zawsze sprawdzać wolne miejsce (np.: df -h) i sprawdzać czy xauth generate i xauth add rzeczywiście dały jakiś efekt (xauth list).
Źródło
1
1
1
2015-05-20 14:06:07 +0000

Przesunięcie katalogu .ssh z drogi sprawiło, że przekierowanie X-ów działało za mnie.

Poprzez proces eliminacji znalazłem plik w ~/.ssh, który nazywał się “rc” i zawierał: 

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

Nigdy tego nie tworzyłem i nie mam pojęcia skąd się wzięło. Usunięcie go naprawiło problem, a moje authorized_keys, known_hosts, i kluczowe pliki mogą pozostać nienaruszone.
Źródło
1
1
1
2014-09-04 08:33:25 +0000

Po tym jak dowiedziałem się, że to nie był system, dodając użytkownika testowego (który x forwarding zadziałał “out the box”), pomyślałem, że zacznę kopiować pliki startowe .bash*, aby zainfekować “uszkodzonego” użytkownika.

Żaden z tych plików nie był inny, więc następnie usunąłem katalog users .ssh. Kiedy wszedłem, jęczał o “Serwer odmówił nam klucza”, ale mogłem się zalogować za pomocą hasła. Po zalogowaniu, mogłem idealnie x przekazać dalej.

Teraz spróbuję ponownie ustawić klucz i sprawdzić, czy to też działa. Wtedy wrócimy do normy.
Źródło
1
1
1
2019-09-17 06:35:46 +0000

Pod root privileges otwórz /etc/ssh/sshd_config i usuń komentarz w następujących liniach:

X11Forwarding yes

X11DisplayOffset 10

X11UseLocalhost yes

Następnie wyloguj się i zaloguj ponownie z flagą -X w ssh. Nie trzeba ustawiać ani wyłączać zmiennej środowiskowej w DISPLAY.
Źródło
0
0
0
2019-01-11 14:16:32 +0000

Na ten sam problem natknąłem się na dwa serwery, które były technicznie siostrzanymi węzłami. Bolał mnie ogon, bo nie mogłem się zorientować, co jest inne. Okazuje się, że katalog /home był pełny, więc pliki .Xauthority nie mogły się prawidłowo zapełnić. Po zlokalizowaniu pliku(ów) zajmującego(ych) zbyt dużo miejsca i oczyszczeniu ich, nowe pliki .Xauthority zostały utworzone poprawnie.
Źródło