View  Edit  Attributes  History  Attach  Print  Search

GLAP-Box : Sécuriser l'accès au bureau distant par tunellisation de VNC par SSH

GLAPBOX | Procedures

Procédure ok sous Lucid 10.04 - Aout 2011

Sources utilisées :

Cette page est base sur les sources suivantes :

Explication

  • Par défaut, le niveau de sécurisation de la GLAP-Box est plutôt bas afin de faciliter la mise en oeuvre. Pour plus de détails, voir : La GLAP-Box et la sécurité
  • Si l'on est sur un réseau ouvert à internet, ou bien si l'on accède à sa GLAP-Box depuis internet, il peut être nécessaire d'augmenter significativement le niveau de sécurisation de la connexion d'accès au bureau distant par VNC à l'aide d'une tunellisation par cryptage SSH à double clé publique/privée.
  • Pour comprendre : un tel cryptage crée un "tunnel" numérique autour de la connexion qui rend impossible toute intrusion extérieure et rend également invisible tout ce qui se passe dans le tunnel lui-même.

Ce que l'on va faire ici

  • Sur cette page, on va détailler la procédure à suivre pour mettre en place une tunellisation de la connexion VNC par SSH.
  • La connexion entre les 2 ordinateurs va se faire en fait via SSH de poste à poste et ensuite on accèdera au bureau distant de la GLAP-Box avec VNC en se connectant sur le réseau local 127.0.0.1 au niveau du client au lieu de se connecter directement sur l'IP de la GLAP-Box.
  • Le principe de la procédure est un peu le même que pour un partage NFS ou encore l'accès au bureau distant par VNC :
    • il y a un paramétrage à effectuer sur le client (le poste qui va se connecter à distance)
    • et un paramétrage à effectuer sur le serveur (le poste auquel on se connecte, pour nous la GLAP-Box.

Présentation de SSH

  • A la base, SSH est un protocole de communication et de sécurisation qui permet d'obtenir une ligne de commande à distance. Ainsi, à partir d'un poste client, on accède à une ligne de commande d'un poste serveur que l'on peut contrôler à distance.
  • SSH est un système de cryptage et de tunnelisation des connexions qui utilise une clé publique et une clé privée pour assurer le cryptage des données. Un schéma vaut mieux que de longs discours :

Liens utiles :

Etape préalable : paquets à installer

sur le serveur

Sur le serveur (poste auquel on accède à distance)

  • x11vnc
  • openssh-server

sur le client

  • xvnc4viewer
  • openssh-client (déjà installé sous Ubuntu normalement)

1. Etape à réaliser côté client = Générer les clés privées et publiques à utiliser

Dans une console saisir, taper :

$ ssh-keygen -t dsa

Ceci va lancer la génération des clés publiques et privées . La procédure va demander un passphrase (équivalent mot de passe).

L'ensemble aboutit à :

  • la clé privée va être sauvée dans /home/user/.ssh/id_dsa
  • la clé publique dans /home/user/.ssh/id_dsa.pub

Ces 2 clés sont donc sur le poste client (celui qui va accéder au serveur). NE JAMAIS DIVULGUER LA CLE PRIVEE QUI DOIT RESTER SUR LE POSTE CLIENT !! Seule la clé publique va être transmise au serveur (voir ci-dessous).

2. Configuration du poste client

Editer le fichier ssh_config = en ligne de commande taper :

gksudo gedit /etc/ssh/ssh_config

Décocher le # présent devant PasswordAuthentication et passer la valeur à no (ceci exclut l'authentification par mot de passe) :

PasswordAuthentication no

Faîtes de même avec Protocol pour qu'il ne reste que Protocol 2 (le protocole 1 des clés RSA ou DSA est à proscrire car moins sécurisé) :

Protocol 2

Enregistrer le fichier ainsi modifié

3. Diffusion de la clé publique sur le poste serveur

Source : http://doc.ubuntu-fr.org/ssh_vnc

  • Créez sur le serveur le répertoire ~/.ssh/ (mkdir ~/.ssh/)
  • Enregistrez sur le ou les postes auxquels vous souhaitez accéder la clé publique (/home/user/.ssh/id_dsa.pub) copiée de votre fichier caché « ~/.ssh/id_dsa.pub ». Vous devez enregistrer la clé publique dans le répertoire caché que vous venez de créer « ~/.ssh/ » du poste serveur.
  • Puis renommez sur le poste serveur ce fichier en authorized_keys2 (le 2 signifie qu'on souhaite bénéficier du protocole SSH2). Vous vous retrouvez alors avec le fichier caché « ~/.ssh/authorized_keys2 »

Pour visualiser les fichiers cachés dans Nautilus, il faut aller dans le menu Affichage > Afficher les fichiers cachés dans une fenêtre Nautilus)

  • ATTENTION : Le fichier authorized_keys2 doit comporter la clé publique SSH sur une seule ligne. Veuillez ouvrir ce fichier dans l'éditeur (sudo gedit ~/.ssh/authorized_keys2) et assurez vous que la clé tient sur une seule ligne. Si ce n'est pas le cas veillez à décocher la case "activer le retour à la ligne" dans édition/préférences onglet affichage de l'éditeur. Puis enregistrez et fermez la fenêtre.
  • Vous pouvez diffuser cette clé publique par le moyen de votre choix :
  • copie par clé usb, envoi email…)
  • et donc aussi par partage fichier NFS...

