wikinotes

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
{{tag>cours administration système sysadmin linux}}

Notes et transcriptions du cours "[[https://openclassrooms.com/fr/courses/7274161-administrez-un-systeme-linux|Administrez un système Linux]]" disponible sur la plateforme [[https://openclassrooms.com|Openclassrooms]].


====== Connectez-vous à distance avec SSH ======

===== Découvrez les protocoles de cryptographie asymétrique =====

Rassurez-vous, l'idée derrière ces mots un peu barbares est simple : il s'agit de mettre en œuvre des mécanismes pour garantir la sécurité de l'échange entre vous et votre serveur sur deux aspects principaux :

  - L'échange a bien lieu avec votre serveur ;
  - Vous êtes bien le seul à pouvoir lire les informations transmises.

Ces deux aspects historiques de la sécurité de l'information ne datent pas d'aujourd'hui : les Égyptiens utilisaient déjà des principes de chiffrement pour s'assurer de la confidentialité des échanges ! 

D'ailleurs, avant toute chose, un peu de vocabulaire :

  * **Cryptologie** : C'est la science du secret dans la transmission de l'information.
  * **Cryptographie** : C'est une discipline de la cryptologie assurant notamment la confidentialité, l'authenticité et l'intégrité du message dans une transmission.
  * **Chiffrer** : On **chiffre** un message afin de s'assurer qu'il est secret.
  * **Déchiffrer** : On **déchiffre** un message afin de récupérer les données d'origine, lisibles et compréhensibles.
  * **Crypter** : On crypte lorsqu'on veut altérer un message dans l’objectif qu’il ne soit plus lisible, à jamais.
  * **Décrypter** : On essaie cependant de décrypter un message chiffré lorsqu'on ne connaît pas la clé de déchiffrement.

Le principe de la cryptographie est le suivant :

  * Déterminer un algorithme permettant de chiffrer un message ;
  * Communiquer cet algorithme à votre correspondant afin qu'il puisse déchiffrer le message. 

Prenons un exemple tout bête : Imaginons que vous souhaitiez communiquer la phrase suivante “Linux rocks !” (et c’est vrai…) à votre correspondant. Mais vous voulez être sûr qu'une personne lambda qui tomberait volontairement ou par hasard sur votre message ne puisse pas le lire.

Vous vous mettez d'accord avec votre correspondant sur l'algorithme suivant :

  * Décalage de deux touches vers la gauche sur un clavier AZERTY ;
  * Décalage d'une seule touche si pas possible de deux ;
  * Aucun décalage si le décalage d’une seule touche n’est pas possible non plus.

Votre message chiffré devient : “Jyvt< zuwhq ;”.

Vous conviendrez que le message est, d’emblée, beaucoup moins lisible par un tiers qui ne connaît pas d'algorithme !

Nous venons ici d'illustrer le principe de **cryptographie symétrique** (aussi nommé “à clé secrète"). Le même algorithme, la même clé va servir à chiffrer et déchiffrer le message. C'est simple, efficace et très performant. 

Le gros inconvénient de cette méthode réside dans la criticité de cette clé unique, qui doit être très protégée et transmise de façon sûre à vos correspondants.

Bien entendu, notre clé ici est ridicule, un calculateur mettrait quelques millisecondes à la casser, et un humain familier des processus de cryptographie le ferait également assez rapidement.

Heureusement pour nous, l'informatique peut nous fournir assez facilement des algorithmes de chiffrement performants :

  * **DES** (**D**ata **E**ncryption **S**tandard) d'IBM,
  * ou encore **AES** (**A**dvanced **E**ncryption **S**tandard), qui est probablement le plus courant aujourd'hui.

Pour résoudre le problème de la criticité de la clé de chiffrement symétrique, nous employons plutôt la **cryptographie asymétrique**, c'est à dire l'utilisation de deux clés plutôt qu'une :

  * Une **clé** dite **publique**, qui va servir à l'interlocuteur à **chiffrer** le message, et qui peut être diffusée sans criticité absolue, puisqu'elle ne sert qu'à chiffrer.
  * Une **clé** dite **privée**, qui va servir à **déchiffrer** le message, et qui est à conservée précieusement, et doit rester confidentielle.

Comment la clé privée déchiffre-t-elle le message chiffré à partir de la clé publique ?

Et bien, en utilisant un procédé mathématique nommé **brèche secrète** : La clé publique est générée à partir de la clé privée, qui y laisse une brèche secrète, soit un élément permettant de déchiffrer le message...

Bref, sans trop rentrer dans le détail des mathématiques, retenez simplement que la clé publique sert à chiffrer et que la clé privée sert à déchiffrer.

Ce processus présente l'avantage d'être très sécurisé, une personne lambda en possession de la clé publique (seul élément à être transmis) ne pourra pas déchiffrer le message. 

Ajoutons à cela l'avantage de pouvoir identifier de manière sûre la provenance du message en inversant la transmission.

En effet, un message chiffré à l'aide de la clé privée présente une **empreinte** (on parle ici de **condensat** ou de **hash**). **Ce condensat est identique à celui du même message chiffré avec la clé publique**.

Le gros inconvénient de cette méthode réside dans ces performances. En effet, la cryptographie asymétrique est beaucoup plus gourmande en ressources de calcul que la cryptographie symétrique. Les deux principaux algorithmes de cryptographie asymétrique sont **RSA** et **DSA**, et ils sont environ 1 000 fois plus lents que DES.

Bon, ok, mais quid de notre serveur SSH du coup ?

Et bien, le protocole SSH se définit par l'utilisation des deux procédés de cryptographie :

  - Asymétrique pour mettre en place un échange sécurisé avec le client ;
  - Symétrique pour gérer les données sur une communication établie.

Le principe de fonctionnement est le suivant :

  - Le serveur écoute les demandes de connexions entrantes ;
  - Un client demande une connexion, le serveur lui répond les algorithmes de chiffrement à sa disposition ;
  - Le client valide un algorithme et le serveur fournit au client sa clé publique ;
  - À partir de ce moment-là, le client peut vérifier que tous les messages qu'il va recevoir proviennent bien du serveur ;
  - Le client et le serveur échangent grâce à la cryptographie asymétrique pour s'accorder sur une clé de chiffrement symétrique basée sur un très grand nombre premier, on l'appelle la **clé de session SSH** ;
  - Une fois cette clé partagée, le client et le serveur peuvent l'utiliser pour tout le reste de la session.

Voilà pour la théorie, passons maintenant à la pratique !

===== Installez un service SSH =====

Parmi les nombreuses distributions Linux, OpenBSD, dérivée de la branche 4.4DSB, est l'une des plus anciennes (1994) et des plus réputées sur l'importance qu'elle accorde à la sécurité.

L'équipe de développement de cette distribution a donc construit une brique logiciel basée sur le protocole SSH : OpenSSH. Cette brique logicielle fournit notamment les éléments suivants :

  * ''sshd'': le service SSH ;
  * ''ssh'': le client SSH ;
  * ''ssh-keygen'' et ssh-copy-id: les utilitaires de gestion de clé RSA, DSA ;
  * ''scp'' et ''sftp'': les clients permettant le transfert de données via SSH.

Nous allons nous intéresser à ''sshd'', le processus service s'appuyant sur le protocole SSH.

Le code source du service SSH est diffusé sous licence BSD et est porté pour les principales distributions Linux.

Ainsi, il est possible de trouver un package  ''openssh-server'' pour les distributions Debian, RedHat et leurs dérivées respectives. Néanmoins, il est également possible de trouver les [[https://www.openssh.com/portable.html|sources du serveur]].

Le service SSH est un logiciel installé par défaut avec toutes les distributions. Même lorsqu'il s'agit d'une version minimale de la distribution, vous aurez la possibilité de l'installer dès le départ.

<code bash>
# Installer le serveur SSH
apt-get install openssh-server

# Vérifier l'état du service
systemclt status sshd

# Afficher les ports ouverts par le service avec ss (remplace netstat)
ss -lptun | grep ssh

# Démarrer automatiquement le service SSH
systemctl enable sshd 
</code>


===== Connectez-vous à un service SSH =====

Bien entendu, les développeurs de la brique logicielle OpenSSH fournissent également la partie cliente, nommée SSH. Ce logiciel permet de se connecter à distance sur un serveur disposant d'un service SSH. Pour l'installer, il suffit de charger les packages associés.

Vous allez sûrement constater un nombre d'options et de paramètres assez conséquent pour la commande ssh. Mais finalement, pour une utilisation basique du client, il suffit de lancer le programme en indiquant :

  * L'adresse du serveur distant auquel se connecter ;
  * Le compte utilisateur avec lequel l'authentification doit s'effectuer.

La partie la plus intéressante de la connexion SSH réside probablement dans la gestion et l’échange des clés dont on a parlé plus haut. Ci dessous on va :

  * Initier une première connexion au service SSH ;
  * Etudier l’option -p de la commande ssh ;
  * Observer le condensat pendant le processus de connexion, et la gestion des clés échangées ;
  * Voir une erreur très classique des connexions via SSH : lorsque le serveur qui héberge le service a changé et que les clés ne correspondent plus ! Dans ces cas-là, la commande ''ssh-keygen'' est votre meilleure amie.

<code bash>
# Connexion au serveur distant
ssh user@host.name

# Equivalent
ssh -l user -h hots.name
</code>

Le plus souvent, sans configuration particulière, lors du premier contact, l'authenticité de serveur distant n'est pas établie par le client. Un message l' indique. Lorsque l'utilisateur valide l'échange, la clé publique du serveur distant est enregistrée : cela permettra au client de vérifier lors des prochains échanges que son interlocuteur est identique ( le serveur distant est bien le même).

Les condensats des clé publiques des serveurs connus sont enregistrés par le client dans le fichier ''~/.ssh/known_hosts''.
 
N'oubliez pas cependant que le service SSH vous permet de vous connecter de manière sécurisée, à distance, sur votre serveur Linux. C'est tout.

Lorsque le processus de connexion/authentification est terminé, le service SSH rend la main en exécutant le shell associé au compte de connexion.

Les données de la session shell sont ensuite chiffrées via le protocole SSH.

Dernier point : la brique logicielle OpenSSH est disponible pour tous les Unix/Linux, si vous souhaitez utiliser un client SSH sur les ancinnes versions de Windows, il est nécessaire d'installer PuTTY par exemple, qui permet d'obtenir avec le même logiciel un client SSH ainsi qu'un émulateur de terminal.


===== Sécurisez votre connexion SSH =====

Allons maintenant un peu plus loin avec la connexion SSH.

Le point faible de la connexion telle que décrite ci-dessus reste bien évidemment le mot de passe du compte utilisateur : lorsque vous allez multiplier les connexions sur différents serveurs, avec différents comptes utilisateurs, la gestion de ces mots de passe va se compliquer. Par ailleurs, la saisie d'un mot de passe est toujours une source de faille potentielle, que ce soit sur votre poste de travail, ou encore avec vos collègues...

L'idée ici est une nouvelle fois d'utiliser les bienfaits de la cryptographie asymétrique. Il s'agit de générer, en tant que client, notre propre jeu de clé privée/clé publique. Cela permettra notamment de diffuser cette clé publique sur les serveurs pour faciliter notre authentification avec la clé privée associée.

Oui, vous avez bien compris, le client va aussi diffuser sa clé publique sur le serveur

Attention : ce processus d’authentification par clés asymétriques est TRÈS important en termes de sécurité, et vous allez probablement le rencontrer très souvent en entreprise. Donc prenez bien le temps de le comprendre parfaitement. 

On va :

  * Utiliser la commande ''ssh-keygen'' pour générer vos propres clés SSH ;
  * Diffuser votre clé publique sur le serveur via la commande ''ssh-copy-id'' ;
  * Se connecter sans saisir de mot de passe au serveur grâce à cet échange de clés !


<code bash>

# Depuis le poste client

# L'utilisateur génère sa paire de clé
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N ''
</code>

L'option -N permet de ne pas associer de mot de passe à la clé : on ne veut pas utiliser de mot de passe lors de l'authentification : c'est bien la détention de la clé rivée qui fera foi (preuve par possession)

Une fois la paire de clés générée, l'utilisateur va pouvoir diffuser sa clé publique sur le serveur sur lequel il souhaite pouvoir se connecter.

<code bash>
ssh-copy-id -i ~/.ssh/id_rsa.pub user@name.server
</code>

Après execution de la commande précédente, sur le serveur distant, dans le dossier ''~/.ssh/'' de l'utilisateur un fichier ''autorized_keys'' a été créé.

L'utilisateur n'a alors plus besoin de taper le mot de passe : son authentification sur le serveur distant est assurée via sa paire de clé.

===== En résumé =====

  * Pour sécuriser un message, il faut le chiffrer ;
  * La cryptographie permet de chiffrer et déchiffrer un message ;
  * SSH repose sur les principes de cryptographie symétrique et asymétrique ;
  * Sous Linux, les briques logicielles OpenSSH permettent de mettre en place un service SSH sécurisé ;
  * Il est nécessaire de sécuriser le service SSH, notamment en passant par une authentification par échange de clés ;

L'accès à distance est maintenant opérationnel sur votre serveur, il peut aller se placer avec les autres dans la salle blanche prévue à cet effet, bien au frais.

Dans le prochain chapitre, je vous propose de nous pencher sur les fonctionnalités permettant de télécharger ou de transférer des données à partir d'un terminal, et vous verrez que la brique logicielle OpenSSH n'a pas fini de nous servir !

[[310_configurer_interfaces_reseaux|◁ Précédent]] | [[000_start|⌂ Retour au sommaire]] | [[330_transfert_fichiers_via_reseau|Suivant ▷]]
wikinotes

Outils pour utilisateurs

Outils du site

Outils de la page
