# Sécurisation du service SSH

Dans cette partie, nous allons analyser et implémenter les recommendations de l'ANSSI et du guide Debian concernant le durcissement du protocole SSH. Les différentes règles permettent de sécuriser l'utilisation d'(Open)SSH.

**Bibliographie**:
- [Recommandations pour un usage sécurisé d'(Open)SSH - ANSSI](https://www.ssi.gouv.fr/uploads/2014/01/NT_OpenSSH.pdf)
- [Chapitre 5.1 des recommandations DEBIAN](https://www.debian.org/doc/manuals/securing-debian-manual/sec-services.en.html#id-1.6.6)
- [Guide de sélection d'algorithmes cryptographiques - ANSSI](https://www.ssi.gouv.fr/uploads/2021/03/anssi-guide-selection_crypto-1.0.pdf)

Le document de l'ANSSI: "Recommandations pour un usage sécurisé d'(Open)SSH", liste des recommandations noté Rx allant de R1 à R31. Nous allons implémenter celle nous paraissant les plus importantes.

- [Sécurisation du service SSH](#sécurisation-du-service-ssh)
- [Version du protocole SSH](#version-du-protocole-ssh)
- [Administration à distance](#administration-à-distance)
- [Authentification et contrôle d'accès utilisateur](#authentification-et-contrôle-daccès-utilisateur)
- [Protocole et accès réseaux](#protocole-et-accès-réseaux)
- [Configuration du fichier `/etc/ssh/sshd_config`](#configuration-du-fichier-etcsshsshd_config)

## Version du protocole SSH

Il existe deux versions de SSH:
- SSHv1
- SSHv2

La version 1 du protocole possède des vulnérabilités structurelles qui sont corrigés dans la version 2 du protocole. SSHv1 est maintenant obsolète. Il est possible de forcer l'utilisation de SSHv2 en rajoutant la directive `Protocole 2` au fichier `/etc/ssh/ssh_config`.

## Administration à distance

**Recommendation R2 et R3** - Pour une administration à distance (accès shell), seul le protocole SSH doit être utilisé (R2). SSH apporte des avantages niveau sécurité. Le protocole offre une authentification au niveau du serveur et un canal chiffré et authentifié. Il est nécessaire de désactivé des protocoles d'administration à distance tels que TELNET, RSH et RLOGIN (R3). Les commandes RLOGIN et RSH sont aujourd'hui des liens symboliques vers SSH. On supprime donc le protocole TELNET.

## Authentification et contrôle d'accès utilisateur

**Recommendation R6** - Il est nécessaire de s'assurer de la légitimité du serveur avant de la contacter. Ceci passe par l'authentification de la machine grâce à sa clé publique ou d'un certificat. Pour se faire, on peut ajouter manuellement la clé publique dans notre fichier 'known_hosts'.

**Recommendation R7** - L'usage de clés DSA est fortement déconseillé. On utilisera donc des clés générées via RSA ou ECDSA.

**Recommendation R8 et R9** - Les clés doivent être générées via RSA ou ECDSA avec une taille minimale de 2048 bits pour le RSA et 256 bits pour l'ECDSA. Selon la **recommendation R16** du [guide de sélection cryptographique de l'ANSSI](https://www.ssi.gouv.fr/uploads/2021/03/anssi-guide-selection_crypto-1.0.pdf) la taille de clés recommandé est passé à 3072 bits. On préfera choisir une taille de 4096 bits pour nos clés par mesure de sécurité.

Les commandes suivantes permettent de respecter ces exigences:

ssh-keygen -t rsa -b 4096 -f <file_name>
ssh-keygen -t ecdsa -b 256 -f <file_name>

**Recommandation R12** - La génération des clés doit être effectué à partir d'une machine physique fonctionnant depuis plusieurs minutes, voire heures, afin d'avoir un niveau d'entropie élevé.

**Recommandation R17** - Pour l'authentification, on place la clé publique de la machine dans le fichier `~/.ssh/authorized_keys`. L'authentification se fera par clés, et non pas par mots de passe. Cela permet de rajouter un niveau d'autorisation. Seul l'utilisateur possédant la clé privée associé à la clé publique inscrite dans le serveur peut obtenir l'accès.

**Recommandation R21** - Le compte 'root' en doit pas être accessible à la connexion SSH.

**Recommandation R23** - Restriction de l'utilitisation de variable d'environnement au travers du deamon SSH. Certaines variables peuvent altérer la sécurité du système (LD_PRELOAD,LD_LIBRARY_PATH par exemple).

## Protocole et accès réseaux

**Recommandation R27** - Sauf besoins justifiés, toutes les redirections de flux doivent être désactivées. Au niveau du pare-feu ou dans notre cas directement à partir de notre fichier de configuration `/etc/ssh/sshd_config`. Cette fonctionnalité peut être utilisé dans le cadre d'attaque par rebond (accès à des services normalement inaccessibles).

**Recommandation R28** - De même que pour la recommandation précédente, la redirection X11 doit être désactivé, sauf pour des besoins spécifique. Lorsqu'elle est active, une compromission pourrait conduire à des fuites d'informations telles que les frappes claviers ou une redirection de l'affichage par exemple.

## Configuration du fichier `/etc/ssh/sshd_config`

Afin de mettre en place les recommandations cités, on ajoute au fichier de configuration les paramètres suivants:

PermitRootLogin no          # Désactive l'authentification de l'utilisateur root
PermitEmptyPassword no      # Force l'utilisation d'un mot de passe
AllowUsers enzom            # Autorise une liste d'utilisateur à se connecter
AllowGroups enzom           # Autorise une liste de groupes à se connecter
PasswordAuthentication no   # Autorise seulement les machines possédant les clés présentes dans le fichier `~/.ssh/authorized_keys`
AllowTcpForwarding no       # Désactivation des redirection de flux côté serveur
X11Forwarding no            # Désactivation de la redirection X11 

On ajoutera aussi les entrées ci-dessous, selon les recommandations Lynis:

ClientAliveInterval 60 # Nombre de seconde avant l'envoie d'un paquet null au client (pour garder la connexion active)
ClientAliveCountMax 10 # Nombre de message pouvant être envoyé sans réponse du client
Compression no         # Spécifie si la compression est activé pour l'utilisateur
LogLevel VERBOSE       # Niveau de log du service
MaxSessions 1          # Nombre de session possible simultanément
Port 2222              # Port utilisé par SSH
TCPKeepAlive no        # Spécifie si le serveur envoie de message de keepalive
AllowAgentForwarding no 

Selon la recommandation Debian, la restriction de l'utilisation des services sftp et scp aux utilisateurs peut être intéressant. Il est possible de désactiver le `sftp-server` et commentant la ligne suivante dans le fichier `/etc/ssh/ssh_config`:

# override default of no subsystems
# Subsystem     sftp     /usr/lib/openssh/sftp-server