Question Que signifie «Avertissement: la configuration du transfert X11 non approuvé a échoué: les données de clé xauth non générées» signifient-elles lorsque ssh'ing avec -X?


Quand j'utilise ssh -X sur mon Mac (sous OS X 10.6.7) pour me connecter à ma boîte Ubuntu (11.04), je reçois l'avertissement suivant:

Avertissement: redirection X11 non fiable   Echec de l'installation: les données de la clé xauth ne sont pas   généré Avertissement: pas de données xauth;   Utilisation de fausses données d'authentification pour X11   expéditeur.

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" est manquante   affichez "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.)


112
2018-05-25 22:41


origine


Le programme xauth est-il installé sur le serveur Ubuntu? - slubman
sudo apt-get install xauth me dit "xauth est déjà la dernière version" - Daryl Spitzer
Une fois connecté au serveur Ubuntu, quel est le résultat de 'quel xauth'? - slubman
En effet, je pense que vous devriez lire cette explication: mail-archive.com/cygwin-xfree@cygwin.com/msg17927.html … Tu peux ignorer cet avertissement - slubman
cela peut parfois être dû à des problèmes avec votre fichier ~ / .Xauthority. Si vous le supprimez, il sera recréé lors de votre prochaine tentative de connexion. - michael


Réponses:


Une raison 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.


125
2018-02-01 22:02



Non, je n'étais tout simplement pas au courant du drapeau -Y lorsque j'ai écrit la question. Je crois que cela s'est avéré être une solution. Changez votre réponse pour que ce ne soit pas une question (et ce serait bien si vous expliquiez brièvement la différence entre -Y et -C) et je l’accepterai. - Daryl Spitzer
y at-il des cas où vous ne voudriez pas utiliser -Y au lieu de -X? - Rooster
@ Rooster pour les très vieux systèmes où -Y n'est pas supporté, je dirais - Petr
Conseil de dépannage: Exécutez "ssh -vv ..." et recherchez la ligne xauth et les messages d'erreur éventuels. Vous pouvez essayer d’exécuter la ligne xauth qu’elle affiche directement. Pour le mien, j'avais besoin que ce soit quelque chose comme "xauth list: 0" (fiable) pas "xauth -f / tmp / ssh ... list: 0" (non fiable). Quel -Y a corrigé et "ForwardX11Trusted yes" dans l'hôte distant / etc / ssh / ssh_config (ou ~ / .ssh / config) ont également été corrigés. - Curtis Yallop
Cette solution fonctionnait également avec Cygwin / X. - linux64kb


Si vous venez ici en 2015: même si tout le reste est configuré correctement, cela peut également arriver sur Mac OS X 10.10 Yosemite, lorsque vous utilisez ssh -X et exécuter 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: # 2068 dans le tracker XQuartz.

Edit: Un XQuartz corrigé a depuis été publié sur la nouvelle page d’accueil, xquartz.orget installer la dernière version à partir de là (actuellement la version 2.7.9) contournera le problème.


22
2018-05-13 15:09



Je vous remercie! j'ai eu aucune idée que le XQuartz I juste téléchargé depuis le haut de la page XQuartz n’est pas réellement la dernière version. - craigds
A noter que brew install xquartz installe actuellement la version 2.7.7 obsolète. - Martin Cleaver
brew install Caskroom/cask/xquartz devrait vous procurer le dernier XQuartz avec HomeBrew - Nick
Ou plus court brew cask install xquartz. - Franklin Yu


Si vous recevez le même message même en utilisant -Y, la xauth programme peut-être manquant sur le serveur. Sur les systèmes de type Debian, vous avez besoin de la xauth paquet. Sur les systèmes de type RedHat, vous avez besoin de la xorg-x11-xauth paquet.


14
2017-07-17 08:35





"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 certain qu'aucun utilisateur de l'hôte distant ne pourra accéder à vos données Xauth et les utiliser 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 approuvé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 (espérons-le). 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.


11
2018-02-17 17:36





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 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. la <hostname> Le 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.


8
2018-06-13 20:03



On peut utiliser ssh -Y faire un transfert X11 de confiance, mais comment peut-on réparer le non fiable? - Pavel Šimerda
J'ai la même erreur dans Redhat et maintenant je suis capable de la résoudre en éditant le fichier de configuration /etc/ssh/ssh_config à côté du client. Je vous remercie - Gangadhar Jannu


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


5
2017-08-01 17:43





Éliminer les problèmes côté serveur

Tout d’abord, vous devez exclure tout problème côté serveur. Es-tu capable de ssh -X de tout autre hôte avec succès? Est-ce que ssh -Y travailler tout en ssh -X n'est-ce 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 ssh du 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 le xauth la commande pourrait être manquante; ou la configuration sshd pourrait être configurée pour refuser l'accès à X11)

Sur Mac: vérifiez que Xquartz est à jour

Comme par La réponse de Angley

Examiner ssh -vv -X sortie

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

Voyez-vous le message suivant apparaître?

debug1: pas de programme xauth.
Si c'est le cas,

  1. Prenez note de l’emplacement de votre système client, le xauth la commande réside:
    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 cette trajectoire selon les résultats de l'étape 1 - Crédits à Jan-Willem Arnold

5
2017-08-18 16:34





IL FAUT SE MÉFIER (fatigué de lire des réponses incomplètes qui mènent à 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 Sécurité onglet des préférences (Cmd-,) qui permet des connexions authentifiées

2 / ajouter

XAuthLocation /opt/X11/bin/xauth

dans $ HOME / .ssh / config

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


4
2018-01-31 13:16