Implémenter l’accès sécurisé au serveur

via SSH
Sommaire
1. Présentation de protocole SSH
2. Configuration par défaut de serveur SSH
3. Configuration avancée de serveur SSH
4. Authentification par clés publique
5. Tunnels et redirection de ports

1 Présentation de protocole SSH

1.1 Introduction
SSH (ou Secure SHell) est un protocole qui facilite les connexions sécurisées entre
deux systèmes à l'aide d'une architecture client/serveur et permet aux utilisateurs de se
connecter à distance à des systèmes hôte de serveurs. Toutefois, contrairement à d'autres
protocoles de communication à distance, tels que FTP ou Telnet, SSH chiffre la session de
connexion et empêche ainsi tout agresseur de recueillir des mots de passe non-chiffrés.
SSH est conçu pour remplacer les applications de terminal plus anciennes et moins
sécurisées qui sont utilisées pour se connecter à des hôtes distants, comme telnet ou rsh
(Remote-shell). Un programme similaire appelé scp remplace des programmes moins
récents conçus pour copier des fichiers entre des hôtes, tels que rcp (Remote-copy). Étant
donné que ces applications plus anciennes ne chiffrent pas les mots de passe entre le client
et le serveur, il est recommandé d'éviter autant que possible de les utiliser. En effet,
l'utilisation de méthodes sécurisées pour se connecter à des systèmes distants, réduit les
risques aussi bien pour le système client que pour l'hôte distant.

1.2 Fonctionnalités de SSH

SSH offre les précautions suivantes au niveau de la sécurité :
 Après avoir effectué une connexion initiale, le client peut s'assurer que sa connexion
est établie avec le même serveur que lors de sa session précédente.
 Le client transmet ses données d'authentification au serveur au moyen d'un
chiffrement solide 128 bits.
 Toutes les données envoyées et reçues lors d'une session sont transférées au moyen
d'un chiffrement 128 bits, rendant ainsi le déchiffrement et la lecture de toute
transmission interceptée extrêmement difficile.
 Le client peut retransmettre des applications X11 depuis le serveur. Cette technique
appelée retransmission X11, fournit un moyen d'utiliser en toute sécurité des
applications graphiques sur un réseau.
Étant donné que le protocole SSH chiffre tout ce qu'il envoie et reçoit, il peut être
utilisé pour sécuriser des protocoles autrement vulnérables. Grâce à la technique
de retransmission de port, un serveur SSH peut être employé pour sécuriser des protocoles
non-sécurisés tels que POP, augmentant ainsi la sécurité globale du système et de ses
données.
 1.3 Pourquoi utiliser SSH ?
Les utilisateurs d'ordinateurs malintentionnés disposent d'une variété d'outils pour
interrompre, intercepter et réacheminer le trafic réseau afin de s'octroyer l'accès à un
système. D'une manière générale, ces menaces peuvent être répertoriées de la manière
suivante :
 Interception d'une communication entre deux systèmes — Dans ce scénario, le
pirate peut se trouver quelque part sur le réseau entre les entités qui communiquent,
pouvant ainsi copier toute information qui est transmise entre elles. Le pirate peut
intercepter et garder les informations ou peut les modifier avant de les envoyer au
destinataire prévu.
Cette attaque peut être orchestrée en utilisant un programme renifleur — un
utilitaire réseau courant.
 Usurpation de l'identité d'un hôte — Grâce à cette technique, le système d'un
agresseur est configuré de telle manière qu'il apparaît comme étant le destinataire
souhaité d'une transmission. Si cette stratégie fonctionne, le système de l'utilisateur
ne détecte pas qu'il communique en fait avec le mauvais hôte.
Ce type d'attaque peut être organisé grâce à l'utilisation de techniques appelées
empoisonnements DNS ou usurpation d'adresse IP.
Ces deux techniques permettent d'intercepter des informations potentiellement
confidentielles et si cette interception est effectuée pour des raisons hostiles, le résultat
peut être catastrophique.

L'utilisation du protocole SSH pour effectuer une connexion au shell à distance ou

