web-dev-qa-db-fra.com

"su" avec l'erreur "Connexion X11 rejetée en raison d'une mauvaise authentification"

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 fichier .ssh/config correct, donc je change d'abord d'utilisateur:

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

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

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 tâche cron. Je comprends que le message d'erreur fait référence à une mauvaise authentification du fichier .XAuth de la racine, mais je n'essaie même pas de me connecter via X11.

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

UPDATE : Le message ne s'affiche que lorsque je suis connecté dans un écran, lorsque j'utilise la commande indiquée ci-dessus sur la machine locale elle-même (sans écran), je n'obtiens pas de message d'erreur, donc cela devrait être aussi bien avec cron.

J'ai également démarré la même commande avec -v et, de façon surprenante, a obtenu le message d'erreur EN PREMIER, avant même 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

Cela m'a conduit au problème lui-même, ce n'est PAS le ssh qui lance le message d'erreur, c'est su:

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

Pourquoi est-ce que je ne reçois cette erreur que dans screen? Comment désactiver ce message d'erreur?

bashgnu-screensuxauth
53
Stefan M

On dirait que votre racine manque de X11 cookie magique dans le .Xauthority, que possède votre standarduser. 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 astuces! Ils ne peuvent pas être remplacés par des guillemets! Vous avez besoin de Sudo installé pour continuer la deuxième commande!

VERSION LONGUE ORIGINALE

Pour résoudre les problèmes, commencez par détecter le numéro d'affichage standarduser utilisé:

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

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

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 le 21.0 L'affichage est le deuxième de la liste et se termine par 104f.

La dernière chose à faire est d'ajouter ce cookie particulier au .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 atténuer le X11 connection rejected because of wrong authentication erreur lorsque vous exécutez su en tant qu'utilisateur différent dans le script Bash ou screen.

Merci à ce gars pour l'inspiration.

81
Neurotransmitter

Une solution plus simple:

1.- ssh user@Host

2.- $ Sudo su

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

C'est tout

Bien sûr $DISPLAY la variable doit être définie.

38
Juan

Mes besoins étaient légèrement différents, j'ai donc trouvé une solution légèrement différente. J'avais besoin de pouvoir exécuter une application X11 en tant qu'autre utilisateur (qui n'est pas root). Exécuter CentOS, donc je n'ai pas l'outil gksudo doux que les chiens chanceux avec ubuntu ont qui fait la magie Xauth.

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

Première étape:

Permettre que $ XAUTHORITY soit reporté sur les sessions Sudo.

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

Defaults    env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"

Deuxième étape:

Permettez à votre utilisateur cible de lire votre .Xauthority (ouais je sais, criez SECURITY! Tout ce que vous voulez). Pour ceux qui veulent simplement pouvoir exécuter des commandes en tant que root, cela peut être ignoré.

L'utilisateur cible partage le même groupe que moi, donc j'active simplement les autorisations de lecture de groupe:

$ chmod g+r user ~/.Xauthority

Troisième étape:

CentOS ne remplit 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. Plus de peaufinage. Pas d'écriture .XML pour que PolicyKit fonctionne. Aucun script en cours d'exécution pour chaque connexion. Pas besoin de Sudo deux fois pour copier le xauth. À partir de maintenant, vous pouvez simplement:

$ Sudo -u user xcalc

Fonctionne très bien avec MobaXTerm.

7
W Smith

Vous devez basculer complètement vers l'utilisateur cible, c'est-à-dire utiliser "- "avec su (su - standarduser ...). Sinon, les éléments X de root seront traînés dans l'environnement.

1
Jerry Epas

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 départ est chiffré, vous pouvez essayer ceci (selon cette réponse ): ls -A /home. Si vous voyez un .ecryptfs, alors votre répertoire personnel est probablement crypté, auquel cas vous pouvez essayer de faire la commande que j'ai mise au début de la réponse.

0
henry

Étant donné que je roote fréquemment sur un partage de fichiers réseau compressé, aucune des solutions ci-dessus n'a fonctionné 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 pour essayer ...

L'hypothèse est que j'ai utilisé ssh 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 $*
0
Gerard