VNC : prise en main de poste distant

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 23/10/12
  • Correction mineure : 04/02/13
  • Auteur : Dirk Hoffmann (Centre de Physique des Particules de Marseille (CPPM-IN2P3))
Mots-clés

VNC : prise en main de poste distant

Introduction

VNC désigne à la fois un protocole de prise en main d'un poste (sous Windows, Linux, MacOS, etc.) et les logiciels qui l'implémentent. Cette fiche ressource se veut générique dans le sens où elle décrit le protocole VNC ainsi que les caractéristiques communes aux logiciels qui l'implémentent.
Cette fiche reprend délibérément le format d'une fiche logiciel, plus exhaustif (et contraignant) qu'une fiche ressource.

Un site générique pour VNC en tant que protocole n'existe pas. Le domaine historique vnc.com renvoie vers le site de la société RealVNC, issue d'une partie de l'équipe initiale des développeurs et détenteur de la marque déposée VNC™. Voir plus loin pour les sites des différentes implémentations, commerciales ou libres, du protocole VNC.

Fonctionnalités générales

Prendre la main (vue de l'écran et contrôle du clavier et de la souris) sur une machine distante, pour faire par exemple de l'administration ou de l'assistance utilisateur. VNC utilise le protocole RFB (remote frame buffer), qui peut s'appliquer à tous les systèmes affichage "en fenêtres" (dont Windows, le protocole X11 et Macintosh). De par sa conception extensible, il a permis aux différentes implémentations (depuis la fin des années 1990) de rester largement compatible entre elles.

Plate-formes et interopérabilité

Fonctionne sur toutes les plate-formes majeures (Windows, Linux, MacOS, etc.), sans problème d'interopérabilité. Cela signifie qu'un client à partir d'un système d'exploitation donné peut se connecter à un serveur tournant sur un autre système d'exploitation. Cependant, l'interopérabilité entre les différents logiciels VNC (saveurs) n'est pas toujours donnée, surtout quand le logiciel serveur et le logiciel client ont des dates de fabrication trop éloignée l'une de l'autre.

Contexte d'utilisation dans mon laboratoire/service

  • serveur VNC sur un serveur Windows pour l'administration à distance,
  • serveur VNC sur des postes clients pour faire de l'assistance à distance,
  • serveur VNC sous Linux, des clients VNC permettent aux utilisateurs d'accéder à cet environnement depuis des PCs Windows.

Limitations, difficultés, fonctionnalités importantes non couvertes

Le protocole est vulnérable à certains types d'attaques, quoique le mot de passe et la transmission des données soient cryptés. Des solutions à base de tunnels SSH ou de VPN sécurisés permettent de pallier cette faiblesse.

Distributions dans lesquelles ce logiciel est intégré

Quasiment toutes les distributions Linux intègrent un client/serveur VNC.

Logiciels implémentant le protocole VNC

  • RealVNC: http://www.realvnc.com/, existe en version gratuite "Free" (licence propriétaire), "Personal" et "Enterprise Edition". La version Free est distribuée pour Windows, Linux x86, Solaris 7, HP-UX 11, code source (Unix) et code source pour le Viewer en Java et pour Windows.
  • TightVNC: http://www.tightvnc.com/, entièrement gratuit (octobre 2011) en licence GPL. Dernière version (2.5) serveur + client disponible pour Windows. Une version précédente (1.3) également en saveur "Unix-like", ainsi que source et "binaire" en Java pour un Viewer en version 2.6.
  • TigerVNC: http://tigervnc.sourceforge.net/, est un fork de TightVNC fondé par un ancien co-développeur de TightVNC pour diverses raisons. Ce dérivé se veut " high performing, stable and generic". Est disponible gratuitement en licence GPL.
    Je n'ai pas pu le tester, mais il est distribué avec Fedora 13 par exemple.
  • UltraVNC: http://www.ultravnc.fr/, gratuit en licence GPL, donations possibles, pour Windows.
  • Vine Server/Client : http://www.testplant.com/support/downloads/vine/, précédemment distribué sous le nom OSXvnc, est un couple serveur/client VNC libre et open-source de TestPlant, Inc., vendu également avec un service support par la même entreprise.

Des fiches logiciels pour ces applications n'existent pas actuellement dans PLUME. Si vous êtes utilisateur régulier d'une de ces "saveurs" de VNC, contactez l'auteur de la fiche pour contribuer à la collection avec votre description du logiciel.

Autres logiciels aux fonctionnalités équivalentes

  • Symantec pcAnywhere (client et serveur payants).
  • Windows Terminal server (payant) et client RDP (intégré à Windows ou rdesktop, FLOSS pour Unix)
  • Nomachine NX, logiciel commercial, mais version gratuite "Free Edition" disponible qui est limitée à deux utilisateurs (comptes) déclarés simultanément sur la machine serveur. (Voir NX-Freenx pour une implémentation gratuite.)

Historique et Éléments de pérennité

Le protocole a été développé à l'origine dans les laboratoires de recherche joints des sociétés Olivetti et Oracle. Les laboratoires ont été vendus en 1999 à la société AT&T, qui ferma les activités de recherche en 2002. Suivant cette fermeture, plusieurs développeurs du projet ont fondé RealVNC, afin de pouvoir continuer à produire le code open source et commercial sous ce nouveau nom. Les sources ont été mises sous licence GPL et réutilisées (forked) par plusieurs autres équipes de développement.
Aujourd'hui, de (trop ?) nombreuses implémentations du client/serveur disponibles sur la majorité des plate-formes existent.
Protocole éprouvé et très répandu.

Références d'utilisateurs institutionnels

  • ATLAS control room management / sysadmins (CERN).
  • Accès à distance local (labo) et international (collaborations) au CPPM (CNRS).
  • Utilisation de VNC pour l'administration et l'intervention à distance sur les postes gérés par les ASR du LAAS (CNRS).

Augmentation de la sécurité du protocole

Le protocole VNC n'était pas un protocole sécurisé à la base, et malgré des progrès récents, surtout dans des versions commerciales de l'implémentation, il convient de donner quelques conseils pour augmenter la sécurité.

Serveur VNC sous Windows

  • Via la base de registre côté serveur, il est possible de n'autoriser que certaines adresses ou plages d'adresses IP à se connecter à un serveur VNC en paramétrant une valeur "AuthHosts" ou "Hosts" selon l'implémentation de VNC utilisée ("AuthHosts" VNC et UltraVNC , "Hosts" pour RealVNC).

  • Le paramétrage d’AuthHosts est une clé de type REG_SZ employée pour indiquer un ensemble de masques d’adresses IP que les connexions entrantes doivent respecter afin d’être acceptées. Par défaut, le masque est vide et les connexions de tous les centres serveurs sont acceptées. Le masque est de la forme :
    +[masque d’IP]
    ?[masque d’IP]
    -[masque d’IP]

Explications :

Le [masque d’IP] représente l'adresse IP ou le masque de sous-réseau qui doit être pris en compte. Il peut être de la forme 192.168.1.10 (et désignera alors une adresse IP précise), ou 192.168 (et désigner l'ensemble du sous-réseau 192.168.x.x et toutes les adresses IP en faisant partie).

    • le symbole "+" indique que le [masque d’IP] correspondant est autorisé.
    • le symbole "-" indique que le [masque d’IP] correspondant est interdit.
    • le symbole "?" indique que le [masque d’IP] correspondant doit être accepté côté serveur par l'intermédiaire d'une fenêtre de dialogue.
    • le symbole ":" (VNC) ou "," (RealVNC) sert de délimiteur, permettant ainsi de définir plusieurs valeurs.