4. Configuration du poste serveur SSH

Edition du fichier /etc/ssh/sshd_config

  • La configuration du serveur SSH est dans le fichier « /etc/ssh/sshd_config » :Editez le fichier SSH-serveur:

gksudo gedit /etc/ssh/sshd_config

Paramétrage

  • Mettez PermitRootLogin no (à vous de voir mais le laisser sur yes peut permettre toutes les modifications possibles)
  • AuthorizedKeysFile /home/[nom_d'utilisateur]/.ssh/authorized_keys2
  • PasswordAuthentication no

Passez de yes à no pour interdire l'utilisation du mot de passe et forcer l'usage de jeux de clefs public/privé (plus sûr).

  • Ne pas oublier: "UsePAM no" sinon le mot de passe sera toujours demandé.

Relancer service ssh

Ensuite on doit pouvoir relancer le serveur ssh ? sudo service ssh restart

Connexion VNC via SSH

  • Pour lancer la connexion VNC via SSH, on fait dans un Terminal sur le client (où 192.168.1.13 est l'adresse de la GLAP-Box):
ssh -L 5901:localhost:5900 glapbox@192.168.1.13

ATTENTION A BIEN UTILISER LE BON user !!

NB : cette ligne doit « lier » le port 5900 ssh sur localhost 5901 non ?

NB2 : La connexion SSH nous donne en fait une console serveur sur le client : on contrôle le serveur depuis le client.

  • puis, dans un nouveau Terminal, sur le client, on lance VNC avec
xvnc4viewer 127.0.0.1:5901

Ou sinon, on lance Terminal Server Client et on utilise l'adresse 127.0.0.1:5901

Il apparaît que xvnc4viewer lancé en ligne de commande est plus rapide que Terminal Server Client en mode non sécurisé par SSH...

  • A noter si aucun serveur VNC n'est lancé sur le serveur (GLAP-Box), on peut aussi le lancer depuis la ligne de commande une fois connecté en SSH
x11vnc -forever -rfbport 5900
  • Et ensuite on se connecte avec : xvnc4viewer

Infos utiles

Pour se déconecter du serveur

  • pour se déconnecter du serveur, saisir la commande exit dans la console de connexion SSH.

Si message d'erreur "Warning: Remote Host Identification Has Changed"

  • A la connexion, on peut avoir un message d'erreur du genre :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
5c:9b:16:56:a6:cd:11:10:3a:cd:1b:a2:91:cd:e5:1c.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:1
RSA host key for ras.mydomain.com has changed and you have requested strict checking.
Host key verification failed.
 
  • Pour résoudre le problème, si on n'utilise que 1 serveur (la Glapbox), on peut effacer le fichier ~/.ssh/known_hosts
cd ~/.ssh/
sudo rm known_hosts