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

xauth not creating .Xauthority file

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

De plus, lorsque je lance xauth, j'obtiens 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.

EDIT :

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

Au fait, 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 maintenant le fichier .Xauthority a disparu. Il semble que le fichier soit UNIQUEMENT là lorsque je me connecte en local. 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 SEUL l'utilisateur “marty” qui ne peut pas faire xforward. Comment puis-je copier les paramètres de test vers marty ?
Source

Réponses (6)

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

Juste pour info, j'ai eu un problème similaire. Mais dans mon cas, j'ai simplement suivi ces étapes :

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

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 fichier .Xauthority depuis lors.

Merci et crédits à srinivasan .
Source
4
4
4
2018-02-20 15:30:16 +0000

Juste pour compléter l'excellent ton answer .

J'ai déjà eu exactement le même problème parce que mon répertoire personnel était devenu plein à 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 produit 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 bien eu un effet (xauth list).
Source
1
1
1
2015-05-20 14:06:07 +0000

Le déplacement du répertoire .ssh m'a permis de faire fonctionner le transfert X.

Par élimination, j'ai trouvé un fichier dans ~/.ssh qui s'appelait “rc” et qui contenait : 

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

Je n'ai jamais créé ce fichier et je n'ai aucune idée de son origine. Le supprimer a réglé le problème, et mes authorized_keys, known_hosts, et les fichiers clés peuvent tous rester intacts.
Source
1
1
1
2014-09-04 08:33:25 +0000

Après avoir découvert que ce n'était pas le système, en ajoutant un utilisateur test (dont la redirection x a fonctionné “out the box”), j'ai pensé commencer à copier les fichiers de démarrage .bash* pour virginiser l'utilisateur “cassé”.

Aucun des fichiers n'était différent, donc j'ai ensuite supprimé le répertoire .ssh des utilisateurs. Quand j'y suis entré, le serveur a refusé notre clé, mais j'ai pu me connecter en utilisant un mot de passe. Une fois connecté, j'ai pu faire une avance x parfaite.

Je vais maintenant essayer de configurer à nouveau la clé et voir si je peux faire fonctionner cela aussi. Ensuite, tout reviendra à la normale.
Source
1
1
1
2019-09-17 06:35:46 +0000

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

X11Forwarding oui

X11DisplayOffset 10

X11UseLocalhost oui

Puis déconnectez-vous et reconnectez-vous avec le drapeau -X dans ssh. Vous n'avez pas à activer ou désactiver la variable d'environnement DISPLAY.
Source
0
0
0
2019-01-11 14:16:32 +0000

Je suis tombé sur ce même problème sur deux serveurs qui étaient techniquement des nœuds frères. J'ai eu mal à la queue, car je n'arrivais pas à comprendre ce qui était différent. Il s'est avéré que le répertoire /home était plein, donc les fichiers .Xauthority ne pouvaient pas se remplir correctement. Une fois que j'ai localisé le(s) fichier(s) prenant trop de place et que je les ai purgés, de nouveaux fichiers .Xauthority ont été créés correctement.
Source