xauth maakt geen .Xauthority bestand

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 .

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

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.

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.

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.

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.