SSH

Présentation de SSH

SSH est un protocole de conneixon sécurisée entre un client et un serveur. Il permet de chiffrer les communications. Plusieurs outils implémentent ce protocole, parmi lesquels OpenSSH est le plus répandu.

Initialement, avant l'arrivée de SSH on utilisait le protocole telnet qui n'est pas chiffré; cela posait problème. Quelques tentatives de telnet chiffré ont eu lieu mais n'ont pas abouti. SSH arriva en 1995, inventé par un finlandais qui fonda la société SSH Communications Security pour en tirer profit. Initialement libre, cette version devint de plus en plus propriétaire. Elle finit par être forkée par l'équipe d'openBSD, qui créa alors OpenSSH.

Elle a continué d'évoluer; elle est très largement déployée. L'équipe de dev d'OpenBSD conçoit deux versions : une pour OpenBSD et une mutliplateforme "dite portable". Les version portables comportent la lettre "p". En 2006, la version SSH2 fut standardisée par une équipe de l'IETF.

Les outils

Une installation classique comporte plusieurs outils :

• Le client SSH : qui sert à se connecter
• Le serveur SSHd : le daemon SSH n'est que rarement installé par défaut.
• SCP : L'outil de copie de fichiers en ligne de commandes (acronyme de SSH Copy)
• SFTP : Plus pratique à utiliser que SCP, il s'appuie sur FTP (ne pas confondre avec TFTP!).
• ssh-keygen : L'outil de création et de gestion des clefs ssh
• ssh-add : l'agent SSH, qui garde en mémoire les clefs privées chargées.

Les fichiers de configuration

Côté serveur

Sur la plupart des serveurs, le fichier de configuration se trouve dans /etc/ssh/sshd_config

Le D est pour Daemon. Par ailleurs côté serveur, pour chaque compte utilisateur la ou les clefs publiques doivent être stockées dans un fichier authorized_keys situé dans son dossier home. Par exemple, avec mon utilisatrice justine j'ai : /home/justine/.ssh/authorized_keys.

Côte client

Il se trouve dans /etc/ssh.ssh_config (sur une machine client et serveur à la fois, on a deux fichiers à ne pas confondre).

Chaque client peut apporter des ajustements à sa configuration SSH en créant un fichier nommé config et qui est dans son propre dossier .ssh :

/home/justine/.ssh/config

Celui-ci peut contenir les mêmes directives que celles du fichier de configuration client global, par exemple:

• ForwardAgent yes : Ici l'agent SSH accompagnera nos connexions de poste en poste (si je fais du ssh de A vers B, puis de B vers C, etc). Si les directives ForwardAgent des postes A et B sont sur yes alors les clefs SSH seront utilisées avec l'agent pour toutes ces connexions.
• PasswordAuthentication yes : On peut refuser l'authentification par mot de passe, auquel cas il faudra utiliser des clefs.
• CheckHostIP yes : vérifie l'IP du serveur par sécurité.
• StrictHostKeyChecking ask : Vérifie que l'hôte est connu.

Le fichier peut aussi contenir des directives pour chaque hôte auquel le client se connecte : alias, paramètres, etc... Par exemple :

ForwardAgent yes
ForwardX11 no
ForwardX11Trusted yes

host serveur1
   hostname 192.168.0.70
   user toto

host serveur2
   hostname 192.168.0.71
   port 2233
   user root

host serveur3 mon_serveur
   user root

Les logs

Le fichier de log du serveur est dans /var/log/auth.log.

On peut facilement voir les attaques de force brute avec la commande :

grep -i invalid /var/log/auth.log

Le niveau de verbosité du log est reglé dans le fichier de config par la directive LogLevel. Par défaut elle est sur INFO mais on peut la rendre plus verbeuse.

Connexion

La connexion se fait avec ssh user@serveur. On peut faire ssh serveur pour essayer de se connecter avec l'utilisateur actuel.

Knownhosts et identification

Pour éviter le spoofing, il est necéssaire de s'identifier et d'identifier les serveurs auxquels le client se connecte. Pour cela, le client va noter l'empreinte digitale du serveur dans un fichier auquel il accèdera à chaque fois qu'il se connectera sur le serveur. Il la comparera ensuite à chaque connexion. L'idéal est donc, avant la première connexion, de noter l'empreinte digitale du serveur afin de pouvoir l'accepter sans crainte. Par la suite, on sera alerté si elle change.

Pour connaître l'empreinte du serveur SSH il faut s'y rendre une première fois et noter le résultat de la commande:

ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub

Ici on prend l'empreinte de la clef RSA. On peut aussi prendre celle de la clef dsa :

ssh-keygen -lf /etc/ssh/ssh_host_dsa_key.pub

On obtient alors une longue suite de caractères hexadécimaux que l'on comparera avec la valeur donnée à la première tentative de connexion. L'utilisation de ces empreintes est un mécanisme de protection contre les attaques mitm. Cette empreinte est en réalité issue de la clef publique du serveur, obtenue en hachant une clef publique, à laquelle elles se rapportent.

Pour purger une ancienne empreinte digitale :

ssh-keygen -R @ipAncienServeur

En pratique

La première fois que l'on se connecte au serveur, on nous demande d'accepter son empreinte digitale. Il faut alors noter quelle empreinte est utilisé : RSA, DSA, ECDSA...

Ici, je vais partir du principe que l'on utilise une clef ECDSA.

Côté client on lance la commande :

ssh-keyscan -t ecdsa <@IPserveur>

On aura alors la clef publique du serveur.

Sur le serveur lui-même on lance la commande :

ssh-keyscan -t ecdsa localhost

On a alors sa "vraie" clef publique; on peut la comparer avec celle donnée au client.

RÉSUMÉ DES COMMANDES

Pour avoir l'empreinte d'une clef :

ssh-keygen -lf /etc/ssh/<clef> <IP> #Sur soi-même ou une autre machine

Pour voir la clef publique en entier:

ssh-keyscan -t <typedeclef> <IP> #Sur soi-même ou une autre machine

Pour rendre le fichier Knowhosts lisible :

Modifier la directive HashKnowHosts dans le fichier ssh_config