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


53

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?


Exécutez à nouveau la commande et ajoutez-la -vaux options ssh, puis collez le résultat dans votre question.
Jenny D

Réponses:


80

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.


Intéressant. J'ai essayé cela, mais ça n'a pas fonctionné pour moi non plus. Dans mon cas particulier, je peux lancer presque n'importe quoi (un autre xterm, VirtualBox), mais je ne peux pas lancer gedit (j'obtiens la même erreur). Cependant, si je passe à root, je peux lancer gedit. J'ai suivi les instructions à la lettre mais rien. Quelque chose d'autre doit être faux.
luis.espinal

@ luis.espinal espérons que quelqu'un vous propose une solution à votre problème particulier.
TranslucentCloud

1
La version longue a fonctionné à merveille, mais la version courte s'est trompée sur centos avec "xauth: (argv): 1: bad", ajout "en ligne de commande"
Sam

1
version courte a fonctionné pour moi sur centos 7
tdc

1
sur Ubuntu 18.04.1 version courte fonctionne bien.
Simakis Panagiotis

38

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.


1
Cela semble prometteur mais un peu incomplet. Souhaitez-vous ajouter des informations sur la manière de définir une $DISPLAYvariable? Je crois que ce petit ajout jettera des voix supplémentaires à votre réponse.
TranslucentCloud

Cela a fonctionné pour moi alors que la réponse de @ TranslucentCloud n'a pas fonctionné. À l'origine, je rencontrais le problème en essayant d'exécuter le gestionnaire de SDK Android en tant que racine à partir de la ligne de commande FYI.
scottyseus

2
Cela n’a pas marché pour moi depuisxauth: file /root/.Xauthority does not exist
2015

2
tdc, c’est juste un avertissement, pas une erreur, xauth créera le fichier - si vous exécutez la commande une seconde fois, vous ne le verrez pas.
Vladimir Panteleev

1
Qui a besoin d'apprendre quoi que ce soit quand vous pouvez simplement copier et coller! Merci! Bien plus facile.
Sirènes

7

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.


C’était précisément ce dont j'avais besoin pour résoudre le problème que je rencontrais lors de l’obtention d’une console VM sur CentOS 7. Il me suffisait en fait de réaliser la troisième étape uniquement (et, bien sûr, d’assurer que X11Forwarding était réglé sur yes dans / etc / ssh / sshd_config). Merci.
darklion

Impressionnant! C'est la réponse! Merci @W Smith
tmow

1

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.


0

É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 $*

La ligne cookie=$(xauth list|grep $h.*$port)peut correspondre à plus que prévu si $ port se trouve dans la valeur du cookie. Plus sûr est: cookie=$(xauth list) cookie=${c%% *}ou cookie=$(xauth list |grep $h[^ ]*$port).
PePa

0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.