OpenSSH (Open Secure Shell) est un tunnel dans lequel il est possible de faire passer des informations. Ces informations sont chiffrées et donc seuls les 2 interlocuteurs (ceux qui sont au bout du tunnel : le serveur et le client) comprennent ses informations.

SSH permet de faire transiter des informations sensibles dans un milieu dangereux. Il est possible de faire transiter des informations confidentielles dans ce tunnel au travers du réseaux internet en toute sécurité. Toute votre vie numérique (mot de passe de vos machines, photos et videos de vos vacances) peut utiliser ce tunnel.

SSH va donc nous permettre d'accéder comme son nom (shell) l'indique d'accéder à (vulgairement parlé) la ligne de commande mais également à une interface graphique déportée.

Exemple d'utilisation :
Copier les photos d'un ordinateur à un autre
Faire des sauvegardes sans recopier toutes les données à chaque fois
Récupérer les données d'un PC portable vers un autre PC
Rajouter un accès à sa web cam à distance
Monter un système de fichier à distance au travers d'un tunnel sécurisé

Mais avant cela voyons comment l'installer, et comment configurer cet outil formidable.

Le transfert va s'effectuer au travers du protocole SSH. Installez donc le serveur SSH sur la machine qui va recevoir les données :

# apt-get install openssh-server

Sans configuration particulière, l'authentification s'effectue en demandant le mot de passe de la machine A (serveur)

faire un dessin avec 3 machines et 2 box

A serveur (celui qui attend d'être contacté)
B machine dans le même sous réseau
C machine éloignée de A avec Internet entre A et elle
boxA
boxB

1. Accéder à la machine A depuis la machine A (je n'en vois pas l'utilité mais ça marche)

$ ssh localhost

2. Accéder à la machine A depuis la machine B

$ ssh utilisateur@IP_machineA

3. Accéder à la machine A depuis la machine C

$ ssh utilisateur@IP_de_la_boxA

Attention si voulez accéder à votre machineA depuis la machineC, il faut que l'adresse interne que vous déclarez dans votre boxA corresponde à l'adresse IP_machineA.

expliquer la création des clés sur le client, et comment l'échange avec le serveur

Si vous voulez authentifier “définitivement” un client auprès d'un serveur :
Il faut générer une clé sur le client par exemple sur la machine B:

$ ssh-keygen -t dsa

Si les clients sont sûrs et que le serveur n'est pas une machine de très haute importance, vous pouvez vous permettre de ne pas mettre de passphrase. Cela vous permettra de monter le système de fichier sans trop de complication.

2 clés ont été générées :

• la clé publique dans ~/.ssh/id_rsa.pub
• la clé privée dans ~/.ssh/id_rsa

explication du transfert, attention au port Décrire l'échange de clés

Puis envoyer cette clé vers le serveur.

$ ssh-copy-id utilisateur@IP_machineA

ou si le port n'est pas le 22

$ ssh-copy-id “-p port utilisateur@IP_machineA”

$ ssh-copy-id utilisateur@IP_machineA
/usr/bin/ssh-copy-id: ERROR: No identities found

il faut alors donner l'emplacement de la clé générée :

$ ssh-copy-id -i ~/.ssh/id_dsa utilisateur@IP_machineA

Après l'envoi de la clé, si lors de votre connexion il vous demande encore le mot de passe après vous avoir indiqué ceci :

Agent admitted failure to sign using the key.

C'est que le poste client (machine B) refuse de donne sa clé. Ne cherchez pas à changer les droits sur la clé, c'est inutile et vous risquez de la corrompre. D'ailleurs si vous le faîtes, le serveur (machine A) vous renvoie un message du genre :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/cl/.ssh/id_dsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: /home/cl/.ssh/id_dsa

Puis vous redemande le mot de passe… Le problème de vient pas de là. Je n'ai pas encore l'explication, mais la solution est la suivante : Lancer cette commande sur la machine B :

$ export SSH_AUTH_SOCK=0

et le tour est joué.

et pour en sortir de ce tunnel sécurisé :

$ exit

Nota : en cours d'élaboration

Le niveau de sécurité que nous souhaitons est souvent le compromis entre les risques encourus et les contraintes imposées par ce niveau.

La sécurisation des machines utilisant SSH touche en au moins 3 points, les 2 premiers points peuvent se faire sans nuire à la facilité/flexibilité de cet outil :

La connexion se fera donc avec un utilisateur UNIX. Une fois connecté il sera bien sûr possible par la suite de passer en root sur la machine. Cela renforce donc l'authentification car il faut connaître le nom d'utilisateur UNIX ainsi que son mot de passe pour la connexion puis et le mot de passe root (pour les distributions n'utilisant pas sudo)

Pour cela il faut éditer le fichier de configuration

# nano /etc/ssh/sshd_config

et changer la ligne

PermitRootLogin yes

si l'on veut interdire toute connexion directe du root

PermitRootLogin no

ou si l'on veut interdire toute connexion directe du root sauf s'il a une clé d'échange

PermitRootLogin without-password

et redémarrer le service :

# /etc/init.d/ssh restart

Il faut Cette modification s'effectue également dans le fichier de configuration.

# nano /etc/ssh/sshd_config

et changer la ligne

Port 22

en par exemple

Port 1919

Il faut choisir de préférence un port ne faisant ni partie des 1024 premiers ports utilisés (car ils il peuvent être testé par des serveurs malveillants pour tenter de pénétrer votre système) ni par un port qui est associé à un service Listes des ports, car là aussi, un serveur malveillant pourrait tenter de passer par là.

et redémarrer le service :

# /etc/init.d/ssh restart

Attention change la commande pour accéder à la machine car il faut que le client demande cette connexion via le bon port. Par défaut il n'était pas nécessaire de lui indiqué car le client “frappait” au port 22 et le serveur écoutait au port 22.

Depuis machineB :

$ ssh -p 1919 utilisateur@IP_machineA

Attention si vous voulez accéder à votre machineA depuis la machineC, il faut que le port d'écoute corresponde au port interne que vous déclarez dans votre boxA. De plus, pour les mêmes raisons évoqué dans chapitre, il est conseillé que le port externe de votre boxA ouvert pour ce service ne soit pas le port 22 et pour vous y retrouvez, je vous conseille d'utiliser le même port externe que le port interne :

Depuis machineC, la connexion sera fera :

$ ssh -p 1919 utilisateur@IP_boxA

décrire uniquement la modification du fichier de conf serveur