pour copier des fichiers permet de réduire considérablement ces menaces au niveau de la
sécurité. En effet, le client et serveur SSH utilisent des signatures numériques pour vérifier
leur identité respectives. En outre, toute communication entre le système client et le
système serveur est chiffrée. Toute tentative d'usurpation d'identité à une extrémité ou à
une autre de la communication est difficilement possible puisque chaque paquet est chiffré à
l'aide d'une clé connue seulement par le système local et le système distant.

1.4 Versions du protocole SSH

À l'heure actuelle, il existe deux versions différentes du protocole SSH :
1. La version 1 de SSH utilise plusieurs algorithmes de cryptage brevetés (toutefois,
certains de ces brevets ont expiré) et expose une faille de sécurité bien connue qui
permet à un agresseur d'insérer des données dans le flux de communication.
2. La version 2 de SSH dotée d'un algorithme d'échange de clés amélioré qui offre une
protection contre le type d'agression possible avec la version 1. Ceci étant, la suite
OpenSSH prend en charge les connexions effectuées avec la version 1.
Donc, il est conseillé d'utiliser autant que possible, des serveurs et clients compatibles avec
la version 2.
 1.5 Couche SSH et Modèle TCP/IP
SSH User Authentication Protocol SSH Connection Protocol

SSH
TCP
IP
Ethernet
 La couche de transport son rôle est de faciliter une communication sécurisée entre
deux hôtes non seulement au moment de l'authentification, mais également lors de
la communication ayant lieu. Pour ce faire, la couche de transport traite le cryptage
et décryptage de données et offre une certaine protection quant à l'intégrité des
paquets de données lors de leur envoi et de leur réception. De plus, la couche de
transport effectue la compression des données permettant d'accélérer la vitesse de
transfert des informations.
 User Authentication Protocol: Authentifie l'utilisateur sur le serveur.
 Protocole de connexion: Multiplexe plusieurs canaux de communication logiques sur
une seule connexion SSH sous-jacente.

1.6 Sessions SSH

 Le processus de création d’une clé symétrique s’effectue par un algorithme d’échange de

clés, à l'aide du protocole de Diffie-Hellman.
 Le client et serveur s'échangent alors une clé pour un algorithme symétrique (typiquement,
AES).
2 Configuration par défaut de serveur SSH
2.1 Paquetages de serveur SSH
CentOS inclut par défaut l’ensemble des paquetages OpenSSH qui permette nt de
déployer le protocole SSH.
Vérifier la présence de paquetage OpenSSH sous CentOS :
# rpm -qa | grep openssh
openssh-server-5.3p1-122.el6.x86_64
openssh-5.3p1-122.el6.x86_64
openssh-clients-5.3p1-122.el6.x86_64
Notez également que les paquetages OpenSSH ont besoin du paquetage OpenSSL qui
installe de nombreuses bibliothèques cryptographiques importantes permettant à OpenSSH
de fournir des communications cryptées.
2.2 Première démarrage de serveur SSH
Le nom de démon (service) SSH est sshd :
# service sshd start
Generating SSH2 RSA host key: [ OK ]
Generating SSH1 RSA host key: [ OK ]
Generating SSH2 DSA host key: [ OK ]
Starting sshd: [ OK ]
Le protocole SSH est conçu pour fonctionner avec presque tout d'algorithme de clé publique
ou tout format de codage. Lors de premier démarrage le service sshd tente de créer la clé
publique et la clé privée pour chacun des deux algorithmes de chiffrement asymétrique RSA
et DSA.
2.3 Se connecter à distance par SSH
Pour se connecter a distant via SSH, on va utiliser deux méthodes :
 Sous Linux, via commande :
# ssh utilisateur@adresse_IP
Ou
# ssh utilisateur@nom_machine
Ou
# ssh –l utilisateur adresse_IP
 Sous Windows, avec PUTTY.
2.3.1 Sous Linux
Voici le résultat via la commande ssh:
[root@client01 ~]# ssh root@192.168.7.2
The authenticity of host '192.168.7.2 (192.168.7.2)' can't be established.
RSA key fingerprint is 76:4c:1b:9c:e5:01:8b:fe:39:39:51:57:71:2a:80:1c.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.7.2' (RSA) to the list of known hosts.
root@192.168.7.2's password:
[root@serveur01 ~]#
 Lors de l'échange des clés, le serveur s'identifie au client au moyen d'une clé
d'hôte unique.
 Si le client communique pour la première fois avec ce serveur, la clé du
