[X11] Affichage déporté et coupe-feu

Hubert Figuiere <hub@free.fr> wrote:

Activer le X11Forwarding sur la machine sur laquelle vous vous
connectez avec SSH. C'est dans /etc/sshd_config. C'est désactivé par
défaut sur bien des système (dont MacOS X)

C'est à dire ?

Je dois reconnaître que j'ai un peu de mal avec cette technique.

Sur la machine à piloter :

X11Forwarding=yes dans /etc/sshd_config

Sur la machine sur laquelle je travaille :

% ssh l'autre_machine
% start x

Est-ce bien cela ?

--
Jaques

Hubert Figuiere <hub@free.fr> wrote:

Activer le X11Forwarding sur la machine sur laquelle vous vous
connectez avec SSH. C'est dans /etc/sshd_config. C'est désactivé par
défaut sur bien des système (dont MacOS X)

C'est à dire ?

Je dois reconnaître que j'ai un peu de mal avec cette technique.

Sur la machine à piloter :

X11Forwarding=yes dans /etc/sshd_config

On l'appellera A

Sur la machine sur laquelle je travaille :

On l'appellera B

% ssh l'autre_machine
% start x

Non. On fait pas un startx. startx c'est pour lancer le serveur X et
tout le toutim. Ce qu'on veut c'est lancer des clients X.

Donc:

Après avoir changé la config et relancé sshd (sur MacOS X il passe par
inetd donc pas besoin) sur la machine A.

B$ ssh -X A
....
A$ xterm &

Bien sur ca veut dire que sur B, le serveur X11 est lancé, et le plus
simple c'est de faire le ssh depuis l'xterm dans X11, car
l'environnement sera correct.


Hub
--
GPG fingerprint: 6C44 DB3E 0BF3 EAF5 B433 239A 5FEE 05E6 A56E 15A3

Hubert Figuiere <hub@free.fr> wrote:

Bien sur ca veut dire que sur B, le serveur X11 est lancé, et le plus
simple c'est de faire le ssh depuis l'xterm dans X11, car
l'environnement sera correct.

Merci Hub. Je crois qu'enfin j'ai pigé.

--
Jacques

Hubert Figuiere <hub@free.fr> wrote:

Bien sur ca veut dire que sur B, le serveur X11 est lancé, et le plus
simple c'est de faire le ssh depuis l'xterm dans X11, car
l'environnement sera correct.

Bah comment dire... J'ai bien fais ça et j'obtiens un superbe Can't open
display: <rien>

Il doit me manquer quelque chose. Tu a pourtant bien dit que ssh
s'occupait tout seul comme un grand de DISPLAY.

--
Jacques

Bien sur ca veut dire que sur B, le serveur X11 est lancé, et le plus
simple c'est de faire le ssh depuis l'xterm dans X11, car
l'environnement sera correct.
Bah comment dire... J'ai bien fais ça et j'obtiens un superbe Can't open

display: <rien>
Il doit me manquer quelque chose. Tu a pourtant bien dit que ssh
s'occupait tout seul comme un grand de DISPLAY.

Que dit « echo $DISPLAY » ? Faire sur les deux machines (la locale
et la distante) un « xauth l $DISPLAY », et regarder si les deux
cookies concordent.

Sinon, copier le cookie, et faire un « xauth add $DISPLAY <cle> ».
pour transférer le cookie.

--
SS> Qu'entend-je comme rumeur? les passes de Free auraient été piratés?
Vous avez une copie de la base? Si oui, gardez-la bien au chaud, ça
nous fera un backup.
-+- Rani in <http://www.le-gnu.net> : Et vlan, passe moi la base -+-

Stephane Dupille <sdupille+news@teaser.fr> wrote:

Que dit « echo $DISPLAY » ?

Voilà la réponse :

[sur A]

et
:0.0

[sur B]

