Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Debian Redirection X via ssh et Debian

Redirection X via ssh et Debian

19 réponses
Avatar
Mourad Jaber
Bonjour,

J'ai un soucis avec laredirection X sous debian...
quand je fait un ssh -X machinecible où la machine cible est une machine
debian, j'ai une erreur dès que j'essai de lancer une application X, il
manque la variable DISPLAY !

Par contre avec une machine cible ubuntu, pas de problème et j'ai
effectivement la variable DISPLAY qui possède une valeur !

Comment résoudre ce problème sous debian ?

++

Mourad

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C4C3F0B.6010808@nativobject.net
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Frederic MASSOT
Le 26/07/2010 12:05, moi-meme a écrit :
Le Mon, 26 Jul 2010 11:20:02 +0200, Julien Demange a écrit :

Si tu fais "xhost +" tu autorise toute personne qui peut initier un
session TCP sur le bon port de la machine, à accéder au serveur X !



question :
un nmap du client:
-->[ ~] nmap 192.168.10.150

Starting Nmap 4.62 ( http://nmap.org ) at 2010-07-26 12:02 CEST
Interesting ports on 192.168.10.150:
Not shown: 1712 closed ports



man nmap : By default, Nmap scans the most common 1,000 ports for each
protocol.

Si tu veux scanner tout les ports TCP tu devrais utiliser la syntaxe :

nmap -sT -p 1-65535 192.168.10.150

--
============================================= | FRÉDÉRIC MASSOT |
| http://www.juliana-multimedia.com |
| mailto: |
==========================Þbian=GNU/Linux==
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Vincent Lefevre
On 2010-07-26 10:36:09 +0200, Xavier Oswald wrote:
De mémoire, je faisais:

machine locale:
* Enlever l'option no listen TCP du serveur X /etc/X11/xinit/xserverrc



Pas besoin. Le problème est forcément ailleurs.

* Lancer X a la main avec startx et non via KDM/GDM car il écrase sinon cette valeur



Donc pas besoin.

machine distante:
* Lancer export DISPLAY=machine:0.0 (si 0.0 est le display de la machine)



Non, la connexion *doit* se faire sur localhost.

Un "export DISPLAY=machine:0.0" *ne peut pas* marcher. Ou alors
tu as un énorme trou de sécurité sur ta machine.

--
Vincent Lefèvre - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Vincent Lefevre
On 2010-07-26 11:18:45 +0200, Julien Demange wrote:
Pour ssh je ne crois pas que "-Y" puisse marcher sans "-X" ?



Si, en fait, -Y s'utilise à la place de -X.

--
Vincent Lefèvre - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Vincent Lefevre
On 2010-07-26 11:46:17 +0200, Simon Chopin wrote:
Si je peux apporter mon grain de sel, les deux options créent un tunnel SSH
qui fait que le serveur X de ta machine locale (celle qui lance ssh) est
accessible sur ta machine distante (qui fait tourner sshd) via :10.0 ou un
truc dans le genre. Sauf que -Y authentifie la connexion au serveur X via le
système xauth dont je ne comprends pas grand chose (il n'y a pas une
histoire de cookie dans le tas ?), alors que -X se connecte simplement en
TCP sans chercher à s'authentifier auprès de X. xhost + (qui doit être lancé
par l'utilisateur qui possède l'instance du serveur X, soit en général
l'utilisateur courant) ne devrait en effet ne jamais être utilisé si on peut
faire autrement.



xauth est aussi utilisé avec -X. En fait, -X ou -Y, c'est juste une
question de restriction sur ce qu'un client X11 peut faire. D'après

http://dailypackage.fedorabook.com/index.php?/archives/48-Wednesday-Why-Trusted-and-Untrusted-X11-Forwarding-with-SSH.html

avec -Y, un client peut injecter des événements (déplacement de
la souris, touches enfoncées) ou lire des données des fenêtres
des applications locales (e.g. pour screenshot), avec qu'avec -X
seulement, le serveur X l'interdit.

Je suppose que le but est de pouvoir faire tourner des applications
(avec affichage local) sur une machine distante, dont on n'a pas
entièrement confiance, par exemple une machine qui appartient à une
entreprise tierce: on ne voudrait pas que cette application distante
puisse voler des données locales ou perturber la machine locale.
Donc attention, ne pas faire de ssh -Y vers n'importe quelle machine!

--
Vincent Lefèvre - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Julien Demange
Salut,

Le 26/07/2010 12:05, moi-meme a écrit :
Le Mon, 26 Jul 2010 11:20:02 +0200, Julien Demange a écrit :

Si tu fais "xhost +" tu autorise toute personne qui peut initier un
session TCP sur le bon port de la machine, à accéder au serveur X !



question :


[nmap]

Nmap done: 1 IP address (1 host up) scanned in 0.730 seconds

Le "xhost +" n'ouvre pas de port supplémentaire (dixit nmap)



Bien sur que non !
C'est le serveur X qui va ouvrir des ports, à son lancement. Dans les
version récente des distribution, X ouvre rarement autre chose que sur
127.0.0.1 ou une socket unix. Mais on peut lui dire d'écouter n'importe
quel IP de la machine, même si ça n'a plus beaucoup d'intérêt avec SSH.

xhost lui va dire qu'elle hôte distant va ne pas êtres jeté des sa
connexion. A l'instant des directive host alow/deny dans apache ou tout
autre appli serveur qui filtre au niveau applicatif.

Si tu fais un "xhost +" mais que je serveur X n'écoute pas sur l'IP de
ta machine, ça ne sert à rien. Par contre, si X vien a écouter l'IP,
alors là, il va autoriser potentiellement tout le monde...
xauth lui travail avec des "coockie", je n'en sais pas plus.

pour nmap teste :
# nmap -sS -p6000-6100 127.0.0.1
# nmap -sS -p6000-6100 192.168.10.150
(ou -sT à la place de -sS si tu ne le lances pas en root)


et avant je n'ai pas possibilité d'ouvrir de fenêtre X.
Je ne le vois pas ouvert ce port X11.



Ce que j'ai toujours compris :
pour ton serveur X, à travers ssh, il va voit tout, comment venant du
client ssh local. Donc c'est ton client ssh qui doit avoir le droit de
parler à ton serveur X local ;
pour le distant, le serveur SSH va se comporter un peu comme un serveur
X local.
Le tout est de passer les coockie entre tout ça. Ou bien ne pas avoir de
cookie. Et là, je n'ai jamais réussi à faire autre chose que tu tatillon
sans comprendre trop fort.


Plutôt que de continuer à polluer, vous n'avez pas une petite URL pour
neuneu comme moi que je meure (?) moins idiot ?



Perso, je suis intéressé par tout doc clair sur xauth, Je n'ai jamais
trouvé que des truc qui entre des des considération technique assez
floue. :(


--
a+,
Julien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
moi-meme
Le Mon, 26 Jul 2010 13:20:02 +0200, Julien Demange a écrit :

pour nmap teste :
# nmap -sS -p6000-6100 127.0.0.1
# nmap -sS -p6000-6100 192.168.10.150 (ou -sT à la place de -sS si tu ne
le lances pas en root)



le résultat des commandes -j'ai suivi le sorfdres :

root[moi]# nmap -sS -p 1-65535 192.168.10.16

Starting Nmap 5.21 ( http://nmap.org ) at 2010-07-26 13:48 CEST
Nmap scan report for morgane (192.168.10.16)
Host is up (0.025s latency).
Not shown: 65524 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds
2049/tcp open nfs
6566/tcp open unknown
43629/tcp open unknown
45590/tcp open unknown
60646/tcp open unknown

root[moi]# nmap -sT -p 1-65535 192.168.10.16

Starting Nmap 5.21 ( http://nmap.org ) at 2010-07-26 13:52 CEST
Nmap scan report for morgane (192.168.10.16)
Host is up (0.046s latency).
Not shown: 65524 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds
2049/tcp open nfs
6566/tcp open unknown
43629/tcp open unknown
45590/tcp open unknown
60646/tcp open unknown


le port 60646 est du X11 ?
j'ai une fenêtre graphique ouverte

> Plutôt que de continuer à polluer, vous n'avez pas une petite URL pour
> neuneu comme moi que je meure (?) moins idiot ?

Perso, je suis intéressé par tout doc clair sur xauth, Je n'ai jamais
trouvé que des truc qui entre des des considération technique assez
floue.



Tant pis. Mais on n'a pas toujours besoin de savoir finement comment
tournent toutes les roues ... si on arrive à les utiliser.

Merci pour le -X et -Y.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/4c4d9809$0$18310$
Avatar
Goldy
Le 25/07/2010 22:30, C. Mourad Jaber a écrit :


On 25/07/2010 16:53, Mourad Jaber wrote:


Le 25/07/2010 16:37, Stephane Bortzmeyer a écrit :
On Sun, Jul 25, 2010 at 03:44:56PM +0200,
Erwan David wrote
a message of 30 lines which said:

Va voir dans le /etc/ssh/sshd_config pour activer le tunnel X11.

X11Forwarding yes


Ça peut être aussi le paquet xauth (qui contient le programme du même
nom, qui configure l'autorisation X11) qui n'est pas installé sur le
serveur SSH.



Bien vu, c'était la paquet xauth qui n'était pas installé !

Merci

++

Mourad



J'ai retenté lexpérience sur une autre machine, celle-ci est en 64bits
et installée recement...
Pour sshd_config j'ai :

X11Forwarding yes
X11DisplayOffset 10

J'ai essayé de donner des droits supplémentaires, mais sans succès avec
xhost :
# xhost +
xhost: unable to open display ""

effectivement la variable DISPLAY n'est pas présente...

En forcant la valeur de DISPLAY, j'ai le même résultat :(

J'ai ajouté ça dans le ssh_config :
Host *
ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes

Mais ça ne change rien... ce que est très curieux, c'est que ma machine
sous ubuntu à exactement la même configuration ssh (avant mes dernières
modifications) et ça marche sans difficulté !

Si quelqu'un a une autre idée, je suis prenneur !...

++

Mourad




Désolé de déterrer un thread de quelques mois.

Je ne sais pas si Mourad à trouvé la solution à son problème, mais j'ai
été confronté à quelque chose de similaire.

Je l'ai corrigé en mettant l'option X11UseLocalhost no dans sshd_conf.
Mais il semblerait que ça engendre des risques de sécurité, si quelqu'un
pouvait me confirmer ça. La machine est derrière un part feu donc je
devrais logiquement être protégé des connexions à xorg depuis internet,
mais bon comme je ne comprends pas vraiment à quelle niveau se situerait
cette faiblesse, je préfère vous demander.

Merci d'avance.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
C. Mourad Jaber
Le 10/10/2010 04:29, Goldy a écrit :
Le 25/07/2010 22:30, C. Mourad Jaber a écrit :
J'ai retenté lexpérience sur une autre machine, celle-ci est en 64bits
et installée recement...
Pour sshd_config j'ai :

X11Forwarding yes
X11DisplayOffset 10

J'ai essayé de donner des droits supplémentaires, mais sans succès avec
xhost :
# xhost +
xhost: unable to open display ""

effectivement la variable DISPLAY n'est pas présente...

En forcant la valeur de DISPLAY, j'ai le même résultat :(

J'ai ajouté ça dans le ssh_config :
Host *
ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes

Mais ça ne change rien... ce que est très curieux, c'est que ma machine
sous ubuntu à exactement la même configuration ssh (avant mes dernières
modifications) et ça marche sans difficulté !

Si quelqu'un a une autre idée, je suis prenneur !...

++

Mourad



Désolé de déterrer un thread de quelques mois.

Je ne sais pas si Mourad à trouvé la solution à son problème, mais j'ai
été confronté à quelque chose de similaire.

Je l'ai corrigé en mettant l'option X11UseLocalhost no dans sshd_conf.
Mais il semblerait que ça engendre des risques de sécurité, si quelqu'un
pouvait me confirmer ça. La machine est derrière un part feu donc je
devrais logiquement être protégé des connexions à xorg depuis internet,
mais bon comme je ne comprends pas vraiment à quelle niveau se situerait
cette faiblesse, je préfère vous demander.

Merci d'avance.



Bonjour,

Je ne sais pas si c'est une faille, les bsdistes vont hurler...

Par contre, je pense que le cœur du problème est que ssh ne communique pas la variable
$DISPLAY ce qui empêche le X11forward puisqu'il ne sait pas où afficher les fenêtres !

J'ai fait quelques tests sur une ubuntu et ça marche directement parce que la variable
$DISPLAY est correctement initialisée. Je n'ai pas trouvé ce qui modifie le comportement,
mais si quelqu'un à une piste, je suis prenneur !

++

Mourad

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Goldy
Le 11/10/2010 11:08, C. Mourad Jaber a écrit :
Le 10/10/2010 04:29, Goldy a écrit :
Le 25/07/2010 22:30, C. Mourad Jaber a écrit :
J'ai retenté lexpérience sur une autre machine, celle-ci est en 64bits
et installée recement...
Pour sshd_config j'ai :

X11Forwarding yes
X11DisplayOffset 10

J'ai essayé de donner des droits supplémentaires, mais sans succès avec
xhost :
# xhost +
xhost: unable to open display ""

effectivement la variable DISPLAY n'est pas présente...

En forcant la valeur de DISPLAY, j'ai le même résultat :(

J'ai ajouté ça dans le ssh_config :
Host *
ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes

Mais ça ne change rien... ce que est très curieux, c'est que ma machine
sous ubuntu à exactement la même configuration ssh (avant mes dernières
modifications) et ça marche sans difficulté !

Si quelqu'un a une autre idée, je suis prenneur !...

++

Mourad



Désolé de déterrer un thread de quelques mois.

Je ne sais pas si Mourad à trouvé la solution à son problème, mais j'ai
été confronté à quelque chose de similaire.

Je l'ai corrigé en mettant l'option X11UseLocalhost no dans sshd_conf.
Mais il semblerait que ça engendre des risques de sécurité, si quelqu'un
pouvait me confirmer ça. La machine est derrière un part feu donc je
devrais logiquement être protégé des connexions à xorg depuis internet,
mais bon comme je ne comprends pas vraiment à quelle niveau se situerait
cette faiblesse, je préfère vous demander.

Merci d'avance.



Bonjour,

Je ne sais pas si c'est une faille, les bsdistes vont hurler...

Par contre, je pense que le cœur du problème est que ssh ne communique
pas la variable $DISPLAY ce qui empêche le X11forward puisqu'il ne sait
pas où afficher les fenêtres !

J'ai fait quelques tests sur une ubuntu et ça marche directement parce
que la variable $DISPLAY est correctement initialisée. Je n'ai pas
trouvé ce qui modifie le comportement, mais si quelqu'un à une piste, je
suis prenneur !

++

Mourad




Je ne pense pas que cela vienne du client, car je peux sans problème
utiliser mon laptop sous debian pour faire du x11 forwading depuis une
machine ubuntu. Le problème semble donc être au niveau du serveur ssh,
pas du client.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
1 2