serveur n'est pas connue du client et la connexion ne peut pas être établie.
 OpenSSH contourne ce problème en acceptant la clé d'hôte du serveur après
notification de l'utilisateur et vérifie l'acceptation de la nouvelle clé d'hôte.
Lors des connexions suivantes, la clé d'hôte du serveur est vérifiée en le comparant
avec une version enregistrée sur le client, permettant ainsi au client de s'assurer qu'il
communique bien avec le serveur désiré. Si, à l'avenir, la clé d'hôte ne correspond plus à la
version enregistrée sur le client, l'utilisateur doit supprimer cette dernière avant qu'une
nouvelle connexion puisse avoir lieu.

Attention : Il est tout à fait possible pour un pirate de se faire passer pour le serveur SSH lors
de la première connexion car le système local ne détecte aucune différence entre le serveur
désiré et le faux serveur créé par le pirate.
Afin d'éviter une telle situation, contrôlez l'intégrité d'un nouveau serveur SSH en
contactant l'administrateur du serveur avant d'établir la première connexion ou dans le cas
où une clé d'hôte ne correspond pas à celle stockée sur le serveur.
Pour afficher l’empreinte numérique de la clef publique au niveau de serveur SSH :
serveur01# ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
2048 76:4c:1b:9c:e5:01:8b:fe:39:39:51:57:71:2a:80:1c /etc/ssh/ssh_host_rsa_key.pub (RSA)
Vous remarquez que la même empreinte affichée lors de la connexion au serveur SSH.
2.3.2 Sous Windows
Après la validation des informations de serveur SSH envoyé par Putty, vous obtiendrez ce
message qui vous demande si ce serveur et un serveur de confiance en vérifiant l’empreinte
numérique de la clef RSA (Comme dans la connexion sous Linux) :
3 Configuration avancée de serveur SSH
3.1 Fichiers de configuration d'OpenSSH
OpenSSH est constitué de deux ensembles de fichiers de configuration :
 Un pour les programmes client (ssh, scp et sftp)
 L'autre pour le service (sshd).
Les informations de configuration SSH qui s'appliquent à l'ensemble du système sont
stockées dans le répertoire /etc/ssh/ où figurent :
 moduli — Fichier contenant les groupes Diffie-Hellman utilisés pour l'échange de clés
Diffie-Hellman qui est crucial pour la création d'une couche de transport sécurisée.
Lorsque les clés sont échangées au début d'une session SSH, une valeur secrète
partagée ne pouvant être déterminée que conjointement par les deux parties est
créée. Cette valeur est ensuite utilisée pour effectuer l'authentification de l'hôte.
 ssh_config — Fichier de configuration client SSH pour l'ensemble du système.
o Il est écrasé si un même fichier est présent dans le répertoire personnel de
l'utilisateur (~/.ssh/config).
 sshd_config — Fichier de configuration pour le démon sshd.
 ssh_host_rsa_key — Clé RSA privée utilisée par le démon sshd pour la version 2 du
protocole SSH.
 ssh_host_rsa_key.pub — Clé RSA publique utilisée par le démon sshd pour la version
2 du protocole SSH.
 ssh_host_key — Clé RSA privée utilisée par le démon sshd pour la version 1 du
protocole SSH.
 ssh_host_key.pub — Clé RSA publique utilisée par le démon sshd pour la version 1
du protocole SSH.
 ssh_host_dsa_key — Clé DSA privée utilisée par le démon sshd.
 ssh_host_dsa_key.pub — Clé DSA publique utilisée par le démon sshd.
Les informations de configuration SSH spécifiques à l'utilisateur sont stockées dans son
répertoire personnel à l'intérieur du répertoire ~/.ssh/ où figurent :
 known_hosts — Fichier contenant les clés d'hôtes DSA/RSA des serveurs SSH
auxquels l'utilisateur a accédé. Ce fichier est très important car il permet de garantir
que le client SSH se connecte au bon serveur SSH.
 authorized_keys — Fichier contenant une liste de clés publiques autorisées pour les
