Chaque fois que je lance une connexion ssh de mon Mac à un système Linux (Debian), je reçois cet avertissement:

No xauth data; using fake authentication data for X11 forwarding.

Cela se produit également pour les outils utilisant ssh, tels que git ou mercurial.

Je veux juste apporter une modification locale à mon système afin d'éviter que cela n'apparaisse.

Remarque: J'ai un serveur X11 (XQuartz 2.7.3 (xorg-server 1.12.4)) sur mon Mac OS X (10.8.1) et il fonctionne correctement. Je peux démarrer l'horloge avec succès en local ou à distance.

Aucune des solutions affichées n'a fonctionné pour moi. Mon système client (ordinateur de bureau) exécute macOS 10.12.5 (Sierra). J'ai ajouté -vaux options pour la sshcommande et il m'a dit,

debug1: No xauth program.

ce qui signifie que le chemin d'accès au xauthprogramme n'est pas correct . (Sur cette version de macOS, le chemin d'accès xauthn'est pas standard.) La solution a été d'ajouter cette ligne à /etc/ssh/ssh_config(peut-être /etc/ssh/configdans certaines configurations) ou à ~/.ssh/config(si vous n'avez pas de droits d'administrateur):

XAuthLocation /opt/X11/bin/xauth

Maintenant, le message d'avertissement est parti.

Trouvé la cause, ma ~/.ssh/configétait incomplète, vous avez besoin des deux:

Host *
    ForwardAgent yes
    ForwardX11 yes

Mon erreur est que je n'ai inclus que l'option ForwardX11.

Laisser Ubuntu bash sur Windows 10 s'exécuter ssh -X pour obtenir un environnement graphique sur un serveur distant

• Première

Installez tout ce qui suit. Sur la fenêtre, installez Xming. Sur Ubuntu bash, utilisez sudo apt installpour installer ssh xauth xorg.

sudo apt install ssh xauth xorg

• Seconde

Allez dans le dossier contient le ssh_configfichier, le mien est /etc/ssh.

• Troisième

Modifier en ssh_configtant qu'administrateur (USE sudo). A l' intérieur ssh_config, supprimer la valeur de hachage #dans les lignes ForwardAgent, ForwardX11, ForwardX11Trusted, et définir les arguments correspondants yes.

# /etc/ssh/ssh_config

Host *
    ForwardAgent yes
    ForwardX11 yes
    ForwardX11Trusted yes

• 4ème

Dans le ssh_configfichier, supprimez le hachage #avant avant Port 22et Protocol 2ajoutez également une nouvelle ligne à la fin du fichier pour indiquer l'emplacement du fichier xauth XauthLocation /usr/bin/xauth. N'oubliez pas d'écrire votre propre chemin d'accès au fichier xauth.

# /etc/ssh/ssh_config

#   IdentifyFile ...
    Port 22
    Protocol 2
#   Cipher 3des
#   ...
#   ...
    ...
    ...
    GSSAPIDelegateCredentials no
    XauthLocation /usr/bin/xauth

• Cinquième

Maintenant que nous avons terminé l'édition du ssh_configfichier, enregistrez-le lorsque nous quittons l'éditeur. Maintenant, allez dans le dossier ~ou $HOME, ajoutez export DISPLAY=localhost:0à votre .bashrcfichier et enregistrez-le.

# ~/.bashrc
...
...
export DISPLAY=localhost:0

• Dernier

On a presque fini. Redémarrez votre shell bash, ouvrez votre Xmingprogramme et utilisez-le ssh -X yourusername@yourhost. Ensuite, profitez de l'environnement graphique.

ssh -X yourusername@yourhost

Le problème concerne également le sous-système Ubuntu sous Windows et le lien se trouve à l'adresse suivante:

https://gist.github.com/DestinyOne/f236f71b9cdecd349507dfe90ebae776

Remarque: le texte lié comprend 2 fautes de frappe ( XauthLocaionau lieu de XauthLocation)

Comme indiqué, il semble que xauthsur OS X, Yosemite a régressé pour adopter une ancienne version qui ne fonctionnait pas avec le $DISPLAYparamètre de XQuartz :

% xauth -V
1.0.9
% xauth generate $DISPLAY .
xauth: (argv):1:  bad display name "/private/tmp/com.apple.launchd(...)/org.macosforge.xquartz:0" in "add" command

Il y a un bug dans MacOS pour le moment. Je suis tombé sur ça aussi. Le correctif pour moi impliquait l’ajout du texte suivant à mon fichier .bash_profile

dispdir=`dirname $DISPLAY`
dispfile=`basename $DISPLAY`
dispnew="$dispdir/:0"
if [ -e $DISPLAY -a "$dispfile" = "org.x:0" ]; then
  mv $DISPLAY $dispnew
fi
export DISPLAY=$dispnew

Essentiellement, le nom du canal de fichier associé à votre racine X ne peut pas être manipulé correctement et doit donc être corrigé. :-)

Comprenant

XAuthLocation / opt / local / bin / xauth dans ~ / .ssh / config

dans mon macOS Sierra 10.12.6 a fonctionné pour moi. Un petit changement par rapport à la réponse 7).

Je viens de supprimer ~ / .Xauthority (machine de destination) de mon dossier racine et ssh -X 192.168.123.1 à nouveau et ik a fonctionné.

Dans mon cas, le problème de .Xauthority contenant le cookie Magic non transféré, Fabby sur http://askubuntu.com/questions/571116/ recommande le 2014-11-14 d'ajouter cette ligne à la fin du .bashrc ou . profile pour permettre le transfert de clés xauth entre utilisateurs lors de l'appel de su:

export $(dbus-launch)

J'ai ajouté aussi précédemment:

export XAUTHORITY=~/.Xauthority 

pour assurer à distance appelé avec ssh -X ̍ @ le trouvera.

Dans mon cas, Xauthority est un lien symbolique vers l'utilisateur d'origine /home//.Xauthority que je su depuis ...

  cd /home/<child_user>;ln -sf /home/<parent_user>/.Xauthority .xAuthority

avec les droits corrects:

  sudo chown <parent_user> /home/<parent_user>/.profile
  chmod a+rw /home/<parent_user>/.profile 

il est donc accessible à et à. sera en mesure de déclencher des applications sur et afficher le résultat X-windowed sur son écran local à travers le compte proxy!

CONSEIL: Consultez la liste xauth ... si le cookie magique est activé.

Je voudrais ajouter cela comme un commentaire, mais je n'ai pas assez de représentant. Ajouter une ligne supplémentaire à la solution de sorin a fonctionné pour moi.

Ouvrez votre fichier de configuration ssh avec vim ~/.ssh/config Ensuite ajoutez-y ces lignes:

Host *
    ForwardAgent yes
    ForwardX11 yes
    XAuthLocation /opt/X11/bin/xauth

Vous pouvez vérifier votre xauthposition avec:

which xauth