SSH

Par ce salop de FanfanlaTulipe et corrigé par ce salop de fl0w5

Secure SHell est un protocole de communication sécurisé (couche 7) destiné à remplacer rlogin, telnet et rsh (des protocoles non sécurisés) fonctionnant sur le port 22 par défaut.

Le Secure SHell Daemon représente le serveur SSH sur lequel les clients se connectent.

Vu la simplicité du système, nous n'expliquerons pas ici le fonctionnement du démon, nous n'aborderons que son installation et sa configuration. Nous utiliserons également l'implémentation OpenSSH (maintenu par OpenBSD).

Installation

Notre exemple d'installation sera fait sur une machine Debian.

apt install openssh-server -y
systemctl enable ssh
systemctl start ssh

systemctl status ssh    # On vérifie que le démon tourne

Génération des clés

Basé sur les recommandations de l'ANSSI

SSH utilise un système de clé asymétrique pour l'authentification. Il faut noter que dans la pratique, on renouvelle assez peu les clés, il faut donc les faire robustes.

  • La taille minimale d'une clé RSA est 2048 bits.
  • La taille minimale d'une clé ECDSA est de 256 bits.
  • DSA ne doit pas être utilisé.

Pour générer un biclé, entrez une des deux commandes suivantes, en fonction de votre implémentation favorite :

ssh-keygen -t rsa -b 2048 <fichier de clé RSA>      # RSA
ssh-keygen -t ecdsa -b 256 <fichier de clé ECDSA>   # ESDSA

Ces fichiers sont à utiliser comme clé d'identification hôte (attribut HostKey dans sshd) ou utilisateur (IdentifyFile dans ssh).

ECDSA doit être préféré à RSA si les clients et les serveurs le supportent.

Gestion des clés

Une clé privée d'authentification utilisateur ne doit être lisible que de ce dernier et protégée par un mot de passe. Ce chiffrement permet de laisser suffisamment de temps aux équipes d'administration pour révoquer le biclé.

Une clé privée d'authentification hôte ne doit être lisible que par le service sshd, soit l'utilisateur root :

-rw------- root:root /etc/ssh/ssh_host_rsa_key
-rw------- root:root /etc/ssh/ssh_host_ecdsa_key

Le répertoire ~/.ssh/ et son contenu doivent être protégés.

Afin de vérifier les modes et le propriétaire des fichiers de l'utilisateur avant la connextion :

StrictModes yes     # Normalement activé de base

Choix des algorithmes symétriques

Le canal de comminication entre le client et le serveur est chiffré avec un algorithme symétrique. Dans /etc/ssh/sshd_config :

Ciphers aes256-ctr,aes192-ctr,aes128-ctr

# OpenSSH > 6.3
MACs    hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Anciennes versions
MACs    hmac-sha2-512,hmac-sha2-265,hmac-sha1

Authentification

L'authentification d'un utilisateur doit se faire avec l'une des implémentations suivantes, dans l'ordre de préférence :

  • ECDSA
  • RSA
  • tickets Kerberos
  • PAM
  • mot de passe vis-à-vis d'une base de données

Il faut savoir que le fichier authorized_keys, qui stocke normalement les clés publiques des utilisateurs déjà authentifiés, permet de configurer les accès d'un serveur.

# La clé n'autorise l'accès que si le client provient du réseau 192.168.1.0/24.
from="192.168.1.*" ssh-ecdsa AAAA...

# La clé autorise l'accès pour un client venant du domaine *.salo.pe sauf pour *.belle.salo.pe
from="!*.belle.salo.pe, *.salo.pe" ssh-rsa AAAA...

# Bloque l'usage de l'agent forwarding pour cette clé
no-agent-forwarding ssh-ecdsa AAAA...

Imputabilité

L'imputabilité des accès est nécessaire pour la traçabilité. Autrement dit, chaque utilisateur doit avoir son propre compte. De plus, le compte root ne doit pas être accessible :

PermitRootLogin no

Configuration sécurisée

/etc/ssh/ssh_config est le fichier de configuration du client.

# Il faut s'assurer de l'authenticité du serveur.
StrictHostKeyChecking ask

/etc/ssh/sshd_config est le fichier de configuration du serveur OpenSSH.

# SSH existe en 2 versions, SSHv1 et SSHv2. SSHv1 présentant des problèmes de sécurité,
# nous forcerons l'utilisation du protocol v2.
Protocol 2

# Si le serveur SSH est exposé à un réseau non maitrisé, il est recommandé de lui
# mettre un port d'écoute différent de celui par défaut (22). Il est conseillé
# d'utiliser un port inférieur à 1024 afin d'empêcher les tentatives d'usurpation
# par des services non administrateurs.
# Ici, le port 969 par exemple :
Port 2222

# Sur un réseau maitrisé, sshd doit écouter uniquement sur une interface
# du réseau d'administration, distincte de l'opérationnelle
# Ici, le serveur écoute sur l'adresse 192.168.254.3 sur le port 22.
ListenAddress 192.168.254.3:22

# Active la séparation des privilèges en créant un fils non privilégié
# pour prendre en charge le trafic réseau entrant pour éviter une escalade de privilège.
# Par défaut à yes
UsePrivilegeSeparation sandbox

# On proscrit l'accès sans mot de passe
PermitEmptyPasswords no

MaxAuthTries 3 # doit être strictement supérieur à 1

# Interdire la connexion en temps que root
PermitRootLogin no

# Affiche les informations de la dernière connexion
PrintLastLog yes

# AllowUsers permet de spécifier la liste des utilisateurs autorisés
# Ici, l'acces à fanfanlatulipe est restreint aux adresses IPs du réseau 192.168.254.0/24
# et bobotlebrocolis à 192.168.1.0/24
AllowUsers fanfanlatulipe@192.168.254/24 bobotlebrocolis@192.168.1/24

# AllowGroups permet de spécifier la liste des groupes autorisés
AllowGroups wheel@192.168.254/24 flore

# Bloquer la modification des variables d'environnement;
# Les variables d'environnement peuvent modifier le fonctionnement attendu de programme.
# La directive AcceptEnv permet d'autoriser la modification d'une variable.
# !!! Je n'ai pas trouvé de documentation sur cette directive !!!
PermitUserEnvironment no

# Permet d'éxecuter une commande à la connexion.
# Cela remplace la connexion.
# ForceCommand <command>
# Par exemple, une connexion à l'utilisateur reboot relancera la machine :
Match User reboot
    ForceCommand reboot

# Désactivation de la redirection de flux
AllowTcpForwarding no
X11Forwarding no
ForwardX11Trusted no

##### Commandes expliqués plus haut #####

StrictModes yes

Ciphers aes256-ctr,aes192-ctr,aes128-ctr
# OpenSSH > 6.3
MACs    hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
# Anciennes versions
MACs    hmac-sha2-512,hmac-sha2-265,hmac-sha1

Utilisation des clés pour un host

Il est possible d'automatiser l'utilisation d'une clé ssh grâce à une fichier config situé dans "~/.ssh".

Pour faire cela utilisez les lignes de config suivantes:

Host [DOMAIN]
 HostName [DOMAIN]
 IdentityFile [PATH_TO_SSH_KEY]

L'exemple d'utilisation le plus fréquent est un serveur distant dont l'adresse ne change pas comme par exemple un répo Git.

P.S. : Afin d'utiliser une clé SSH à la place de la paire username/password pour les répo git un changement dans l'adresse de remote est nécessaire ("https://github.com/[repo]" à "git@github.com:[repo]")

Références

ANSSI :

IETF :

Divers :