Vous êtes sur la page 1sur 6

Sécurité des Réseaux 

: ssh

1. SSH

SSH (Secure SHell) permet de se connecter de façon sécurisée à un système Unix,


Linux et Windows.

 ssh : le programme client permettant de se connecter au serveur


 sshd : le serveur (ssh daemon) écoutant sur le port 22 par défaut
Il existe des clients SSH pour toutes les architectures : Linux : ssh, putty...

SSH permet de garantir :


 La confidentialité : le chiffrement des données permet de garantir celle-ci. Les
protocoles tels que telnet, rlogin... envoyaient les données en clair.
 L'intégrité : SSH permet de garantir que les données circulant d'un hôte vers un
autre ne sont pas modifiés.
 L'authentification : chaque connexion SSH vérifie l'identité du serveur (par sa
clé d'hôte ~/.ssh/known_hosts) puis celle du client (par mot de passe ou clé
publique ~/.ssh/authorized_keys).
 L'autorisation : il est possible avec SSH de limiter les actions autorisées à
l'utilisateur (~/ssh/.authorization).
 Tunneling : SSH permet de sécuriser un service dont les informations circulent
habituellement en clair (POP, IMAP, VNC...). D'autres aspects du tunneling sont
la sécurisation du protocole X11 (X11forwarding) , et l'utilisation de clés privées
situées sur un hôte distant (Agent forwarding).
SSH est donc sécurisé mais ne protège pas de tout. L'authentification par mot de passe
reste relativement vulnérable (mot de passe trop facile à découvrir... toute la difficulté
d'un bon mot de passe : facile à retenir, difficile à découvrir par les autres).

L'authentification par clé


La clé permet de garantir à un système qu'un utilisateur est bien celui qu'il prétend
être...

A. NAANAA 1/6
L'authentification par clé 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.
 La sécurité est vraiment accrue car la passphrase seule ne sert à rien sans la clé
privée, et vice-versa.

2. Les tâches à effectuer


Utilisation simple de SSH
En tant qu'initiation commencer par les actions suivantes:
1. Connecter sur une machine du réseau en utilisant ssh.
2. Déconnecter avec logout.

Utilisation d'applications X distantes avec SSH


Lancer l'application xeyes par exemple à partir d'une machine du réseau en
utilisant une connexion ssh.

Changer la méthode d'authentification avec ssh-keygen


Sous sa forme la plus simple, l'authentification consiste à saisir un mot de passe,
de manière analogue à la procédure illustrée dans les exemples précédents.
Pour utiliser l'authentification par les clés publiques et les phrases de passe il
faut suivre les étapes suivantes:
1. Générer une paire de clé RSA avec ssh-keygen avec phrase de passe.
2. Copier la clé publique contenue dans ~/.ssh/id_rsa.pub vers
~/.ssh/authorized_keys de la machine distante en question en utilisant scp.
Ou bien par l’utilitaire ssh-copy-id
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 ip_machine pour
éventuellement supprimer les clés que vous ne souhaitez pas publier sur ce serveur.
3. Établir une connexion vers cette machine sur le compte en question et
noter la différence.

A. NAANAA 2/6
La transparence d'authentification avec ssh-agent
ssh-agent est l'utilitaire associé à ssh et qui permet de s'en passer des
authentifications par phrase de passe à chaque ouverture de session avec ssh. En effet,
cet utilitaire exploite les clés publiques utilisées pour les sessions ssh, et vues
précédemment, afin d'assurer la transparence de l'authentification. Une manière
simple pour le mettre en oeuvre passe par les étapes suivantes:
1. Lancer ssh-agent à l'aide de la fonction du shell eval pour pouvoir
ensuite le contacter avec ssh-add ou l'arrêter.
2. Vérifier qu'aucune clé n'est encore gérée par ssh-agent à l'aide de la
commande ssh-add.
3. Ajouter la clé crée précédemment à l'aide de ssh-add.
4. Vérifier le résultat avec ssh-add.
5. Se connecter de nouveau avec ssh sur la machine en question et noter la
différence.
6. Se déconnecter et arrêter ssh-agent.
7. Vérifier que l'authentification ne se fait plus d'une façon transparente.

3. Les solutions et les détails


Installation :
Serveur : #apt-get install openssh-server
Client : #apt-get install openssh-client

Utilisation simple de SSH


1. On suppose ici que le compte d'utilisateur est user sur les deux machines
localhost et remotehost,
user@localhost:~ # ssh user@remotehost
Utilisation d'applications X distantes avec SSH
Indépendamment des améliorations en matière de sécurité dont il vient d'être
question, le programme ssh facilite également l'utilisation d'applications X distantes.
Lorsque on appelle ssh avec l'option -X, la variable DISPLAY est automatiquement
définie sur le système distant et toutes les sorties X sont redirigées vers la machine
source à travers la connexion ssh existante. Cette fonctionnalité pratique interdit dans
le même temps les possibilités d'écoute qui existeraient sans passer par ssh, lorsqu'on
appelait à distance des applications X pour les afficher en local. Dans notre cas on
A. NAANAA 3/6
aura:
user@localhost:~ # ssh -X user@remotehost
user@remotehost:~>xeyes
A ce niveau il faut arrêter l'application xeyes qui s'affiche à l'écran pour pouvoir
continuer.
user@remotehost:~>logout
Connection to remotehost closed.

Changer la méthode d'authentification avec ssh-keygen


1. On utilise ici la commande ssh-keygen avec le paramètre -t rsa pour créer la
paire de clés RSA, cet utilitaire demande l'emplacement pour enregistrer la clé et
propose un répertoire par défaut entre parenthèses qu'on peut accepter en appuyant
sur entrée, ensuite il demande la phrase de passe avec confirmation et il se termine
par l'affichage de quelques informations sur les clés et les empreintes.
user@localhost:~ # ssh-keygen -t rsa
2. Copier le fichier id_rsa.pub en entier vers authorized_keys de la machine
remotehost en utilisant scp qui fait aussi partie du paquetage OpenSSH et réalise de
ce fait des copies sécurisées.
user@localhost:~ # scp ~/.ssh/id_rsa.pub
user@remotehost:/~/.ssh/authorized_keys
3. Connexion avec le compte user c'est la phrase de passe qui est demandée non
pas le mot de passe.
user@localhost:~ # ssh user@remotehost
La transparence d'authentification avec ssh-agent
1. eval est une fonction du shell permettant de mettre à jour les variables
d'environnement qu'utilise une application et de récupérer sa valeur de sortie. Dans ce
cas on s'intéresse aux variables d'environnement SSH_AUTH_SOCK et
SSH_AGENT_PID qui permettent de communiquer avec le ssh-agent exécuté:
user@localhost:~ # eval `ssh-agent`
Agent pid 10481
2. On visualise les clés mises en disposition de l'agent avec l'option -l de la
commande ssh-add: user@localhost:~ # ssh-add -l
The agent has no identities.
3. On utilise ssh-add sans aucun paramètre ni option pour ajouter la totalité des
A. NAANAA 4/6
clés sous ~/.ssh/id_rsa à ssh-agent, la phrase de passe est demandée pour chaque clé
ajoutée, ici il ne s'agit que d'une seule clé:
user@localhost:~ # ssh-add
Enter passphrase for ~/.ssh/id_rsa:
Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
4. On vérifie que tout s'est bien déroulé:
user@localhost:~ # ssh-add -l
1024 04:2b:03:8c:80:34:44:88:08:3c:4e:41:2c:1a:6b:f8 ~/.ssh/id_rsa(RSA)
5. On se connecte de nouveau sur user@remotehost, aucune authentification n'est
alors demandée car ssh-agent effectue la tâche en toute transparence.
user@localhost:~ # ssh user@remotehost
Last login: xxx xxx xx xx:xx:xx xxxx from xhost
Have a lot of fun...
6. On se déconnecte, on termine ssh-agent avec ssh-agent -k, un message informe
alors des variables d'environnement libérées et du pid du processus tué.
user@remotehost:~> logout
Connection to remotehost closed.
user@localhost:~ # ssh-agent -k
unset SSH_AUTH_SOCK;
unset SSH_AGENT_PID;
echo Agent pid 10481 killed;
7. On se connecte encore une fois, on remarque qu'on retrouve l'authentification
par passphrase en l'absence d'un ssh-agent en exécution.
user@localhost:~ # ssh user@remotehost
Enter passphrase for key '~/.ssh/id_rsa':

4. Configuration avancée:
Le fichier de configuration du serveur SSH est : /etc/ssh/sshd_config.
1. La ligne : PubkeyAuthentication yes
Signifie que l'authentification par clé est autorisée.
Cela ne suffit bien entendu pas car aucune clé publique n'a été envoyée sur le serveur.
L'authentification par mot de passe va être utilisée.
Après avoir envoyer les clés publiques, décommenté les lignes si n’est pas le cas :

A. NAANAA 5/6
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication yes
Et désactivé l'authentification par mot de passe
PasswordAuthentication no

2. Désactivation de l'accès direct en super utilisateur.


PermitRootLogin no

3. Liste des utilisateurs autorisés à se connecter


Il est possible de mettre en place la liste des utilisateurs qui seront seuls autorisés à se
connecter avec la directive AllowUsers : 
AllowUsers karim manel anis@127.0.0.1

La configuration par utilisateur se fait par le fichier  .ssh/config.


Exemple :
Host serveur
HostName 192.168.1.10
User mounir
Port 22
IdentityFile ~/.ssh/.id_rsa

Host *.oranix
IdentityFile ~/.ssh/.id_rsa_oranix

Avec le fichier ci-dessus, la commande ssh serveur sera équivalente à ssh -p 22 -i


~/.ssh/.id_rsa mounir@192.168.1.10, ce qui est bien plus pratique. Dans cet exemple,
quelque soit l'utilisateur auquel on veut se connecter sur la machine oranix, le fichier
d'identité est précisé.

A. NAANAA 6/6

Vous aimerez peut-être aussi