Proxy PuTTY X11: tentative du protocole d'autorisation incorrect
J'essaie de me connecter à un serveur Ubuntu pour travailler sur Qt-creator. Avant que tout ne se passe mal, j'ai suivi ce tutoriel . J'ai téléchargé PuTTY et Xming et tout fonctionnait parfaitement.
puis, tout à coup, alors que je travaillais sur Qt-creator, je ne pouvais enregistrer aucune modification. J'ai donc fermé Qt-creator et redémarré la session PuTTY. il m'a demandé son nom d'utilisateur et son mot de passe (comme d'habitude), puis après s'être connecté au serveur et quand j'ai essayé de lancer Qt-creator (comme d'habitude), le message suivant apparaît:
PuTTY X11 proxy: wrong authorisation protocol attempted
Can't open display: localhost:10.0
alors, j'ai essayé de résoudre le problème en utilisant deux approches trouvées sur Internet:
la première consiste à obtenir le dpyname protoname hexkey en utilisant:
xauth list
qui devrait retourner la clé qui est ensuite pourrait être ajouté en utilisant:
xauth add
Cependant, cela ne fonctionnait pas car la commande xauth list ne renvoyait rien.
la deuxième solution était d'aller à:
./etc/ssh/sshd_config
ouvrez le fichier: sshd_config et éditez la ligne ForwardX11Trusted pour lire yes, et si aucune telle ligne n'existe, ajoutez-la.
ForwardX11Trusted yes
puis redémarrez le serveur ssh et cela devrait fonctionner.
Cependant, cela n'a pas fonctionné non plus. Je ne pouvais pas ouvrir le fichier sshd_config en utilisant xdg-open ou gedit et le même message apparaît à nouveau.
alors pourquoi cela se produit-il et quelle est la solution?
Lorsque je me suis connecté en tant que su, après quelques erreurs de type "proxy PuTTY X11: tentative d'autorisation par un protocole d'autorisation incorrect", j'ai compris qu'il s'agissait d'un problème d'authentification. Ensuite, je me suis rappelé de copier le fichier .Xauthority de mon propre répertoire profile/home vers/root. Problème résolu!
Résolu.
Je l'ai résolu en utilisant un mélange des deux mentionnés ci-dessus.
1. J'ai ajouté la ligne suivante à '/ etc/ssh/sshd_config'
ForwardX11Trusted yes
2. J'ai installé xauth en utilisant
Sudo apt-get install xauth
xauth list était vide pour moi avant le redémarrage. Il a toutefois été rempli après le redémarrage. J'ai fait xauth list après l'avoir testé avec PuTTY.
Ensuite, j'ai redémarré ssh et cela a fonctionné. Yay!
Remarque: ce que j’ai réellement fait est de redémarrer mon Raspberry Pi
J'ai eu un problème similaire sur un serveur au travail parce que le dossier de base manquait d'espace disque. Une fois connecté, il ne pouvait pas écrire le fichier Xauthority et ... ne pouvait pas transférer.
Libérer de l'espace a résolu le problème.
J'imagine que vous auriez un problème similaire si le dossier personnel ou les autorisations .Xauthority étaient définis de manière incorrecte afin que vous n'ayez pas accès en écriture.
Dans mon cas, j’ai remarqué que je pouvais ouvrir l’affichage avec la racine, mais j’étais en train de faire une su-grid, et cette grille utilisateur était celle avec le problème,
la solution consistait à fermer cette session et à ouvrir une nouvelle session directement avec grid, et cela a fonctionné, quelque chose à propos de la su-grid échouait ...
J'ai eu un problème similaire sur un serveur. La raison en était que l'utilisateur a eu le mauvais numéro d'affichage (DISPLAY = localhost: 10.0). Lorsque l'utilisateur se connecte au serveur via SSH (en tant qu'utilisateur appelé test1), il obtient DISPLAY = localhost: 11.0. Lorsqu'il se connecte en tant qu'un autre utilisateur, puis qu'il devient utilisateur (test1), il obtient un numéro d'affichage incorrect (DISPLAY = localhost: 10.0). Quand je règle le nombre de droit de DISPLAY (DISPLAY = localhost: 11.0), cela fonctionne.