Que signifie «avertissement: échec de la configuration du transfert X11 non approuvé: données de clé xauth non générées» lorsque vous utilisez ssh avec -X?
Lorsque j'utilise ssh -X sur mon Mac (exécutant OS X 10.6.7) pour me connecter à ma boîte Ubuntu (11.04), je reçois l'avertissement suivant:
Avertissement: échec de la configuration du transfert X11 non approuvé: données de clé xauth non générées Avertissement: aucune donnée xauth; en utilisant de fausses données d'authentification pour le transfert X11.
Puis-je faire quelque chose pour faire disparaître cet avertissement? Sinon, puis-je l'ignorer en toute sécurité?
Le transfert X11 semble fonctionner correctement, bien que je vois ce message:
Xlib: extension "RANDR" manquante sur l'affichage "localhost: 10.0".
Est-ce lié à l'avertissement? (Je suppose que non. Si ce n'est pas le cas, je déposerai une nouvelle question à ce sujet.)
Une raison pour laquelle vous ne souhaitez pas utiliser l'indicateur -Y au lieu de l'indicateur -X?
Tout simplement, la différence entre -X et -Y est que -Y permet un transfert X11 de confiance.
Si vous venez ici en 2015: même si tout le reste est correctement configuré, cela peut également se produire sur Mac OS X 10.10 Yosemite, lors de l'utilisation de ssh -X et exécutant une version XQuartz <= 2.7.7. La cause principale est que les sockets d'affichage X11 sont écrites en dehors du chemin de recherche xauth: issue # 2068 dans le tracker XQuartz.
Edit: Un XQuartz fixe a depuis été publié sur la nouvelle page d'accueil, xquartz.org , et l'installation de la dernière version à partir de là (actuellement 2.7.9) contournera le problème.
Si vous obtenez le même message même lorsque vous utilisez -Y, le programme xauth est peut-être manquant sur le serveur. Sur les systèmes de type Debian, vous avez besoin du paquetage xauth. Sur les systèmes de type RedHat, vous avez besoin du xorg-x11-xauth paquet.
"Non approuvé" dans ce contexte signifie que vous ne faites pas confiance à la connexion. SSH utilisera des mesures de sécurité supplémentaires pour essayer de rendre le transfert X11 plus sûr. "Trusted" signifie que vous êtes tout à fait sûr qu’aucun sur l’hôte distant n’aura accès à vos données Xauth et ne les utilisera pour surveiller vos frappes par exemple.
Cette terminologie m'a en fait dérouté pendant des années. Je pensais que les connexions "de confiance" étaient plus sûres. Mais en fait, c'est une option que vous êtes censé utiliser dans les situations où la connexion IS digne de confiance et que vous souhaitez exécuter des choses sans que des mesures de sécurité supplémentaires ne vous gênent. "Non fiable" est celui qui rend il est (un peu) plus sûr de traiter avec un hôte distant non fiable.
Une connexion "non approuvée" tente de limiter ce qu'un chapeau noir pourrait vous faire en engageant l'extension de sécurité X11 et en désactivant d'autres extensions dont vous (espérons-le) n'avons pas besoin. C'est probablement pourquoi RandR est désactivé avec -X. Avez-vous besoin de pouvoir faire pivoter votre écran X à partir de l'hôte distant?
Il est également important de noter que le transfert X11 "non fiable" s'éteint après un certain temps pour vous empêcher de le laisser accidentellement activé. De nouvelles tentatives d'ouverture de fenêtres échoueront juste après cela. Cela m'a mordu plusieurs fois avant de lire suffisamment de documents pour comprendre ce qui se passait.
MÉFIEZ-VOUS (fatigué de lire des réponses incomplètes qui mènent à une faille de sécurité)
utiliser ssh -Y signifie ici avoir de fausses informations xauth qui sont mauvaises!
ssh -X devrait fonctionner car XQuartz, une fois activé, utilise xauth. Le seul problème est que ssh recherche xauth dans/usr/X11R6/bin et sur macos avec XQuartz c'est dans/opt/X11/bin
Résolution sécurisée:
Activez la première option dans l'onglet Sécurité des préférences (Cmd-,) qui permet les connexions authentifiées
ajoutez ce qui suit à
$HOME/.ssh/configXAuthLocation /opt/X11/bin/xauthssh -X you_serverfonctionne de manière sécurisée
Exclure les problèmes côté serveur
Tout d'abord, vous devez exclure tout problème côté serveur. Es-tu capable de ssh -X d'un autre hôte avec succès? Est-ce que ssh -Y travailler tout en ssh -X non? Dans les deux cas, supposez que ssh + X11 est correctement configuré sur votre serveur et passez à la section suivante.
Si vous n'êtes pas en mesure de vérifier cela (vous n'avez qu'un seul ordinateur portable exécutant X11, par exemple), vous pouvez ssh du serveur à lui-même en utilisant une fausse session:
export DISPLAY=:44# (Bourne Shell) ousetenv DISPLAY :44# (csh/tcsh)xauth add $DISPLAY MIT-MAGIC-COOKIE-1 1234# Cookie Bogus juste pour ce testssh -X localhost env |grep DISPLAY
Résultat attendu: une variable DISPLAY doit être définie à l'extrémité distante de la session ssh-to-self. Si vous n'obtenez aucun résultat, votre serveur est probablement mal configuré (par exemple, les bibliothèques X11 et/ou la commande xauth peuvent être manquantes; ou la configuration sshd peut être définie pour refuser l'accès X11)
Sur Mac: vérifiez que Xquartz est à jour
Selon la réponse de Will Angley
Examiner ssh -vv -X production
Le message d'erreur que vous citez est un symptôme qui peut avoir plusieurs causes. Réessayez avec ssh -X -vv remotehost, qui devrait vous donner des indices supplémentaires sur la raison de l'échec de la configuration du tunnel X11.
Voyez-vous le message suivant apparaître?
debug1: Pas de programme xauth.
- Prenez note de l'emplacement sur votre système client, où réside la commande
xauth:quel xauth
- Ajoutez ce qui suit à la toute fin de votre ~/.ssh/config (et ajoutez un commentaire pour vous rappeler de le conserver à l'avenir):
Hôte * XAuthLocation /opt/X11/bin/xauth
Ajustez ce chemin selon les résultats de l'étape 1 - Crédits à Jan-Willem Arnold
Je n'ai pas de configuration qui puisse présenter ce comportement, c'est donc une photo dans le noir:
L'avertissement peut être supprimé si vous définissez ForwardX11Trusted à "no" pour les hôtes qui donnent cet avertissement. Vous pouvez placer ceci dans ~/.ssh/config ou /etc/ssh/ssh_config, et vous pouvez rendre l'option spécifique à un hôte particulier en incluant Host <hostname> sur la ligne ci-dessus. le <hostname> le composant correspond à ce que vous tapez sur la ligne de commande (pas le nom d'hôte résolu), et il peut inclure des caractères génériques.
Si l'installation de xauth ne fonctionne pas correctement, un cas particulièrement ennuyeux pourrait être un fichier .Xauthority Corrompu. Ce cas particulier a permis à certains clients X de fonctionner, mais pas à d'autres avec une plus grande tendance à l'échec avec des écrans plus récents. La suppression et la recréation du fichier .Xauthority Peuvent résoudre ce problème.
Comme cela a déjà été expliqué ci-dessus, les éléments suivants ont fonctionné pour moi:
Modifier ~/.ssh/config pour ajouter les lignes
Host *
XAuthLocation /opt/X11/bin/xauth
et maintenant ssh -X hostname fonctionne (XQuartz 2.7.11, macOS 10.4 Mojave)
J'ai déjà installé le dernier XQuartz 2.7.11, mais je pense que j'ai également mis à jour le système d'exploitation à plusieurs reprises depuis lors. J'ai réinstallé XQuartz 2.7.11, et maintenant cela fonctionne bien.