web-dev-qa-db-fra.com

xauth ne crée pas de fichier .Xauthority

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

De plus, quand je lance xauth, je 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.

MODIFIER:

Lorsque je connecte moniteur, puis que je me connecte localement, le fichier est créé mais lorsque j'essaie d'ajouter une entrée (car 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".

Incidemment, faire un netstat --listen montre le port en écoute:

tcp 0 0 localhost:6010 *:* LISTEN

AGH, plus d'infos. Je me suis déconnecté de la session X sur le serveur et le fichier .Xauthority a maintenant disparu. Il semble que le fichier est SEULEMENT là-bas lorsqu'il est connecté localement. Quelqu'un peut-il me dire pourquoi ou comment je peux 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 lancé xeyes. Ce qui a fonctionné! Donc, c’est SEULEMENT l’utilisateur "marty" qui ne peut pas effectuer d’exécution. Comment copier les paramètres de test à marty?

linuxsshxauth
21
wkdmarty

Après avoir découvert que ce n’était pas le système, en ajoutant un utilisateur test (dont la transmission x fonctionnait "à la volée"), je pensais commencer à copier les fichiers de démarrage .bash * afin de virginiser l’utilisateur "cassé".

Aucun des fichiers n'étant différent, j'ai ensuite supprimé le répertoire .ssh des utilisateurs. Quand je suis entré, ça a gémi à propos de "Le serveur a refusé notre clé", mais je pouvais me connecter avec un mot de passe. Une fois connecté, je pouvais x parfaitement.

Je vais maintenant essayer de ré-installer la clé et voir si je peux la faire fonctionner aussi. Ensuite, ça va revenir à la normale.

1
wkdmarty

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

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

Connectez-vous en tant qu'utilisateur et confirmez que vous vous trouvez dans le répertoire de base 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, plus de problèmes avec le fichier .Xautority depuis lors.

Merci et crédits à srinivasan .

27
ton

Juste pour compléter l'excellent ton 's réponse .

Une fois, j’ai eu exactement le même problème car mon répertoire personnel était saturé à 100%. Lors de la connexion, ssh a créé un ~/.Xauthority vide et n’a pas pu y écrire une seule entrée (de sorte que xauth list a toujours généré une sortie vide).

Je suggère donc de toujours vérifier l’espace libre (par exemple, df -h) et de vérifier que xauth generate et xauth add ont effectivement eu un effet (xauth list).

3
Bass

Le fait de déplacer le répertoire .ssh en dehors de la route a rendu le transfert X efficace pour moi.

Au cours du processus d’élimination, j’ai trouvé un fichier dans ~/.ssh appelé "rc" et contenant:

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

Je n'ai jamais créé cela et je ne sais pas d'où ça vient. En le supprimant, le problème a été résolu. Mes fichiers authorized_keys, known_hosts et mes clés peuvent rester intacts.

1
billq

Je suis tombé sur le même problème sur deux serveurs techniquement associés. Douleur dans la queue, je ne pouvais pas comprendre ce qui était différent. Il s’avère que le répertoire/home est plein et que les fichiers .Xauthority ne peuvent pas être remplis correctement. Une fois que j'ai localisé le ou les fichiers, prenant trop de place et les avoir purgés, de nouveaux fichiers .Xauthority ont été créés correctement.

0
Linux_User