Faire sur les deux machines (la locale
et la distante) un « xauth l $DISPLAY », et regarder si les deux
cookies concordent.

C'est TRÈS long....

Pour tout dire en 1/2 heure ça n'a rien donné.

Sinon, copier le cookie, et faire un « xauth add $DISPLAY <cle> ».
pour transférer le cookie.

De la machine A vers la machine B ou l'inverse ?

--
Jacques

Que dit « echo $DISPLAY » ?
Voilà la réponse :

[sur A]
< rien >

et
:0.0
[sur B]

C'est donc que la variable n'est pas positionnée. Il suffit de la
positionner :
$ export DISPLAY=<machine B>:0 (shell Bourne)
ou
$ setenv DISPLAY <machine B>:0 (shell csh)
où <machine B> est le nom de la machine qui lance le serveur X.

Si la connexion est faite via une redirection X de SSH, cela ne
marche pas aussi simplement. Ce que j'indique, ne fonctionnera que
pour une connexion directe. La redirection SSH doit fonctionner toute
seule, tant que l'on passe l'option « -X » (et que les clients et
serveur l'autorisent).

Faire sur les deux machines (la locale
et la distante) un « xauth l $DISPLAY », et regarder si les deux
cookies concordent.

C'est TRÈS long....

Très étonnant.

Pour tout dire en 1/2 heure ça n'a rien donné.

Encore plus étonnant.

Sinon, copier le cookie, et faire un « xauth add $DISPLAY <cle> ».
pour transférer le cookie.
De la machine A vers la machine B ou l'inverse ?

Explications : lorsque l'on lance le serveur X, il crée un mot de
passe (que l'on nomme « magic cookie ») qui sert simplement à pouvoir
communiquer avec lui. Ce cookie est stocké dans le fichier
~/.Xauthority. Les clients le lisent dans le fichier, et communiquent
avec le serveur simplement.

Si on veut lancer un programme sur une autre machine, qui doit
utiliser le serveur X, ce processus doit pouvoir avoir accès au
cookie. Il suffit de le copier depuis la machine qui fait tourner le
serveur X. Tout ceci se fait avec la commande « xauth ».

« xauth l » permet d'avoir la liste des cookies, et « xauth add »
permet de le placer dans le fichier .Xauthority.

Par exemple, « xauth l » doit retourner quelque chose comme ça :
aragorn.dustnet.teaser.fr:0 MIT-MAGIC-COOKIE-1 473a337ad75a1c66a5656b6887eeb3fa
legolas.local/unix:0 MIT-MAGIC-COOKIE-1 60d4de7967168576e1dde2aa7329b128
192.168.0.11:0 MIT-MAGIC-COOKIE-1 b9450db75467ab0b8b012f3032781e2e
legolas.dustnet.teaser.fr/unix:0 MIT-MAGIC-COOKIE-1 30d64d7b48977960d53a9ea91a38b0ce
legolas.dustnet.teaser.fr:0 MIT-MAGIC-COOKIE-1 24e97a58e68e3b70d2a1a2e8929946ce

« xauth l <display> » ne retourne que la ligne qui concerne le
display.

Donc ici, copier le cookie depuis la machine qui fait tourner le
serveur X, vers la machine qui fait tourner le client.

Par exemple, lancer :
« xauth add legolas.dustnet.teaser.fr/:0 MIT-MAGIC-COOKIE-1
30d64d7b48977960d53a9ea91a38b0ce » (sur une seule ligne).

L'avantage de copier le cookie par rapport à une commande telle que
« xhost » (qui permet de spécifier les machines qui ont le droit
d'attaquer un serveur X), c'est que si la machine est partagée par
plusieurs utilisateurs, dans le cas de xhost, tous les utilisateurs
qui ont accès à la machine auront un accès au serveur X, alors que
dans le cas de « xauth », seuls ceux qui ont un accès au fichier
.Xauthority (qui par défaut a des droits très restrictifs) peuvent
attaquer le serveur X (donc permet d'avoir une granularité beaucoup
plus fine).

Il faut ignorer les cookies dont le nom finit par /unix:0, ce sont
des cookies qui permettent de communiquer avec le serveur X via une
socket Unix (donc locale), comme ici on veut les attaquer par réseau,
ils ne fonctionneront pas.

Le nom du display est facile à déterminer : c'est le nom de la
machine, suivit de « :0 ». C'est un poil plus compliqué s'il y a
plusieurs écrans.

Plus d'infos ? « man xauth ».

Est-ce que c'est plus clair avec des explications ?

--
DA> à moins qu'il n'y ait une recette du magret à la Guinness ?
Faut pas confondre canette et cannette.
-+- TT in : GNU - Coin coin, le poivrot et la bouteille de gnac -+-

Stephane Dupille <sdupille+news@teaser.fr> wrote:

C'est donc que la variable n'est pas positionnée. Il suffit de la
positionner :
$ export DISPLAY=<machine B>:0 (shell Bourne)
ou
$ setenv DISPLAY <machine B>:0 (shell csh)
où <machine B> est le nom de la machine qui lance le serveur X.

C'est donc en contradiction avec ce que disait Hub :

3/ Quelle valeur doit-on donner à la variable DISPLAY ?

ssh s'en occupe.

Nous sommes bien d'accord ?

Si la connexion est faite via une redirection X de SSH, cela ne
marche pas aussi simplement. Ce que j'indique, ne fonctionnera que
pour une connexion directe. La redirection SSH doit fonctionner toute
seule, tant que l'on passe l'option « -X » (et que les clients et
serveur l'autorisent).

Donc jouer avec xhost+

L'avantage de copier le cookie par rapport à une commande telle que
« xhost » (qui permet de spécifier les machines qui ont le droit
d'attaquer un serveur X), c'est que si la machine est partagée par
plusieurs utilisateurs, dans le cas de xhost, tous les utilisateurs
qui ont accès à la machine auront un accès au serveur X, alors que
dans le cas de « xauth », seuls ceux qui ont un accès au fichier
.Xauthority (qui par défaut a des droits très restrictifs) peuvent
attaquer le serveur X (donc permet d'avoir une granularité beaucoup
plus fine).

Donc pas de xhost mais des manips...

Est-ce que c'est plus clair avec des explications ?

Oui très clair.

Je résume.

Sur B qui est la machine sur laquelle je bosse, je fais :

% xauth l

Il me donne le MAGIC-COOKIE de l'écran sur lequel je suis là,
maintenant.

Sur la machine A, serveur à 8000 kilomètres de là, je fais :

% xauth add <MAGIC-COOKIE DE B>

J'ajoute dans mon .zshrc (par exemple) :

DISPLAY=machineB.domaine.net:0.0
export DISPLAY

Ensuite sur B, je lance X11 et dans un xterm LOCAL, je lance :

% ssh -X machineA.domaine.net

Une fois que j'ai le prompt, je fais

% xterm &

et une nouvelle fenêtre XTerm devrait s'afficher sur l'écran de B.

Bah, ça marche.

Le seul hic (pour moi) c'est cette différence entre toi et Hub sur la
variable DISPLAY.

Merci :-)

--
Jacques

C'est donc que la variable n'est pas positionnée. Il suffit de la
positionner :
$ export DISPLAY=<machine B>:0 (shell Bourne)
ou
$ setenv DISPLAY <machine B>:0 (shell csh)
où <machine B> est le nom de la machine qui lance le serveur X.
C'est donc en contradiction avec ce que disait Hub :

Non.

3/ Quelle valeur doit-on donner à la variable DISPLAY ?
ssh s'en occupe.

Nous sommes bien d'accord ?

Ce n'est pas la même chose. Il y a deux méthodes pour attaquer un
serveur X : soit une connexion directe (comme je l'ai indiqué), soit
en utilisant un tunnel SSH.

Si on lance ssh avec l'option -X, alors ssh doit tout faire tout
seul, et doit positionner la variable DISPLAY comme un grand.

Pour la connexion directe, c'est un peu plus compliqué.

Si la connexion est faite via une redirection X de SSH, cela ne
marche pas aussi simplement. Ce que j'indique, ne fonctionnera que
pour une connexion directe. La redirection SSH doit fonctionner toute
seule, tant que l'on passe l'option « -X » (et que les clients et
serveur l'autorisent).
Donc jouer avec xhost+

Non, surtout pas. ssh passe le cookies lors de l'initialisation.
C'est ssh qui s'occupe de lui-même de mettre à jour le fichier
.Xauthority (ou d'appeler xauth, je ne sais pas comment il fait dans
le détail).

Il faut prendre l'habitude de bannir xhost autant que possible, tout
est possible avec xauth (mais est un peu plus chiant à utiliser).
xhost est dangereux !

Donc pas de xhost mais des manips...

Voilà. A noter qu'il existe un utilitaire qui simplifie un peu le
machin, ça s'appelle « xon ». Il doit être dans tout distrib un tant
soit peu standard (comme xterm), et est censé s'occuper tout seul de
placer le cookie qui va bien. Le problème est qu'il repose sur rsh
pour la connexion initiale, et niveau sécurité, c'est loin d'être top.

Est-ce que c'est plus clair avec des explications ?
Oui très clair.

< snip >

Bah, ça marche.

:))

Le seul hic (pour moi) c'est cette différence entre toi et Hub sur la
variable DISPLAY.

La variable display contient le nom du display (en gros, l'adresse
du serveur X). La valeur que tu as indiqué permet d'avoir une
connexion directe entre le client et le serveur.

La version de Hub est de faire passer cette connexion via le tunnel
SSH (ce qui est mieux : non seulement on sécurise, mais par dessus le
marché, on peut compresser (ce qui n'est pas toujours un gain
d'ailleurs)).

Avec un schéma, c'est peut-être plus clair :


connexion directe :
Client X ------------------> serveur X

Forwarding SSH :
Machine distante | Machine locale
|
Client X | Serveur X
| | ^
/ | |
serveur SSH ---------------> client SSH

Dans le cas d'un tunnel SSH, la variable display est de la forme
localhost:<num>, et SSH va rerouter le display local vers le serveur
X.

En gros, la méthode est celle ci :
< machine locale >
$ echo $DISPLAY
doit affiche quelque chose, on doit pouvoir lancer un client X sur
cette machine.
$ ssh -X <machine distante>
le X doit être en majuscule !
$<distant> echo $DISPLAY
doit renvoyer qqchose sous la forme localhost:<num>

On doit pouvoir lancer un client sur la machine distante.

Ça ne peut marcher que si : « X11Forwarding yes » est présent dans
/etc/ssh/sshd_config de la machine distante (cela indique que le
serveur SSH autorise le forwarding de X).

A noter que SSH s'occupe tout seul de gérer les cookies. Tout est
indiqué à ce propose dans le man d'SSH, chapitre X11 Forwarding.

Merci :-)

Ah mais de rien !

--
salut c Herve je voulais savoir si tu puvais m'envoyer le crack pour
wingate.
-+- Is in <http://www.le-gnu.net/> - Je lui fais crack-crack -+-

Stephane Dupille <sdupille+news@teaser.fr> wrote:

Ce n'est pas la même chose. Il y a deux méthodes pour attaquer un
serveur X : soit une connexion directe (comme je l'ai indiqué), soit
en utilisant un tunnel SSH.

Ce qui m'interessait, c'était la connexion SSH, l'autre étant par moi
connue depuis septembre 1991. :-)

Mais comme il y a eu confusion... :-)

Merci donc

--
Jacques