Comment déboguer "Connexion X11 rejetée en raison d'une mauvaise authentification"

J'ai un problème avec le transfert X via SSH. Je me bats depuis des lustres, mais personne ne semble aider.

Je prends maintenant un tact différent. Je voudrais savoir comment je déboguerais les erreurs?

Quels journaux dois-je consulter, quels indicateurs supplémentaires dois-je définir (-v, etc.) et que dois-je rechercher?

Modifier davantage:

Si je me connecte à Putty sur le serveur et que j'essaye xeyes, j'obtiens:

Proxy PuTTY X11: tentative de mauvais protocole d'autorisation Erreur: impossible d'ouvrir l'affichage: hôte local: 10.0

Si xauth generate $DISPLAYje reçois:

Proxy PuTTY X11: protocole d'autorisation incorrect tentéxauth: (argv): 1: impossible d'ouvrir l'affichage "localhost: 10.0".

Ma solution étape par étape:

1) Connectez-vous avec l'option -X racine de connexion à l'hôte distant

$ ssh -X root@192.168.1.39

2) Vérifiez si le fichier .Xauthority existant

[root @ localhost ~] # ls -al
[root @ localhost ~] # vim .Xauthority

3) copiez le fichier .Xauthority dans le répertoire de l'autre utilisateur

[root @ localhost ~] # cp .Xauthority / home / oracle /
cp: écraser `/home/oracle/.Xauthority '? y

4) définir les autorisations pour ce fichier

[root @ localhost ~] # chown oracle: oinstall .Xauthority
[root @ localhost ~] # chmod 0600 .Xauthority

5) Connectez-vous à l'utilisateur Oracle

[root @ localhost ~] # su - oracle

6) paramètre d'affichage dans localhost: 10.0

[oracle @ localhost ~] $ echo $ DISPLAY
localhost: 10.0
[oracle @ localhost ~] $ ls -al

7) répertorie les cookies xauth existants

[oracle @ localhost ~] $ xauth list
localhost.localdomain / unix: 11 MIT-MAGIC-COOKIE-1 310f1b02c1080e73059391c193a1881b
localhost.localdomain / unix: 10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb759

8) ajouter

[oracle @ localhost ~] $ xauth add localhost.localdomain / unix: 10 MIT-MAGIC-COOKIE-1 41843db100830a2aa352641ac47bb75

9) test

[oracle @ localhost ~] $ xclock

J'espère qu'ils servent! @wcaraza

Assurez-vous que l' xauthoutil SSH est installé sur le serveur SSH et que votre ~/.Xauthorityfichier est accessible en écriture. (Inexistant est également correct, tant qu'il xauthpeut le créer.)

Vérifiez si les données xauth sont mises à jour:

server$ xauth list

Essayez d'ajouter manuellement des données xauth factices (encore une fois, sur le serveur SSH) et voyez s'il y xautha des problèmes (par exemple, impossible de créer le fichier de verrouillage ou de modifier le fichier Xauthority lui-même):

server$ xauth add localhost:123 MIT-MAGIC-COOKIE-1 d7e2e4a8c5aa4430bfcc2abb436940d2

Si nécessaire, réexécutez sous strace.

Exécutez le service SSH en mode débogage, en définissant LogLevel DEBUG2dans la configuration du serveur ( /etc/ssh/sshd_config), ou en démarrant directement sshd en mode débogage:

server$ sshd -rddp 12234

(Dans cet exemple, 12234est le port SSH temporaire auquel vous devez vous connecter. N'importe quel port libre fera l'affaire.)

Ça marche, ça marche. haha.

ENFIN.

Après avoir découvert que ce n'était pas le système, en ajoutant un utilisateur de test (dont le transfert x a fonctionné "hors de la boîte"), j'ai pensé commencer à copier les fichiers de démarrage .bash * pour virginiser l'utilisateur "cassé".

Aucun des fichiers n'était différent, alors j'ai supprimé le répertoire .ssh des utilisateurs. Quand je suis entré, il a gémi à propos de "Le serveur a refusé notre clé", mais j'ai pu me connecter en utilisant un mot de passe. Une fois connecté, je pouvais x transférer parfaitement.

Je vais maintenant essayer de configurer à nouveau la clé et voir si je peux aussi le faire fonctionner. Ensuite, ce sera de retour à la normale.

Une autre chose qui peut provoquer ce problème est l'existence d'un ~/.ssh/rcfichier sur le serveur - la machine à laquelle vous vous connectez. Supprimez-le (ou renommez-le) pour résoudre le problème.

rm ~/.Xauth* puis reconnectez-vous.

Cela fonctionne pour moi. Pour plus de détails