serveurs. Lorsque le client se connecte à un serveur, ce dernier authentifie le client
en vérifiant sa clé publique signée qui est stockée dans ce fichier.
 id_rsa — Clé RSA privée utilisée par ssh pour la version 2 du protocole SSH.
 id_rsa.pub — Clé RSA publique utilisée par ssh pour la version 2 du protocole SSH.
 id_dsa — Fichier contenant la clé DSA privée de l'utilisateur.
 id_dsa.pub — Clé DSA publique de l'utilisateur.
 identity — Clé RSA privée utilisée par ssh pour la version 1 du protocole SSH.
 identity.pub — Clé RSA privée utilisée par ssh pour la version 1 du protocole SSH.

3.2 Configuration avancée de serveur SSH

Voici le contenu de fichier de configuration /etc/ssh/sshd_config après avoir élevé tous les
commentaires :
# cp sshd_config sshd_config.orig
# grep -E "^[^#]" /etc/ssh/sshd_config.orig > /etc/ssh/sshd_config
Protocol 2
SyslogFacility AUTHPRIV
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
X11Forwarding yes
Subsystem sftp /usr/libexec/openssh/sftp-server

Explication :
 Le type de d’authentification par défaut utilisée par le serveur SSH est
l’authentification par mot de passe. « PasswordAuthentication yes »
 L’authentification normale d’UNIX est fournie par le module PAM (Pluggable
Authentication Modules), donc le démon sshd il va utiliser ce module pour
authentifier ses utilisateurs « UsePAM yes ».

3.3 Affiné la configuration de serveur SSH

Voici les options à ajouter ou à décommenter dans le fichier de configuration
/etc/ssh/sshd_config:
# Désactiver le protocole version 1
Protocole 2
# Faire écouter le démon sshd, que sur une interface donnée.
ListenAddress @IP
#Ne pas autoriser l’authentification de l’utilisateur root
PermitRootLogin no 
# N’autoriser pas mes mot de passe vide. Par défaut, cette option est sur « no ».
PermitEmptyPasswords no
# N’autorise pas certains utilisateurs à avoir accès via SSH à cette machine.
DenyUsers user3 user4
# Autorise seulement certains utilisateurs à avoir accès via SSH à cette machine.
AllowUsers user1 user2
# Permet de limiter le nombre de connexion :
# Le 10 représente le nombre de connexions acceptées sans qu'un utilisateur ait réussi à
# s'identifier, si cela passe au-dessus de 10, il y a 30 % de chances que les suivantes
# soient bloquées, ça augmente linéairement jusqu'à complétement bloquer les connexions à
# 60 %.
MaxStartups 10:30:60
# Permet de limiter le nombre de de tentative d'authentification : ici, 3.
MaxAuthTries 3
# Ajouter une bannière (elle sera récupérée du fichier) pour les utilisateurs se connectant
# au serveur OpenSSH.
Banner /chemin/un_fichier
# Change le port d'écoute du serveur openSSH.
# Par défaut, le serveur openSSH écoute sur le port 22.
# Ou on peut mettre l’option
### ListenAddress @IP:2222
Port 2222
# Empêcher la connexion SSH de s’expirer.
TCPKeepAlive yes
Enregistrer le fichier /etc/ssh/sshd_config est redémarrer le service sshd, pour activer les
modifications apporter.
Note:
 AllowGroups autorise seulement les utilisateurs dont le groupe principal ou les
groupes secondaires correspondent à un des groupes spécifique à se connecter.
 DenyGroups n’autorise pas les utilisateurs dont le groupe principal ou les groupes
secondaires correspondent à un des groupes spécifique à se connecter.
 Pour que vous n’obteniez pas des résultats flous concernant l’utilisation des
directives Allow/Deny, il faut respecter l’ordre suivant : DenyUsers, AllowUsers,
DenyGroups, et finalement AllowGroups.
o Au préalable, soit vous autoriser ou refuser l’accès à des utilisateurs
(DenyUsers ou AllowUsers), ou soit vous autoriser ou refuser l’accès à des
utilisateurs appartenant à des groupes spécifiques (DenyGroups ou
AllowGroup).
 Pour exécuter plusieurs règles d’accès aux groupes et utilisateurs, soit vous exécuter
plusieurs instances sshd chacun va écouter sur une adresse/port différent et avec des
configurations distinctes.
# /usr/sbin/sshd /etc/sshd_2_config &
o Ou utiliser la bibliothèque TCPWrapper qui fournit un contrôle d'accès simple
et une journalisation normalisée pour les applications prises en charge qui
acceptent les connexions via un réseau.
 Si vous avez changé le numéro de port par défaut, il faut le spécifier dans la
