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

xauth maakt geen .Xauthority bestand

Wanneer ik in een hoofdloos Linux Mint 17 systeem ssh, maakt het geen update / een .Xauthority bestand.

Bovendien, wanneer ik xauth draai krijg ik het antwoord: 

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>

Het maakt het bestand niet aan.

EDIT:

Als ik monitor aansluit en vervolgens lokaal inlog, wordt het bestand aangemaakt maar als ik een entry probeer toe te voegen (omdat mijn SSH het niet voor mij doet): 

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

Overigens laat het doen van een netstat --listen de poort luisteren zien: 

tcp 0 0 localhost:6010 *:* LISTEN

AGH, meer info. Ik heb uitgelogd van de X-sessie op de server, en nu is het .Xauthority bestand verdwenen. Het lijkt erop dat het bestand ALLEEN aanwezig is als je lokaal bent ingelogd. Kan iemand mij vertellen waarom, of hoe ik dit kan verhelpen?

NEW DEVELOPMENT:

Ik heb een maagdelijke gebruiker aangemaakt op het systeem genaamd “test”. Ik heb toen ingelogd, en zonder enige andere commando’s, heb ik xeyes uitgevoerd. Dat werkte! Dus het is ALLEEN de gebruiker “martelaar” die niet kan doorsturen. Hoe kopieer ik de instellingen van “test” naar “marty”?
Bron

Antwoorden (6)

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

Ik wil alleen maar zeggen dat ik een soortgelijk probleem had. Maar in mijn geval volg ik gewoon die stappen :

Volg deze stappen om een $HOME/.Xauthority-bestand aan te maken.

Log in als gebruiker en bevestig dat u in de thuismap van de gebruiker bent. 

# 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

Daarna zijn er geen problemen meer met het .Xauthority-bestand.

Bedankt en credits voor srinivasan .
Bron
4
4
4
2018-02-20 15:30:16 +0000

Als aanvulling op de uitstekende ton ’s antwoord .

heb ik ooit precies hetzelfde probleem gehad omdat mijn thuismap 100% vol was geraakt. Bij de verbinding maakte ssh een lege ~/.Xauthority en kon er geen enkele invoer naar schrijven (zodat xauth list altijd een lege uitvoer had geproduceerd).

Dus ik stel voor dat men altijd de vrije ruimte controleert (bijv.: df -h) en controleert of xauth generate en xauth add inderdaad enig effect hebben gehad (xauth list).
Bron
1
1
1
2015-05-20 14:06:07 +0000

Door het verplaatsen van de .ssh directory uit de weg werkte X forwarding voor mij.

Door het eliminatieproces vond ik een bestand in ~/.ssh dat “rc” werd genoemd, en dat bevatte: 

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

Ik heb dit nooit gemaakt, en heb geen idee waar het vandaan kwam. Door het te verwijderen is het probleem opgelost, en mijn authorized_keys, known_hosts, en de belangrijkste bestanden kunnen allemaal intact blijven.
Bron
1
1
1
2014-09-04 08:33:25 +0000

Nadat ik erachter kwam dat het niet het systeem was, door het toevoegen van een test gebruiker (welke x forwarding werkte “out the box”), dacht ik dat ik zou beginnen met het kopiëren van de .bash* opstartbestanden om de “gebroken” gebruiker te maagdelijken.

Geen van de bestanden waren anders, dus daarna heb ik de gebruikers .ssh directory verwijderd. Toen ik ssh’d binnenkwam, kreunde het over “Server weigerde onze sleutel”, maar ik kon inloggen met behulp van een wachtwoord. Eenmaal ingelogd kon ik perfect doorsturen.

Ik zal nu proberen de sleutel weer in te stellen en kijken of ik dat ook aan de praat krijg. Dan is het weer normaal.
Bron
1
1
1
2019-09-17 06:35:46 +0000

Onder root rechten open /etc/ssh/sshd_config en uncommentarieer de volgende regels als ze worden becommentarieerd:

X11Forwarding ja

X11DisplayOffset 10

X11UseLocalhost ja

Daarna uitloggen en opnieuw inloggen met -X vlag in ssh. U hoeft geen DISPLAY omgevingsvariabele in of uit te schakelen.
Bron
0
0
0
2019-01-11 14:16:32 +0000

Ik kwam ditzelfde probleem tegen op twee servers die technisch gezien zusterknooppunten waren. Pijn in mijn staart, want ik kon er niet achter komen wat er anders was. Blijkt dat de /home directory vol was, dus .Xauthority bestanden konden niet goed gevuld worden. Toen ik eenmaal het bestand (de bestanden) had gevonden dat (die) te veel ruimte in beslag nam (namen), werden de nieuwe .Xauthority bestanden op de juiste manier aangemaakt.
Bron