Lorsque je l’utilise ssh -Xsur mon Mac (sous OS X 10.6.7) pour me connecter à ma machine 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; utiliser de fausses données d'authentification pour le transfert X11.

Est-ce que je peux faire quelque chose pour que cet avertissement disparaisse? Si non, puis-je l'ignorer en toute sécurité?

Le transfert X11 semble bien fonctionner, même si je vois ce message:

Xlib: L'extension "RANDR" manque dans l'affichage "localhost: 10.0".

Est-ce lié à l'avertissement? (Je suppose que non. Si ce n'est pas le cas, je poserai une nouvelle question à ce sujet.)

Une raison quelconque pour laquelle vous ne souhaitez pas utiliser le drapeau -Y au lieu du drapeau -X?

Tout simplement, la différence entre -X et -Y est que -Y active le transfert X11 de confiance.

Si vous venez ici en 2015: même si tout le reste est configuré correctement, cela peut également arriver sous Mac OS X 10.10 Yosemite, lorsque vous utilisez ssh -Xet exécutez une version de XQuartz <= 2.7.7. La cause première est que les sockets d'affichage X11 sont écrits en dehors du chemin de recherche xauth: numéro n ° 2068 dans le suivi XQuartz.

Edit: Un correctif XQuartz a depuis été publié sur la nouvelle page d’accueil, xquartz.org , et l’installation de la dernière version à partir de cet emplacement (actuellement la version 2.7.9) résoudra le problème.

Si vous recevez le même message même lorsque vous l'utilisez -Y, le xauthprogramme est peut-être manquant sur le serveur. Sur les systèmes de type Debian, vous avez besoin du xauthpaquet. Sur les systèmes de type RedHat, vous avez besoin du xorg-x11-xauthpaquet.

"Non approuvé" dans ce contexte signifie que vous ne faites pas confiance à la connexion. SSH utilisera des mesures de sécurité supplémentaires pour tenter de rendre le transfert X11 plus sûr. "Fiable" signifie que vous êtes absolument confiant que rien sur l'hôte distant n'aura accès à vos données Xauth et les utilisera pour surveiller vos frappes au clavier, par exemple.

Cette terminologie m'a en effet confondu pendant des années. Je pensais que les connexions "de confiance" étaient plus sûres. Mais c’est en réalité une option que vous êtes censé utiliser dans les situations où la connexion est fiable et que vous souhaitez exécuter, sans que des mesures de sécurité supplémentaires ne vous gênent. "Non approuvé" est celui qui rend (un peu) plus sûr de traiter avec un hôte distant non approuvé.

Une connexion "non sécurisée" tente de limiter ce qu'un chapeau noir pourrait vous faire en activant l'extension de sécurité X11 et en désactivant d'autres extensions dont vous n'avez pas besoin. C'est probablement pourquoi RandR est désactivé avec -X. Avez-vous besoin de pouvoir faire pivoter votre affichage X à partir de l'hôte distant?

Il est également important de noter que le transfert X11 "non approuvé" est désactivé après un certain temps pour vous empêcher de le laisser accidentellement. Les nouvelles tentatives d'ouverture de fenêtres échoueront par la suite. Cela m’a mordu plusieurs fois avant de lire suffisamment de documents pour comprendre ce qui se passait.

Je n'ai pas de configuration pouvant présenter ce comportement, c'est donc un coup dans le noir:

L'avertissement peut être supprimé si vous définissez la valeur ForwardX11Trustedsur "no"pour les hôtes qui émettent cet avertissement. Vous pouvez placer ceci dans ~/.ssh/configou /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>composant correspond à ce que vous tapez sur la ligne de commande (pas le nom d'hôte résolu) et peut inclure des caractères génériques.

ATTENTION (fatigué de lire des réponses incomplètes qui conduisent à une faille de sécurité)

1 / utiliser ssh -Y signifie ici avoir de fausses informations xauth qui sont mauvaises!

2 / 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, il se trouve dans / opt / X11 / bin

Résolution sécurisée:

1 / Activer la première option dans l' onglet Sécurité des préférences (Cmd-,) qui permet les connexions authentifiées

2 / ajouter

XAuthLocation /opt/X11/bin/xauth

dans $ HOME / .ssh / config

3 / ssh -X you_servertravaille de manière sécurisée

Si l'installation xauthne fonctionne pas correctement, un .Xauthorityfichier particulièrement corrompu pourrait être un fichier corrompu . Ce cas particulier a permis à certains clients X de fonctionner, mais pas à ceux avec une plus grande tendance à échouer avec les nouveaux écrans. Supprimer et recréer le .Xauthorityfichier peut résoudre ce problème.

Éliminer les problèmes côté serveur

Tout d’abord, éliminez tout problème côté serveur. Êtes-vous capable ssh -Xde n'importe quel autre hôte avec succès? Est-ce ssh -Yque le travail ssh -Xne fonctionne pas? 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 sous X11, par exemple), vous pouvez passer sshdu serveur à lui-même en utilisant une fausse session:

1. export DISPLAY=:44# (Bourne shell) ou
   setenv DISPLAY :44# (csh / tcsh)
2. xauth add $DISPLAY MIT-MAGIC-COOKIE-1 1234 # Cookie Bogus juste pour ce test
3. ssh -X localhost env |grep DISPLAY

Résultat attendu: une variable DISPLAY doit être définie sur 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 xauthcommande peuvent être manquantes; ou la configuration de sshd peut être configurée pour refuser l'accès à X11).

Sur Mac: vérifiez que Xquartz est à jour

Selon la réponse de Will Angley

Examiner la ssh -vv -Xsortie

Le message d'erreur que vous citez est un symptôme qui peut avoir plusieurs causes. Réessayez avec , ce qui devrait vous donner des indices supplémentaires sur l’échec de la configuration du tunnel X11.ssh -X -vv remotehost

Voyez-vous le message suivant apparaître?

debug1: pas de programme xauth.

1. Prenez note de l'emplacement de la commande sur votre système client xauth:

   quel xauth

2. Ajoutez ce qui suit à la fin de votre ~ / .ssh / config (et ajoutez un commentaire pour vous rappeler de le conserver dans le futur):

   Hôte *
       XAuthLocation / opt / X11 / bin / xauth
   

   Ajustez ce chemin en fonction des résultats de l'étape 1 - Crédits à Jan-Willem Arnold

Comme cela a déjà été expliqué ci-dessus, les éléments suivants ont fonctionné pour moi:

Editez ~ / .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'avais déjà la dernière version de XQuartz 2.7.11 installée, mais je pense avoir également mis à jour le système d'exploitation plusieurs fois depuis. J'ai réinstallé XQuartz 2.7.11, et maintenant cela fonctionne bien.

xauth add `hostname` / unix: 10 MIT-MAGIC-COOKIE-1` openssl rand -hex 16`