commande de connexion :
# ssh -l user01 IP_Serveur -p 2222
 Pour autoriser tous les utilisateurs d’un réseau, il faut modifier l’option AllowsUser
comme suite :
AllowUsers *@192.168.0.*
 Pour plus d’information sur les options de daemon SSH, taper la commande :
# man sshd_config.
4 Authentification par clés publique
4.1 Principe
SSH est donc sécurisé mais ne protège pas tout. L'authentification par mot de passe
reste relativement vulnérable (mot de passe trop facile à découvrir).
Face à la faiblesse de l'authentification par mot de passe, l'authentification par clé se révèle
être très efficace.
La clé permet de garantir à un système qu'un utilisateur est bien celui qu'il prétend être, elle
fonctionne grâce à 3 composants : 
 Une clé publique : elle sera exportée sur chaque hôte sur lequel on souhaite pouvoir
se connecter.
 Une clé privée : elle permet de prouver son identité aux serveurs.
 Une passphrase : Permet de sécuriser la clé privée (notons la subtilité, passphrase et
pas password ... donc "phrase de passe" et non pas "mot de passe").
La sécurité est vraiment accrue car la passphrase seule ne sert à rien sans la clé privée, et
vice-versa.

4.2 Création de la paire de clé

Il existe 2 types de clés : RSA et DSA (Chacune pouvant être de longueur différente : 1024,
2048, 4096 bits et les clés inférieures à 2048 bits sont à éviter).
La création de la paire de clé se fait avec la commande ssh-keygen, si vous n’avez pas
spécifié aucun paramètres au commande, les options par défaut sont de type RSA en 2048
bits.
Il faut créer la paire de clé au nom d’utilisateur qui va se connecter à distance (Cliente), donc
il faut s’assurer que l’utilisateur est connecté en local avant de taper la commande :
# su user01
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user01/.ssh/id_rsa):
Created directory '(/home/user01/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user01/.ssh/id_rsa.
Your public key has been saved in /home/user01/.ssh/id_rsa.pub.
The key fingerprint is:
6d:3c:90:3b:be:55:fd:c3:fe:89:82:23:89:6c:4d:29 user01@client
The key's randomart image is:
+--[ RSA 2048]----+
| |
| . |
| o |
| = . |
| S = . . |
| E + o o .. |
| . = o o o.|
| + + = . o o|
| . o . .. oo|
+-----------------+
Deux fichiers ont été créés (dans le dossier ~/.ssh/) :
 id_rsa (ou id_dsa dans le cas d'une clé DSA) : contient la clé privée et ne doit pas être
dévoilé ou mis à disposition.
 id_rsa.pub (ou id_dsa.pub dans le cas d'une clé DSA) : contient la clé publique, c'est
elle qui sera mise sur les serveurs dont l'accès est voulu.
Note :
 Pour créer une clé DSA de 2048 bits :
ssh-keygen -t dsa -b 2048 -C username@domain.tld.
o Le commentaire permet de distinguer les clés, utile quand on a plusieurs clé
(notamment une personnelle et une pour le travail). Ici la distinction se fait
sur l'adresse e-mail.
o Si le commentaire est omis, il sera de la forme user@host.
 Pour modifier votre "passphrase" sur une clé privée DSA par exemple, utilisez la
commande :
ssh-keygen -p -f ~/.ssh/id_dsa

4.3 L’envoi de la clé publique

Pour effectuer une authentification par clés, il suffit que vous envoyiez la clé publique de
l’utilisateur de la machine cliente, vers la machine sur laquelle vous voulez vous connecter à
distance (Serveur), et l’inscrivez dans le fichier ~/.ssh/authorized_keys de machine serveur.
 4.3.1 Première méthode de copie d'une clé :
$ cat ~/.ssh/id_rsa.pub | ssh user02@ip_machine "cat - >> ~/.ssh/authorized_keys"
Ou
$ cat ~/.ssh/id_rsa.pub | ssh user02@ip_machine "mkdir -p ~/.ssh && chmod 700
~/.ssh && cat >> ~/.ssh/authorized_keys"
Cette commande va lire le fichier $HOME/.ssh/id_rsa.pub (clé publique), se connecter sur le
serveur ayant l'adresse IP « ip_machine » avec le nom d'utilisateur « user02 » et ajouter au
fichier des clés autorisées ($HOME/.ssh/authorized_keys) le contenu de la clé lue.
4.3.2 Deuxième méthode de copie d'une clé :
Il s'agit du même principe que la première méthode, sauf que tout est décomposée (utile
pour bien comprendre) :
$ scp ~/.ssh/id_rsa.pub user02@ip_machine:/tmp/
User02@ip_machine's password:
id_rsa.pub 100% 609 0.6KB/s 00:00
Ensuite:
$ ssh user02@ip_machine
$ cat /tmp/id_rsa.pub >> /user02/.ssh/authorized_keys
$ rm /tmp/id_rsa.pub
4.3.3 Troisième méthode :
Il s'agit de la méthode la plus automatisée et la plus simple.
$ ssh-copy-id -i ~/.ssh/id_rsa.pub user02@ip_machine
ssh-copy-id srvuser@192.168.7.2
user02@ip_machine's password:
Now try logging into the machine, with "ssh user02@ip_machine'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
 ssh-copy-id va copier la clé publique sur l'hôte distant. Par mesure de sécurité, le
script ajoute l'extension .pub au fichier d'identité si elle a été omise.
 On peut tapez juste la commande ssh-copy-id user02@ip_machine
 Notez que si vous possédez plusieurs clés, cette commande risque d'en copier
plusieurs. Pensez à vérifier le fichier ~/.ssh/authorized_keys sur serveur pour
éventuellement supprimer les clés que vous ne souhaitez pas publier sur ce serveur.
4.3.4 Quatrième méthode :
Si vous n’avez pas d’accès basé sur SSH pour votre Serveur, vous pouvez procéder au
copiage de la clé publique manuellement.
4.3.5 Piège à éviter :
Il faut s'assurer dans le cas où un fichier authorized_keys est présent, qu'il se termine
bien par une nouvelle ligne. Sinon le rajout se fera à la volée et 2 clés (la dernière et celle
rajoutée) seront inutilisables.

4.4 Paramétrage de SSHd

Au niveau de serveur, l'authentification par clé est désactivée par défaut, pour
l’activé il faut décommenter l’option PubKeyAuthentication dans le fichier de configuration
/etc/ssh/sshd_config :
PubkeyAuthentication yes
 La valeur par défaut de la clé PubkeyAuthentication est Yes, signifie que
l'authentification par clé est autorisée.
 Cela ne suffit bien entendu, car aucune clé publique n'a été envoyée sur le serveur.
L'authentification par mot de passe va être utilisée.
Au niveau de serveur, voici les options a décommenté dans le fichier de configuration
/etc/ssh/sshd_config:
# Désactivation de l'authentification par mot de passe
PasswordAuthentication no
# Activation de l'authentification par clé
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication yes
Note
 Il est possible de définir la machine distante dans /etc/hosts (ou dans .ssh/config)
pour qu'elle soit identifiée par son nom.
 De plus, si l'utilisateur auquel on souhaite se connecter est le même sur la machine
distante, on remplacera « user@ip_machine » par « nom_machine ». Nous pourrons
donc nous connecter plus simplement avec la commande suivante :
user01$ ssh ip_machine
4.4.1 Test de connectivité
user01$ ssh user02@ip_machine
Enter passphrase for key '/home/user01/.ssh/id_rsa':
4.5 ssh-agent
Le serveur SSH est maintenant plus sécurisé, mais taper des passphrases à
longueur de journée peut se révéler être très pénible surtout si on a choisi une « vraie »
passphrase.
L'agent SSH permet de taper la passphrase une seule fois et de la conserver en
mémoire pendant tout son fonctionnement. Les communications SSH fonctionneront donc
de façon transparente.
4.5.1 En ligne de commande
Il faut lancer l'agent avec un SHELL (le plus simple étant de le lancer avec la variable
$SHELL qui contient le SHELL courant).
$ ssh-agent $SHELL
Ou
$ ssh-agent /bin/bash
Ensuite le programme ssh-add permet de charger les clés présentes dans ~/.ssh/. La
passphrase est demandée, toutes les connexions nécessitant les clés chargées par l'agent
seront transparentes.
$ ssh-add
Enter passphrase for /home/user01/.ssh/id_rsa:
Identity added: /home/user01/.ssh/id_rsa (/home/user01/.ssh/id_rsa)
$ ssh user02@ip_machine
Last login: Sun Feb 4 22:53:34 2018 from ip_dernier_client
5 Tunnels et redirection de ports
Faire un tunnel SSH est un moyen simple de chiffrer n'importe quelle communication
TCP/IP entre votre machine et une machine sur laquelle vous avez un accès SSH.
Il existe trois modes de tunnels :
 Le Mode Local ;
 Le Mode Distant ;
 Le Mode dynamique (basé sur l'utilisation d'un serveur SOCKS).

