xauth erstellt keine .Xauthority-Datei

Nur um zu berichten, ich hatte ein ähnliches Problem. Aber in meinem Fall befolge ich einfach diese Schritte :

Folgen Sie diesen Schritten, um eine Datei $HOME/.Xauthority zu erstellen.

Melden Sie sich als Benutzer an und bestätigen Sie, dass Sie sich im Home-Verzeichnis des Benutzers befinden.

# 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

Danach gibt es seitdem keine Probleme mehr mit der Datei .Xauthority.

Dank und Anerkennung an srinivasan .

Nur als Ergänzung zu den ausgezeichneten ton ’s answer .

hatte ich einmal genau das gleiche Problem, weil mein Home-Verzeichnis zu 100% voll geworden war. Beim Anschließen erzeugte ssh eine leere ~/.Xauthority und konnte keinen einzigen Eintrag in dieses Verzeichnis schreiben (so dass xauth list immer eine leere Ausgabe erzeugt hatte).

Ich schlage also vor, man überprüft immer den freien Platz (z. B.: df -h) und verifiziert, dass xauth generate und xauth add tatsächlich irgendeine Wirkung gehabt haben (xauth list).

Durch das Verschieben des Verzeichnisses .ssh funktionierte die X-Weiterleitung für mich.

Durch einen Eliminationsprozess fand ich eine Datei in ~/.ssh, die “rc” hieß und enthielt:

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

Ich habe diese Datei nie erstellt und habe keine Ahnung, woher sie kam. Durch das Entfernen wurde das Problem behoben, und meine authorized_keys, known_hosts und Schlüsseldateien können alle intakt bleiben.

Nachdem ich herausgefunden hatte, dass es nicht das System war, indem ich einen Testbenutzer hinzufügte (wobei die x-Weiterleitung “out of the box” funktionierte), dachte ich, ich fange an, die .bash*-Startdateien rüber zu kopieren, um den “kaputten” Benutzer zu jungfräulich zu machen.

Keine der Dateien war anders, also löschte ich als nächstes das .ssh-Verzeichnis des Benutzers. Als ich ssh’d in, stöhnte es über “Server verweigerte unseren Schlüssel”, aber ich konnte mich mit dem Passwort einloggen. Sobald ich eingeloggt war, konnte ich x perfekt weiterleiten.

Ich versuche nun, den Schlüssel erneut einzurichten und zu sehen, ob ich das auch hinbekomme. Dann wird es wieder normal sein.

Öffnen Sie unter Root-Privilegien /etc/ssh/sshd_config und entkommentieren Sie die folgenden Zeilen, wenn sie kommentiert werden:

X11Forwarding ja

X11DisplayOffset 10

X11UseLocalhost ja

Dann loggen Sie sich aus und wieder mit dem Flag -X in ssh ein. Sie müssen die Umgebungsvariable DISPLAY nicht setzen oder zurücksetzen.

Ich stieß auf dasselbe Problem auf zwei Servern, die technisch gesehen Schwesterknoten waren. Ich hatte Schmerzen im Hintern, da ich nicht herausfinden konnte, was anders war. Es stellte sich heraus, dass das Verzeichnis /home voll war, so dass die Xauthority-Dateien nicht richtig aufgefüllt werden konnten. Nachdem ich die Datei(en) gefunden hatte, die zu viel Platz beanspruchten, und sie bereinigt hatte, wurden neue .Xauthority-Dateien ordnungsgemäß erstellt.