Lors de la tentative de SSH sur un hôte, j'ai reçu le message suivant xauth:

/ usr / bin / xauth: délai d'expiration dans le fichier d'autorité de verrouillage /home/sam/.Xauthority

REMARQUE: J'essayais d'afficher à distance une interface utilisateur graphique X11 via une connexion SSH; je devais xauthdonc pouvoir créer un $HOME/.Xauthorityfichier avec succès, mais comme ce message l'indiquait, ce n'était clairement pas le cas.

Les tentatives d’exécution d’applications basées sur X11, telles que celles qui xeyesont été accueillies avec le message suivant:

$ xeyes
X11 connection rejected because of wrong authentication.
Error: Can't open display: localhost:10.0

Comment puis-je résoudre ce problème?

L'exécution d'un système stracesur le système distant en cas d' xauthéchec vous montrera ce qui se produit xauth.

Par exemple

$ strace xauth list
stat("/home/sam/.Xauthority-c", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0x7fff6c4430e0)       = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0x7fff6c4430e0)       = 0
open("/home/sam/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EEXIST (File exists)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0

Donc, xauthtente d'ouvrir un fichier et il existe déjà. Le fichier coupable est /home/sam/.Xauthority-c. Nous pouvons confirmer la présence de ce fichier sur le système distant:

$ ls -l .Xauthority*
-rw------- 1 sam sam 55 Jul 12 22:04 .Xauthority
-rw------- 1 sam sam  0 Jul 12 22:36 .Xauthority-c
-rw------- 1 sam sam  0 Jul 12 22:36 .Xauthority-l

Le correctif

Comme il s'avère. Ces fichiers sont des fichiers de verrouillage .Xauthority, donc le simple fait de les supprimer résout le problème.

$ rm -fr .Xauthority-*

Une fois les fichiers supprimés, quittez la connexion SSH, puis reconnectez-vous. Cela permettra xauthde ré-exécuter avec succès.

$ ssh -t skinner ssh sam@blackbird
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-44-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

Last login: Sun Jul 12 22:37:54 2015 from skinner.bubba.net
$

Nous pouvons maintenant exécuter des xauth listapplications X11 sans problème.

$ xauth list
blackbird/unix:10  MIT-MAGIC-COOKIE-1  cf01f793d2a5ece0ea58196ab5a7977a

L'interface graphique

$ xeyes

Méthode alternative pour résoudre le problème

Je suis tombé sur ce message intitulé: xauth: erreur dans le fichier d'autorité de verrouillage .Xauthority [linux, ssh, X11], qui mentionne l'utilisation de xauth -bpour casser tous les fichiers de verrouillage susceptibles de traîner. xauthLa page de manuel de The semble corroborer cela:

 -b      This option indicates that xauth should attempt to break any
         authority file locks before proceeding.  Use this option only to
         clean up stale locks.

Les références

• Traitement des erreurs «erreur dans le fichier d'autorité de verrouillage» de xauth

La racine du problème peut être que vous n'avez pas de permission d'écriture dans le répertoire $ HOME.

C'est pourquoi j'ai reçu ce message:

/ usr / bin / xauth: délai d'expiration dans le fichier d'autorité de verrouillage /home/fooftp/.Xauthority

Voici comment j'ai vérifié l'autorisation:

fooftp@for-fun-work:~> ls -l .Xauthority 
-rw-r--r-- 1 fooftp fooftp 1 Sep 14  2015 .Xauthority
# Conlusion: I can write this file: ok

fooftp@for-fun-work:~> rm .Xauthority
rm: cannot remove '.Xauthority': Permission denied
# Conlusion: strange ... I can't delete it 

fooftp@for-fun-work:~> id
uid=1001(fooftp) gid=1000(fooftp) groups=1000(fooftp)
# Conlusion: Yes, I am user fooftp

fooftp@for-fun-work:~> ls -ld .
dr-xr-xr-x 14 fooftp fooftp 4096 Sep 14  2015 .
# Conlusion: Bug found :-)
# The permissions should be "rwx" for you.

Si tel est le problème, vous devez vous assurer que vous disposez des autorisations en écriture sur $ HOME:

chmod u+rwX $HOME

J'ai une autre réponse à la question qui me tourmentait avant de comprendre le problème. Le problème est un bug dans Fedora OS et ses dérivés, comme je l’ai compris plus tard. Si le problème ne correspond pas à la réponse acceptée et / ou que vous n'êtes pas sous Fedora, RedHat, Korora, etc., cela ne vous aidera pas.

Le problème

Comme l'utilisateur slm l'a dit, lancer strace vous donnera une indication du problème, mais dans le cas de ce bogue particulier, le résultat est différent:

$ strace xauth list
  ...
  stat64("/home/USER/.Xauthority-c", 0xbff23280) = -1 ENOENT (No such file or directory)
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
  rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
  rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
  nanosleep({2, 0}, 0xbff232c8)           = 0
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
  rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
  rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
  nanosleep({2, 0}, 0xbff232c8)           = 0
  open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) 
  ...