5.1 Redirection locale de port

La redirection de port local permet de transmettre les demandes locales sur le port
« port-local » vers le serveur SSH qui les envoie sur le port « port-distant ».
Supposons qu'on veuille se connecter à un site web (requête HTTP) mais qu'il soit bloqué.
On va simplement transiter via le tunnel SSH pour atteindre notre serveur SSH, qui ira
chercher l'information et nous la renverra.

5.1.1 Configuration simple

Taper la commande sur la machine Cliente :
ssh -fN -L port-local:machine-distant:80 user01@machine-distante
 -L : Permet de rediriger un port local vers un port distant sur une machine distante.
 -N : Ne pas exécuter de commande distante.
 -f : Exécute le programme en tâche de fond.
 Pour configurer la retransmission de port de manière à ce qu'elle écoute sur les ports
inférieurs à 1024, il est nécessaire d'avoir un accès de niveau super-utilisateur (ou
root).
 5.1.2 Test de redirection locale de port
Cet exemple, pour simple qu'il soit, permet de montrer la simplicité de la création
d'un tunnel. Une fois que le tunnel TCP/IP est créé, il suffit de rediriger les clients utilisés
pour qu'ils utilisent le port local redirigé et non plus le port distant avec une transmission en
clair.
Depuis la machine cliente, tapez l’adresse http://localhost:8080 dans le navigateur :