On aura donc par exemple comme valeur de clé :
HKEY_LOCAL_MACHINE\Software\RealVNC\WinVNC4
"AdminPassword"=hex:dc,c6,6b,58,6d,e4,19,7c
"Hosts"="+192.168.82.0/255.255.254.0,?192.168.0.0/255.255.0.0,-255.255.255.255/0.0.0.0"

Serveur VNC sous Linux ou Windows avec SSH

Il est possible de rediriger les ports utilisés par VNC vers la machine locale à travers un tunnel SSH afin d'en sécuriser la connexion : ainsi les mots de passe VNC ne transitent pas en clair sur le réseau.

ssh $SSH_SERVER -L$LOCALPORT:$VNC_SERVER:$VNCPORT

Le cadriciel cygwin peut fournir un serveur SSH pour une machine équipée de Windows.

Commentaires

choix d'un clavier pour Mac OSX

Ce fil de discussion, https://listes.services.cnrs.fr/wws/arc/asr/2012-1..., sur la liste ASR du CNRS (inscription nécessaire) décrit le problème (et la solution) de la définition d'un clavier (français/anglais) différent du système d'origine sur le client (UltraVNC).

x11vnc

À ma connaissance, le lancement d'un serveur TightVNC (mais peut-être aussi des autres applications mentionnées), sous GNU/Linux, ne permettra pas la prise à distance "à chaud" d'une session X en cours mais permettra à un l'utilisateur du client de créer une nouvelle session X.
Or, pour prendre le cas de figure le plus courant: celui de la prise en main d'une session déjà entamée localement, c'est le serveur x11vnc qui le permet (toutefois n'importe quel client fera l'affaire comme par exemple tightvncviewer).

C'est vrai, il me semble.

Je n'ai pas testé récemment, mais cela correspond bien à ce que j'avais retenu et relu (sur RealVNC). D'ailleurs, Xvnc utilise un fichier de configuration ~/.vnc/xstartup pour définir ce qui sera démarré lors d'une nouvelle connection VNC.
Dans ce sens, le fonctionnement est différent de celui sur Windows (qui correspondrait à la méthode x11vnc) par défaut, alors que rdesktop sur Windows correspond plutôt au fonctionnement d'un lancement par vncserver/Xvnc par défaut.
A noter que x11vnc est un autre produit que ceux mentionnés ici (des "VNC standard"). Il serait concevable et tout à fait utile d'avoir une fiche spécifique sur ce logiciel donc, alors que l'utilisation du protocole VNC justifie qu'on le mentionne ici.