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.