Note :
 Pour chaque type de transaction différent (exemple : navigation internet, connexion
à un serveur de messagerie, envoi de fichier par FTP, etc.) il faudra ouvrir un nouveau
tunnel. Cela se comprend facilement car les ports utilisés sur la machine hôte sont
différents.
 Pour fermer le tunnel, récupérez l'identifiant du processus en tapant la commande
suivante depuis la machine cliente:
# ps aux | grep ssh
o Puis tuez le processus :
# kill -9 id_du_processus

5.2 Redirection distante de port (Redirection inverse)

SSH est un très bon outil pour accéder à la machine ou au serveur distant en toute
sécurité. Mais, le problème se pose lorsque vous essayez de vous connecter à un serveur
distant qui se trouve derrière un pare-feu (Par exemple Serveur Email), et ce pare-feu refuse
toute connexion entrante ou demande de transfert de données qui n'a aucune demande
sortante précédente. Cela signifie que seules les connexions autorisées par la machine du
serveur distant sont autorisées. C'est un vrai problème pour ceux qui veulent accéder à
distance à cette machine serveur.
Reverse SSH (Ou la redirection distant) fournit une technique par laquelle vous
pouvez simuler un SSH normal sur ce serveur distant.
Le principal problème est que le pare-feu rejette la connexion SSH que votre machine
essaie d'établir avec la machine du serveur distant. Mais vous savez que le même pare-feu
n'aura aucun problème avec les connexions provenant de la machine du serveur. Alors,
pourquoi ne pas demander à quelqu'un (Administrateur) qui est assis derrière le pare-feu de
faire quelque chose avec lequel vous pouvez atteindre votre objectif d'accéder à distance au
serveur.
Donc la redirection distante de port, permet de rediriger un port distant vers un port
local sur la machine locale (c’est l’inverse de la redirection local qui permet de rediriger un
port local vers un port distant sur une machine distante).
Depuis le serveur, taper la commande :
ssh -fN -R port-distant:@machine-local:port-local user@machine-
distante
 Vous pouvez donc utiliser la commande ssh avec l'option -R (à partir du serveur dans