Pour être clair, cela indique que le code de retour EACCES, qui est une autorisation refusée. Ceci est différent du problème de l'utilisateur slm, où il avait le code de retour EEXIST, ce qui signifie que le fichier existe. Donc, pour le code de retour EACCES, évidemment, la première chose à vérifier est: est-ce que mes autorisations personnelles sont configurées pour pouvoir écrire dans mon répertoire personnel? Vous devez d'abord vérifier que l'indicateur d'écriture de votre répertoire personnel est écrit pour votre propre utilisateur. Si vous le faites, vous pourriez être victime du bogue décrit ci-dessous.

L'insecte

Quelques recherches sur Google ont finalement permis de trouver une personne présentant un problème similaire, ce qui m’a conduit au rapport de bogue Fedora. Pour ceux d'entre vous qui veulent lire à ce sujet: https://bugzilla.redhat.com/show_bug.cgi?id=772992

La solution de contournement

La solution de contournement au problème:

#verify you're not crazy
$ xauth list
  /usr/bin/xauth:  timeout in locking authority file /home/USER/.Xauthority
#use restorecon to reset it all
$ /sbin/restorecon -v -v /home/USER/.Xauthority 
$ /sbin/restorecon -v -v -R /home/USER/
#log out of the remote system
$ exit

Lorsque vous revenez dans SSH, tout devrait bien se passer et vous devriez être en mesure de transférer à nouveau votre session X avec succès.

EDIT (et autres solutions de rechange):

Juste pour être aussi complet que possible, d'autres utilisateurs ont indiqué dans le rapport de bogue que le correctif ci-dessus ne fonctionnait pas pour eux - cela m'était arrivé par la suite. Une autre tentative de contourner le problème a été (je n'ai pas vérifié cette solution de contournement personnellement):

# setsebool -P use_nfs_home_dirs 1

Une autre personne a mentionné quelque chose à propos de GDM, que je n'ai aucune connaissance. Si cela vous concerne, je vous recommande de lire son message dans BugZilla et de voir si son commentaire vous dit quelque chose.

La configuration de SELinux est la toute première chose à vérifier, avec ...

*/usr/sbin/sestatus*

ou

*/usr/sbin/sestatus -v*

Si la configuration de SELinux est définie sur "Enforcing", cela peut être à l' origine du problème "xauth" .

 /usr/sbin/setenforce 0

Vous pouvez le définir provisoirement en mode "autorisé" comme suit (pour pouvoir exclure ce problème en tant que cause première du problème) .

Suivez ensuite un didacticiel SELinux pour mettre en place une configuration appropriée ou la désactiver si vous préférez une autre méthode de sécurité (par exemple, éditez le fichier de configuration / etc / selinux / config dans RHEL v.6).