J’ai deux portables un sous Debian et un autre sous Ubuntu 12.04. Je voudrais pouvoir lancer une application qui se trouve sous la machine Ubuntu et qu’elle s’affiche sur la machine Debian.
Je l’ai fait du temps où j’étais administrateur Sun Solaris, mais il y a longtemps de ça et je ne me rapelle plus quels fichiers configurer pour donner les autorisations d’accès (/etc/hosts me semble-t-il), et faire un export DISPLAY de l’adresse de la machine de destination.
Mais peut-être que les chose ont évolués depuis.
Merci de vos aides, ou pistes de recherche.
Xhost permet de contrôler les accès à X, /etc/hosts sert à coupler les numéros IP avec leurs noms.
Sur la machine A, accepter la connexion provenant de B (remplacer A et B par leurs numéros IP)
$ xhost +B
Sur la machine B, exporter l’affichage sur A.
$ export DISPLAY=A:0
Le programme lancé depuis B s’affichera sur le X de la machine A.
$ man xhost
Façon cryptée : ssh avec X11 forwarding , option -X.
$ ssh -X user@B
La méthode ssh est bien plus facile à mettre en œuvre AMHA : par défaut le serveur X n’écoute pas sur le réseau donc xhost n’est pas suffisant, il faut faire d’autres modifs dans la config et ça peut très vite tourner au trou de sécurité.
Merci de vos réponses.
AMHA pour moi c’est de l’Hébreux… Je ne sais pas conceptuellement quels mécanismes il met en oeuvre.
Et si ça génère des trous de sécurités c’est pas très engageant.
Pour info, les deux machines sont connectées à ma NeufBox et j’ai un filtrage MAC (je n’autorise les connexions à ma box que pour les équipement que je connais).
Dois-je dans ces conditions poursuivre; le risque de trous de sécurité présente-t-il dans ces conditions un réel problème ?
À suivre …
Je te conseille la lecture de ce HOWTO : /usr/share/doc/HOWTO/en-txt/Remote-X-Apps.gz
Celui qui a accès à ton X peut voir ton écran, y écrire, lire ce que tu composes au clavier …
[quote]
the default configuration of Debian GNU/Linux is to disable the X server listening on the TCP port. [/quote]
Par défaut, le réglage est “no-listen” en debian. Pour mettre debian à l’écoute, je passe par gdmsetup, réglages de gdm (Nota: gdm pas gdm3).
[quote]
Xhost is a very insecure mechanism. It does not distinguish between
different users on the remote host. Also, hostnames (addresses
actually) can be spoofed. This is bad if you’re on an untrusted
network (for instance already with dialup PPP access to Internet)[/quote]
En procédant par
$ xhost +hostname
on autorise tous les utilisateurs d’un “hostname” donné sans distinguer les utilisateurs.
L’adresse de la machine correspondant au “hostname” est également susceptible d’être détournée.
Si tu es particulièrement méfiant ou que tu veux exploiter X à travers le réseau mondial, ssh -X est plus conseillable.
Si tu es modérément méfiant, préférer xauth à xhost.
Si tu as confiance en ton réseau local cloisonné sans hackers internationaux à la petite semaine qui cherchent les failles dans le voisinage, xhost fera l’affaire.
La seule machine impossible à hacker est la machine en panne …
AMHA = À Mon Humble Avis 
Désolé j’essaye généralement de pas utiliser trop d’abréviations mais là c’est sorti tout seul.
Je parlais bien entendu de la méthode xhost. La méthode SSH, elle, est très sûre.
Un énorme avantage de SSH (à mon avis) c’est qu’une fois mis en place tu fais plein de choses avec : accès distant à la ligne de commandes, accès distant aux applications graphiques, partage de fichiers, … Pas mal pour un truc qui (quand tu le connais) ne met que quelques minutes à se configurer. 
Du coup je pars souvent du principe “si SSH le fait, pas la peine d’aller voir ailleurs”. 
SSh est quand même bien sécurisé et si tu crains encore, ajoute des clefs avec passphrase 
Merci pour tout ces conseils. J’en était resté à rlogin et j’ai cru comprendre que ssh l’avait remplacé. Mais comment configurer les machines pour pouvoir y accéder via ssh?
Installe openssh-server sur les machines auxquelles tu veux accéder à distance (serveurs), et openssh-client sur les machines à partir desquelles tu veux accéder aux autres à distance (clients).
Pour du partage de fichiers il faut en plus sshfs sur les machines clientes.
Si tu veux te connecter par mot de passe, seul les serveurs ont besoin de configuration (mais tu peux aussi configurer les clients pour que ça soit plus pratique à utiliser).
Si tu veux utiliser des paires de clés asymétriques il faut configurer serveurs et clients conjointement.
Comment configurer précisément ? C’est déjà expliqué à des milliers d’endroits (entre autres dans le manuel) donc je te laisse chercher, mais je me ferai une joie de t’aider (ou au pire de t’aiguiller) si tu rencontres un problème précis. 
J’ajoute à ce qu’a dit Syam que François a fait un “truc” très pratique pour réduire un MDP à quelques lettre avec la même sécurité (dans T&A)
EDIT :
C’est là : http://www.debian-fr.org/utilisation-de-clefs-et-raccourcis-dans-ssh-t5472.html
syam
Tu parles de manuel. Je suis tout à fait partant pour chercher plutôt que d’être passif à attendre des réponses. Peux-tu m’indiquer où se trouve de la documentation, un manuel ? Ça c’est une information qui m’intéresse au plus haut point.
Merci d’avance.
J’ai fait ce que vous m’avez dit et j’ai cherché de la doc. J’ai trouvé dans un Wiki Debian comment configurer /etc/ssh/sshd.config.
Je me connecte bien à mon serveur via ssh, mais si je lance gedit ça me dit 'cannot open display: 192.168.1.35:0.
Pour l’instant je peux juste faire des interventions en console sur le serveur ssh. C’est déjà cà 
Reste plus qu’à pouvoir afficher sur le client l’application qui se trouve sur le serveur.
J’ai cherché, je ne trouve pas. Un petit peu d’aide. Me mettre sur une piste, une doc, etc…
À votre bon coeur.
Sur le serveur , configurer sshd_config avec X11 forwarding.
Cette option n’entrera en vigueur qu’après avoir interrompu puis relancé le service sshd. Si tu n’interromps pas le service sshd, il poursuivra sa marche sur la base des réglages antérieurs sans X11 forwarding.
Côté client ssh, il n’y a pas besoin de préciser $DISPLAY , l’option -X suffira.
Quand on parle du manuel, ça implique d’utiliser la commande man. Pour avoir le manuel d’un programme donné (ssh par exemple) il faut évidemment que ce programme soit déjà installé, puis tu peux faire man NOM_DU_PROGRAMME.
Un truc bien pratique à connaître pour “explorer” la ligne de commandes en général, et les manuels disponibles en particulier c’est la touche TAB : tu commences à taper quelque chose, et un appui sur TAB :
- une première fois va compléter ce que tu tapes s’il n’y a qu’un seul choix possible (permet de taper moins de touches)
- ou bien une deuxième fois, s’il y a plusieurs choix, va te montrer tous les choix possibles
Par exemple :
$ man ssh<TAB><TAB>
ssh ssh-agent ssh_config sshd sshfs ssh-keyscan ssh-pkcs11-helper
ssh-add ssh-argv0 ssh-copy-id sshd_config ssh-keygen ssh-keysign ssh-vulnkey
On voit qu’il y a plein de manuels différents pour ssh, mais en l’occurrence pour configurer le serveur c’est le manuel sshd_config qui va t’intéresser.
Juste un truc à garder en mémoire avec le manuel : c’est souvent de la documentation de référence (lire : ça explique toutes les options en détail) et non pas un tutoriel pas à pas pour expliquer comment débuter. Mais par contre c’est toujours un bon complément à un tutoriel pour pouvoir comprendre exactement ce que le tuto te dit de faire.
En utilisant judicieusement les infos disponibles sur internet conjointement au manuel, tu réduis dramatiquement le nombre de questions que tu poses aux autres, mais surtout tu as le plaisir d’avoir trouvé et compris un truc par toi-même.
Et si tu dois quand même poser une question au final, ça montre aux autres que tu as cherché avant (on aide plus facilement ceux qui s’aident eux-mêmes ; pourquoi aider quelqu’un qui n’a pas fait d’effort ? – comprendre : qui estime que son temps est plus précieux que le notre). Alors oui la ligne est parfois fine entre “j’ai pas fait l’effort de chercher” et “je ne sais pas du tout où commencer à chercher” mais on est pas des sauvages, on sait faire la différence.
bash n’a pas d’autocomplétion pour les pages de man (du moins, par défaut), mais on peut utiliser man -k ou apropos :
$ man -k ssh
ssh (1) - OpenSSH SSH client (remote login program)
ssh-add (1) - adds private key identities to the authentication agent
ssh-agent (1) - authentication agent
ssh-copy-id (1) - install your public key in a remote machine's authorized_keys
ssh-keygen (1) - authentication key generation, management and conversion
ssh-keyscan (1) - gather ssh public keys
ssh-keysign (8) - ssh helper program for host-based authentication
ssh-pkcs11-helper (8) - ssh-agent helper program for PKCS#11 support
ssh_config (5) - OpenSSH SSH client configuration files
sshd (8) - OpenSSH SSH daemon
sshd_config (5) - OpenSSH SSH daemon configuration fileBizarre, ça marche chez moi sans que j’aie rien installé de particulier (à part bash-completion qui est un paquet “standard” je crois). 
J’ai étudié le man de ssh.
Je bute sur un problème lors de la connexion j’ai le message “ssh: connect to host 192.168.1.35 port 22: Connection refused”.
J’ai indiqué dans le fichier de configuration concernant le port de connexion, le port n°22 (celui par défault) et je ne sais pas comment faire en sorte que ce port soit accessible.
Peut-être au niveau du firewall du serveur, mais là je ne sais pas comment le configurer.
Un petit coup de pouce … merci par avance.