xauth ne crée pas de fichier .Xauthority

Quand je ssh dans un système sans tête Linux Mint 17, il ne crée pas de mise à jour / crée un fichier .Xauthority.

De plus, lorsque je cours, xauthje reçois la réponse:

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>

Il ne crée pas le fichier.

ÉDITER:

Lorsque je connecte un moniteur, puis que je me connecte localement, le fichier est créé mais lorsque j'essaie d'ajouter une entrée (car mon SSH ne le fait pas pour moi):

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

Par ailleurs, faire un netstat --listenmontre le port d'écoute:

tcp 0 0 localhost:6010 *:* LISTEN

AGH, plus d'infos. Je me suis déconnecté de la session X sur le serveur et maintenant le fichier .Xauthority a disparu. Il semble que le fichier existe UNIQUEMENT lorsqu'il est connecté localement. Quelqu'un peut-il me dire pourquoi ou comment résoudre ce problème?

NOUVEAU DÉVELOPPEMENT:

J'ai créé un utilisateur vierge sur le système appelé "test". Je me suis ensuite connecté, et sans AUCUNE autre commande, j'ai exécuté xeyes. Qui a fonctionné! C'est donc SEULEMENT l'utilisateur "marty" qui ne peut pas xforward. Comment copier les paramètres de test vers marty?

Juste pour signaler, j'ai eu un problème similaire. Mais dans mon cas, je viens de suivre ces étapes :

Suivez ces étapes pour créer un $HOME/.Xauthorityfichier.

Connectez-vous en tant qu'utilisateur et confirmez que vous êtes dans le répertoire personnel de l'utilisateur.

# 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 

Après cela, il n'y a plus de problèmes avec le .Xauthorityfichier depuis.

Merci et crédits à srinivasan .

Juste pour compléter l'excellente tonne de réponse .

J'ai eu une fois exactement le même problème parce que mon répertoire personnel était plein à 100%. Lors de la connexion, a sshcréé un vide ~/.Xauthorityet n'a pas pu y écrire une seule entrée (ce qui xauth lista toujours produit une sortie vide).

Je suggère donc de toujours vérifier l'espace libre (par exemple df -h:) et de vérifier cela xauth generateet d' xauth addavoir effectivement eu un effet ( xauth list).

Après avoir découvert que ce n'était pas le système, en ajoutant un utilisateur de test (dont le transfert x a fonctionné "hors de la boîte"), j'ai pensé commencer à copier les fichiers de démarrage .bash * pour virginiser l'utilisateur "cassé".

Aucun des fichiers n'était différent, j'ai donc supprimé le répertoire .ssh des utilisateurs. Quand je suis entré, il a gémi à propos du "serveur a refusé notre clé", mais j'ai pu me connecter en utilisant un mot de passe. Une fois connecté, je pouvais x transférer parfaitement.

Je vais maintenant essayer de configurer à nouveau la clé et voir si je peux aussi le faire fonctionner. Ensuite, ce sera de retour à la normale.

Le fait de déplacer le .sshrépertoire pour que le transfert X fonctionne pour moi.

Grâce au processus d'élimination, j'ai trouvé un fichier dans ~ / .ssh qui s'appelait "rc" et contenait:

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

Je n'ai jamais créé ça, et je n'ai aucune idée d'où ça vient. L' enlever résolu le problème, et mes authorized_keys, known_hostset les fichiers clés peuvent tous restent intacts.

Sous les privilèges root, ouvrez /etc/ssh/sshd_configet décommentez les lignes suivantes si elles sont commentées:

X11Forwarding oui

X11DisplayOffset 10

X11UseLocalhost oui

Ensuite, déconnectez-vous et reconnectez-vous avec le -Xdrapeau ssh. Il n'est pas nécessaire de définir ou de désactiver DISPLAYla variable d'environnement.

J'ai rencontré ce même problème sur deux serveurs qui étaient techniquement des nœuds sœurs. Douleur dans la queue, car je ne pouvais pas comprendre ce qui était différent. Il s'avère que le répertoire / home était plein, de sorte que les fichiers .Xauthority ne pouvaient pas se remplir correctement. Une fois que j'ai localisé le (s) fichier (s) occupant trop d'espace et que je les ai purgés, de nouveaux fichiers .Xauthority ont été créés correctement.