[ssh X11] probleme d'authorisation de DISPLAY

Support Debian
#1

Je vous expose le probléme.
Je me connecte en ssh via internet sur une debian testing
J’ai créer pour cela un utilisateur aux droits trés réduit.
Si je teste xclock, tout est OK
Maintenant, si je change d’utilisateur avec su, j’ai un problème de DISPLAY

Le display utilisé par ssh est le :10
J’ai à peu prêt cerné le problème: le fichier Xauthority
Avec l’utilisateur qui pose problème:

xauth list ordi1:0 MIT-MAGIC-COOKIE-1 4f0...71d4 [fe80::e2cb:4eff:fe12:1847]:0 MIT-MAGIC-COOKIE-1 4f0950175347af0f1ae2c01d6b6971d4 ordi1/unix:0 MIT-MAGIC-COOKIE-1 4f09...971d4

avec l’utilisateur de connexion ssh:

xauth list ordi1/unix:11 MIT-MAGIC-COOKIE-1 b641...91a6 ordi1/unix:10 MIT-MAGIC-COOKIE-1 e69d...6f752e

Je sens bien qu’il faut ajouter un truc du genre

Mais comme je ne maitrise pas ce sujet, j’aurais besoin de vos conseils.

#2

Salut mon message est hors sujet mais pourrais tu me dire comment tu fais pour te connecter par internet? Merci

#3

Je ne connais pas xauth, mais tu peux autoriser les connexions à X venant de localhost avec :

#4

L’utilisateur (par [mono]su[/mono]) n’est pas authentifié au niveau du serveur X.

Alors, juste après le [mono]su xxxx[/mono] (xxxx étant le nom de l’utilisateur que je ne connais pas),

Il se peut qu’il faille créer un fichier [mono]~/.Xauthority[/mono] (s’il était absent dans le répertoire personnel de l’utilisateur) pour que [mono]xauth[/mono] puisse y ajouter le cookie…

je te laisse remplacer les [mono]…[/mono] de [mono]e69d…6f752e[/mono] dans la commande suivante

EDIT: j’utilise [mono]su -l xxxx[/mono] pour que les variables d’environnement de l’utilisateur xxxx soient prises en compte et que certaines soient copiées :

[quote=“extrait de “man su””]…
Notez que le comportement par défaut pour l’environnement est le suivant :

Les variables d'environnement $HOME, $SHELL, $USER, $LOGNAME, $PATH et $IFS sont réinitialisées.

Si --login n'est pas utilisée, l'environnement est copié sauf pour les variables ci-dessus.

Si --login est utilisée, les variables d'environnement $TERM, $COLORTERM, $DISPLAY et $XAUTHORITY sont copiées si elles ont été définies.

…
[/quote]

@ kna : Fait gaffe avec [mono]xhost[/mono], surtout par le WEB => Gestion de la sécurité sous XWindow

EDIT:Ajout de [mono]&& chmod 600 ~/.Xauthority[/mono]

#5

Je me connecte depuis une machine via putty (j’ai fait un sujet dans truc et astuce la dessus).
j’ai déja tester d’ajouter le magic cookie comme tu l’indique, sans succés. Mais je ne l’ai fait que pour le display :10, je vais tenter pour le display :11 qui existe aussi chez l’utilisateur utilisé pour la connexion.
Et bien vu l’idée du su -l, je vais essayer.

#6

bon su -l, pas mieux

#7

J’avais du faire une boulette en copiant le magic cookie. ça fonctionne.
Par contre, j’ai l’impression que ce magic cookire change à chaque connexion. Il faudra donc faire la manip à chaque fois.
Pas terrible

#8

Effectivement, la variable [mono]$XAUTHORITY[/mono] est vide chez moi, Mais il faudrait que, avant de lancer [mono]su -l xxx[/mono], j’essaie : XAUTHORITY=$HOME/.Xauthority ; export XAUTHORITY

Ce qui permettrait de ne pas modifier le fichier [mono]/home/xxxx/.Xauthority[/mono], et il suffirait alors d’adapter le [mono]~/.bashrc[/mono] en conséquence, avec un [mono]if …[/mono] testant la si la valeur de [mono]$DISPLAY[/mono] n’est pas [mono]:0.0[/mono]

EDIT: Beh non: ça marche pas :angry: va falloir trouver autre chose…

#9

La variable $XAUTHORITY doit étre utile. Mais à quoi …

#10

[mono]$XAUTHORITY[/mono] sert à spécifier un fichier de remplacement pour [mono]~/.Xauthority[/mono].

[quote="“man xauth”"]…
-f authfile
This option specifies the name of the authority file to use.
By default, xauth will use the file specified by the XAUTHORITY environment variable or .Xauthority in the user’s home directory.
…[/quote]

Mais, même après “export”, je n’ai pas réussi à la faire prendre en compte dans un test avec [mono]xaut list[/mono] depuis l’autre compte utilisateur.

EDIT: En fait, j’avais pas été assez patient :

michel@debG53SW:~$ XAUTHORITY=/home/michel/.Xauthority
michel@debG53SW:~$ echo $XAUTHORITY; export XAUTHORITY
/home/michel/.Xauthority
michel@debG53SW:~$ su -l michel2
Mot de passe : 
michel2@debG53SW:~$ echo $XAUTHORITY
/home/michel/.Xauthority
michel2@debG53SW:~$ echo $DISPLAY
localhost:10.0
michel2@debG53SW:~$ xauth list
xauth:  timeout in locking authority file /home/michel/.Xauthority
michel2@debG53SW:~$

Ce serait donc une histoire de fichier verrouillé.

Je verrai ce soir avec [mono]flock[/mono], mais quand je commence à bidouiller comme ça, je finis toujours par trouver, (ou on me donne) beaucoup plus tard une solution toute faite et beaucoup mieux adaptée.

#11

je ne pourrais plus tester avant lundi, j’ai retrouvé ma place devant ma debian!

#12

Donc, je disais :[quote=“MicP”]…une solution toute faite et beaucoup mieux adaptée.…[/quote]ben voilà :root@debG53SW:~# apt-cache search sux sux - Encapsuleur autour de su qui tranfère vos accréditations (credentials) X root@debG53SW:~# Et ce n’est qu’un tout petit script => J’adore Linux. :007

#13

sux validé!
Malgré un message d’erreur, ça à l’air de bien fonctionner:

bash: impossible de régler le groupe de processus du terminlal (-1): Ioctl() inapproprié pour un périphérique bash: pas de contrôle de tâche dans ce shell