Pourquoi est-ce que je reçois ce message de xauth: "délai d'expiration dans le fichier d'autorité de verrouillage / home / <user> /.Xauthority"?
Lors de la tentative de connexion SSH à un hôte, j'ai reçu le message suivant de 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 graphique X11 via une connexion SSH, donc j'avais besoin de xauth pour pouvoir créer un $HOME/.Xauthority fichier avec succès, mais comme ce message l'indiquait, ce n'était clairement pas le cas.
Les tentatives pour exécuter des applications basées sur X11, telles que xeyes ont été accueillies avec ce message:
$ 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 strace sur le système distant où xauth échoue vous montrera ce qui se déclenche 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 xauth tente 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 pour .Xauthority, donc leur simple suppression résout le problème.
$ rm -fr .Xauthority-*
Une fois les fichiers supprimés, quittez la connexion SSH, puis reconnectez-vous. Cela permettra à xauth de s'exécuter à nouveau 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
$
Maintenant, nous pouvons exécuter xauth list et applications 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 post intitulé: xauth: erreur de verrouillage du fichier d'autorité .Xauthority [linux, ssh, X11] qui mentionne l'utilisation de xauth -b pour casser tous les fichiers de verrouillage qui pourraient traîner. La page de manuel de xauth semble sauvegarder ceci:
-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.
Références
La racine du problème pourrait être que vous n'avez aucune autorisation 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 d'é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 bogue dans Fedora OS et ses dérivés, comme je l'ai compris plus tard. Si le problème n'est pas indiqué par la réponse acceptée et/ou que vous n'êtes pas sur Fedora, RedHat, Korora, etc., cela ne vous aidera pas.
Le problème
Comme l'a dit l'utilisateur slm, l'exécution de strace vous donnera une indication du problème, mais dans le cas de ce bogue particulier, la sortie est différente:
$ 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 retour EACCES, qui est une autorisation refusée. C'est différent du problème de l'utilisateur slm, où il avait le code retour EEXIST, ce qui signifie que le fichier existe. Donc, pour le code retour EACCES, la première chose à vérifier est évidemment la suivante: mes autorisations personnelles sont-elles configurées pour que je puisse écrire dans mon répertoire personnel? Vous devez d'abord vérifier que vous avez le drapeau d'écriture sur votre répertoire personnel pour votre propre utilisateur. Si vous le faites, vous pourriez être victime du bogue décrit ci-dessous.
L'insecte
Grâce à quelques recherches sur Google, j'ai finalement pu trouver quelqu'un avec un problème similaire, et cela m'a conduit au rapport de bug de Fedora. Pour ceux d'entre vous qui souhaitent en savoir plus à ce sujet: https://bugzilla.redhat.com/show_bug.cgi?id=772992
La solution de contournement
La solution à ce 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 vous connectez SSH, cela devrait aller à ce stade et vous devriez être en mesure de transférer à nouveau avec succès votre X-session.
EDIT (et autres solutions alternatives):
Juste pour être aussi complet que possible, d'autres utilisateurs ont déclaré dans le rapport de bogue que le correctif ci-dessus ne fonctionnait pas pour eux - il s'est avéré que cela fonctionnait pour moi. Une autre tentative pour 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 mentionne quelque chose à propos de GDM, dont je n'ai aucune connaissance. Si cela vous concerne, je vous recommande de lire son article dans BugZilla et de voir si son commentaire signifie quelque chose pour vous.
Pour moi, deux étapes:
- A créé un nouvel utilisateur. Connectez-vous en tant que nouvel utilisateur et essayez X forward en utilisant des commandes comme feh.
- Reconnectez-vous en tant qu'ancien utilisateur et utilisez le fichier ~/.Xauthority du nouvel utilisateur pour remplacer l'ancien ~/.Xauthority.
La configuration SELinux est la toute première chose à vérifier, avec ...
*/usr/sbin/sestatus*
ou
*/usr/sbin/sestatus -v*
Si la configuration SELinux est définie sur "Enforcing", cela peut provoquer le problème "xauth".
/usr/sbin/setenforce 0
Vous pouvez le régler provisoirement sur le mode "permis" comme suit, (pour pouvoir exclure ce problème comme cause première du problème).
Suivez ensuite un tutoriel SELinux pour mettre en place une configuration appropriée, ou désactivez-la si vous préférez une autre méthode de sécurité, (par exemple en modifiant le fichier de configuration / etc/selinux/config dans RHEL v. 6)