notre cas) pour vous connecter à votre machine, allouer un port et vérifier que toute
demande de connexion sur ce port est transmise au port ssh du serveur distant.
 Au lieu que votre machine fasse un SSH, la machine du serveur fait un SSH et grâce à
la redirection de port, vous êtes sûr de pouvoir retourner à la machine du serveur.

5.2.1 Configuration de redirection distant

Voici la commande que votre Administrateur assis sur le serveur distant doit exécuter sur le
serveur:
ssh -fN -R 2222:localhost:22 username@yourMachine-ipaddress
 Ainsi, cette demande de connexion ssh provenant du serveur distant de votre
machine veillera à ce que toute demande de connexion ssh pour le port 2222 sur
votre machine soit transmise au port 22 du serveur distant.
 Un processus ssh est lancé automatiquement sur la machine client, qui va créer le
tunnel avec le serveur.
o Vérifier avec # ps aux | grep ssh sur la machine cliente.
Maintenant, depuis la machine cliente, taper la commande suivante :
ssh username@localhost -p 2222
 Ici, bien qu'il puisse sembler que vous fassiez SSH sur localhost mais votre requête
serait transmise à l'hôte distant. Donc, vous devriez utiliser votre compte 'nom
d'utilisateur' sur le serveur distant et quand vous êtes invité pour le mot de passe,
entrez le mot de passe correspondant.
 5.2.2 Amélioration
Lors de la configuration de la SSH inverse, c'est que vous devez demander à un
Administrateur qui est assis derrière le pare-feu de créer une connexion SSH en premier. Ce
n'est pas faisable à chaque fois.
Pour résoudre ce problème, vous pouvez configurer une machine hors pare-feu
(comme la vôtre) d'une manière toujours active. Appelons cette machine comme
machine_z.
L'avantage de machine_z est que vous pouvez une fois faire ce SSH inverse et le
laisser comme ça. À tout moment, lorsque vous devez vous connecter à une machine
distante, vous pouvez entrer SSH dans machine_z sur un port spécifié (comme indiqué
précédemment) et votre demande de connexion sera transmise à la machine serveur
distante.
5.3 Redirection dynamique des ports
Jusqu'à présent, nous avons vu comment transférer les ports locaux et distants avec
SSH. En effet, vous devrez spécifier différents ports pour chaque destination et chaque
service auquel vous voulez accéder, ce qui peut s'avérer extrêmement lourd si vous en avez
beaucoup.
La solution qui a été trouvée pour palier à ces problèmes est la redirection
dynamique des ports. Vous créez un port d'écoute qui se charge de prendre toute trame
réseau qui rentre "telle quelle" et de la faire exécuter depuis l'autre bout du tunnel.
Pour configurer le transfert de port dynamique, tapez la commande suivante:
ssh -fN -D port-local nomutilisateur@server
Maintenant que votre tunnel est ouvert, nous allons demander à vos applications de
l'emprunter.
5.3.1 Exemple : navigation sur l'Internet
Ouvrez donc votre navigateur. Allez dans le Menu -> Options -> avancé -> Proxy réseau ->
paramètres de connexion.
Vous arrivez devant un écran tel que celui-ci :
Ensuite, votre navigateur devrait correctement emprunter votre tunnel et tout devrait se
dérouler correctement.
5.4 Exemple de redirection avancée
 5.5 Automatisation de tâches SSH
Dans la mesure où il est possible de passer des commandes à distances sur
un serveur, sans avoir à saisir de mot de passe ou de "passphrase", on peut
envisager l'automatisation de tâches entre machines et dans des tunnels, comme par
exemple les sauvegardes ou la synchronisation de fichiers. Il suffira pour cela de
créer un compte associé à la tâche, lui créer une clé privée et exporter sa clé
publique sur les différentes machines.
Attention toutefois, les manipulations sur les serveurs requièrent un accès
root. Cela signifie que votre compte opérateur, devra avoir un accès root sur le
serveur ce qui n'est jamais très bon.
Vous aurez intérêt à réfléchir à la façon de réaliser le traitement sans que ce
compte opérateur ait besoin du compte "super utilisateur".
Exemples:
# ssh srvuser@192.168.7.2 "df -hT"
5.6 Montage distant avec SSHFS
5.7 SFTP