“Su” avec erreur “connexion X11 rejetée à cause d'une authentification incorrecte”

En tant que root, je me connecte à un hôte distant pour exécuter une commande. Seul "standarduser" a le fichier id approprié et le bon fichier .ssh / config, je change donc d'abord d'utilisateur:

su standarduser -c 'ssh -x remotehost ./remotecommand'

La commande fonctionne bien, mais malgré le fait que j'ai utilisé "-x" (désactiver X11-Forwarding) et que X11Forwards soit désactivé /etc/ssh/ssh_config, je reçois toujours le message d'erreur suivant:

X11 connection rejected because of wrong authentication.

Je ne reçois pas le message d'erreur lorsque je suis connecté en tant que "utilisateur standard".

C'est assez ennuyeux car j'aimerais intégrer la commande dans un fichier de travail cron. Je comprends que le message d'erreur fait référence à la mauvaise authentification du fichier .XAuth de root, mais je n'essaie même pas de me connecter via X11.

Pourquoi "ssh -x" ne désactive-t-il pas la connexion X11 et ne renvoie-t-il pas le message d'erreur?

UPDATE : Le message ne s'affiche que lorsque je suis connecté à un écran, lorsque j'utilise la commande indiquée ci-dessus sur la machine locale elle-même (sans écran), je ne reçois pas de message d'erreur. Cela devrait donc également convenir à Cron. .

J'ai également lancé la même commande avec -vet étonnamment eu le message d'erreur FIRST, même avant les informations d'état de SSH:

root@localhost:~# su standarduser -c 'ssh -x remotehost ./remotecommand'
X11 connection rejected because of wrong authentication.
OpenSSH_6.2p2 Ubuntu-6ubuntu0.1, OpenSSL 1.0.1e 11 Feb 2013

Ceci m’a amené au problème lui-même, ce n’est PAS le sshqui envoie le message d’erreur, c’est su:

root@localhost:~# su standarduser -c 'echo Hi'
X11 connection rejected because of wrong authentication.
Hi

Pourquoi ai-je seulement cette erreur à l'intérieur screen? Comment puis-je désactiver ce message d'erreur?

On dirait que votre racine manque d'un cookie magique X11 dans le .Xauthorityque vous standarduserpossédez. Voici comment résoudre ce problème.

VERSION COURTE (merci à @bmaupin )

standarduser@localhost:~$ xauth list | grep unix`echo $DISPLAY | cut -c10-12` > /tmp/xauth
standarduser@localhost:~$ sudo su
root@localhost:~$ xauth add `cat /tmp/xauth`

Attention: vérifiez les backticks! Ils ne peuvent pas être remplacés par des citations! Vous devez être sudoinstallé pour poursuivre la deuxième commande!

VERSION LONGUE ORIGINALE

Pour résoudre le problème, commencez par déterminer quel numéro d'affichage standarduserutilise:

standarduser@localhost:~$ echo $DISPLAY
localhost:21.0

Dans ce cas c'est 21.0. Deuxièmement, affichez standarduserla liste des cookies:

standarduser@localhost:~$ xauth list
localhost/unix:1  MIT-MAGIC-COOKIE-1  51a3801fd7776704575752f09015c61d
localhost/unix:21  MIT-MAGIC-COOKIE-1  0ba2913f8d9df0ee9eda295cad7b104f
localhost/unix:22  MIT-MAGIC-COOKIE-1  22ba6595c270f20f6315c53e27958dfe
localhost/unix:20  MIT-MAGIC-COOKIE-1  267f68b51726a8a381cfc10c91783a13

Le cookie pour l' 21.0affichage est le deuxième de la liste et se termine par 104f.

La dernière chose à faire est d'ajouter ce cookie à la racine .Xauthority. Connectez-vous en tant que root et procédez comme suit:

root@localhost:~$ xauth add localhost/unix:21  MIT-MAGIC-COOKIE-1  0ba2913f8d9df0ee9eda295cad7b104f

