Salut Patrice,
Patrice Karatchentzeff a écrit :
> Salut,
>
> Je fais mumuse avec vnc en ce moment : entre deux stations (Linux),
> pas de souci en direct (j'ai pris tightvncserver côté server).
>
> Bon, évidemment, je voudrai un peu sécuriser tout cela : donc tout
> mettre dans un tunnel ssh...
Toi, tu aurais du venir à ma conférence de l'année dernière ;) :
http://www.guilde.asso.fr/rencontres/20080409/
Les transparents de ma conf sont sur cette URL, en divers format
> J'ai trouvé plein de tutoriels sur le net qui disent tous la même chose...
>
> % ssh -L 5901:127.0.0.1:5900 [utilisateur]@[serveur SSH]
Tu n'es pas obligé d'ouvrir le port local (coté client) 5901: ("... -L
5901:...."). Tu peux ouvrir le port 5900, du moment, bien sûr, que dans
tes tests, serveurs SSH+vnc et clients SSH+VNC NE tournent PAS sur la
même machine:
ssh -L 5900:127.0.0.1:5900 [utilisateur]@[serveur SSH]
^^^^
> (pour la version soft, sans compression ni optimisation)
Je ne comprends pas ta phrase: Tu parles de compression SSH ?
Honnêtement, si tu utilises un protocole de communication VNC optimisé,
il n'est pas nécessaire de rajouter par-dessus de la compression SSH.
Cela ne fera qu'augmenter l'impression de "lag".
> puis se connecter à 127.0.0.1:1
Avec ma configuration, il te faut faire un un:
xtightvnc 127.0.0.1
> C'est là où ça coince chez moi : pas de message côté serveur et
> suivant le type de connexion ssh que j'utilise, j'obtiens un
>
> channel 2: open failed: connect failed: Connection refused
>
> dans mon terminal.
>
> Une idée de ce qui ne va pas ?
Oui : C'est ton serveur VNC qui ferme la connexion. Sur la machine
serveur SSH+VNC, je te conseille de faire un :
tcpdump -n -i eth0
et de regarder ce qu'il se passe.
Fais aussi un :
netstat -taupn|grep 5900
afin de voir si le port 5900 du serveur est ouvert.
Tu peux aussi activer la verbositée des logs, tant coté :
- serveur SSH ("LogLevel DEBUG3" dans le "/etc/ssh/sshd_config")
- client SSH ("ssh -o LogLevel=DEBUG3 xxxxx")
Pour être honnête, j'en ai pas mal bavé pour faire fonctionner VNC en
mode serveur. Comme indiqué dans mes transparents, il existe 2 modes de
fonctionnement de VNC:
Le mode serveur :
http://olivieraj.free.fr/fr/linux/information/prise_en_main_a_distance_avec_linux/presentation/img24.html
=> Plusieurs clients DIFFERENTS ouvrent des sessions DIFFERENTES sur le
serveur. Et ils NE voient PAS l'écran "physique" du serveur
Ou Le mode partage de bureau :
http://olivieraj.free.fr/fr/linux/information/prise_en_main_a_distance_avec_linux/presentation/img27.html
=> Un client à distance voit l'écran physique du serveur
Le 2nd mode est nettement plus facile à mettre en oeuvre (il faut
utiliser "x11vnc"). A noter que dans ce cas là, "x11vnc", qui doit être
lancé par l'utilisateur qui a le DISPLAY:0, affiche plein de messages de
logs, fort utiles.
> Autre question, pendant que j'y suis : quels sont les meilleurs outils
> pour faire du vnc - ou approchant - sur une liaison modeste (16 ko.s¯¹
> en upload par exemple).
xtightvnc en activant l'encodage "tight" :
xtightvncviewer -encodings tight serveur:0
Mais parfois, c'est un peu dur de lui faire comprendre que l'on veut
cette méthode d'encodage... :=(
Tu as aussi toutes sorte d'options, permettant par exemple, de ne pas
afficher le fond d'écran. Cela fait gagner de la bande passante.
> Merci d'avance,
De rien.
Cordialement,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