Voici comment vous pouvez atténuer l' X11 connection rejected because of wrong authenticationerreur lorsque vous vous exécutez en sutant qu'utilisateur différent dans le script Bash ou screen.

Merci à ce gars pour l'inspiration.

Une solution plus simple:

1.- ssh user@host

2.- $ sudo su

3.- # xauth merge /home/user/.Xauthority

C'est tout

Bien sûr, la $DISPLAYvariable doit être définie.

Mes besoins étaient légèrement différents, j'ai donc proposé une solution légèrement différente. J'avais besoin de la possibilité d'exécuter une application X11 en tant qu'un autre utilisateur (qui n'est pas root). En cours d’exécution de CentOS, je n’ai donc pas le doux outil gksudo que les chiens chanceux avec Ubuntu ont pour faire la magie Xauth.

Je ne voulais vraiment pas créer des scripts personnalisés uniquement pour me connecter, changer d'utilisateur et exécuter une application; cela me semble un peu superflu.

La première étape:

Autoriser le transfert de $ XAUTHORITY sur plusieurs sessions sudo.

Ajoutez cette ligne sous le reste des instructions env_keep dans / etc / sudoers:

Defaults    env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"

Deuxième étape:

Autorisez votre utilisateur cible à lire votre .Xauthority (ouais, je sais, criez SÉCURITÉ! Tout ce que vous voulez). Pour ceux qui veulent juste la possibilité d'exécuter des commandes en tant que root, ceci peut être ignoré.

L'utilisateur cible partage le même groupe que moi, aussi je n'active que les autorisations de lecture de groupe:

$ chmod g+r user ~/.Xauthority

Troisième étape:

CentOS ne renseigne pas la valeur de $ XAUTHORITY par défaut. Ajoutez une ligne à votre profil (le mien est ~ / .bash_profile):

export XAUTHORITY=$HOME/.Xauthority

C'est ça. Pas plus de peaufinage. Aucune écriture .XML pour faire fonctionner PolicyKit. Aucun script en cours d'exécution pour chaque connexion. Pas besoin de sudo deux fois pour copier le xauth. A partir de là, vous pouvez simplement:

$ sudo -u user xcalc

Fonctionne très bien avec MobaXTerm.

Vous devez basculer complètement sur l'utilisateur cible, c'est-à-dire utiliser " -" avec su( su - standarduser ...). Si ce n'est pas le cas, le contenu X de la racine sera déplacé dans l'environnement.

Étant donné que je suis souvent root sur un partage de fichiers réseau à la racine, aucune des solutions ci-dessus ne fonctionne pour moi. (xubuntu 14.04). J'ai mis en place le script suivant, qui fonctionne sur mon système. Cela peut fonctionner sur le vôtre. Là encore, ce n'est peut-être pas le cas, mais c'est gratuit d'essayer ...

Je suppose que j'ai ssh'd en utilisant l'option -Y.

#!/bin/bash  
if [[ $DISPLAY =~ localhost(:[[:digit:]]+) ]] ;then
    port=${BASH_REMATCH[1]}
else
    echo "Unexpected DISPLAY $DISPLAY"
    exit 1
fi
h=$(hostname)
cookie=$(xauth list|grep $h.*$port)
sudo -i xauth -i add $cookie
sudo -i $*

Dans mon cas, lorsque j'ai rencontré cette erreur, j'avais un répertoire utilisateur chiffré. Après avoir appelé ecrypt-mount-private, il s'est débarrassé de l'erreur et m'a permis de continuer le transfert X11.

Pour déterminer si votre dossier de base est crypté, vous pouvez essayer (selon cette réponse ): ls -A /home. Si vous voyez un .ecryptfsdossier, votre répertoire personnel est probablement chiffré. Dans ce cas, vous pouvez essayer d'exécuter la commande que j'ai indiquée au début de la réponse.