Configurer les paramètres avancés du client SSH pour des performances et une sécurité optimales

Établir une connexion sécurisée est souvent la première étape de l'administration de systèmes distants, généralement avec une simple commande ssh user@host. Lorsque vous gérez plusieurs serveurs, les paramètres du client SSH dans ~/.ssh/config maintiennent ces connexions stables, reproductibles et moins sujettes aux erreurs.

Vous pouvez utiliser un seul fichier pour définir des alias d'hôtes, des fichiers d'identité, le comportement keepalive, les chiffrements, la compression et le routage bastion sans avoir à retaper de longues lignes de commande.

Comprendre le fichier de configuration SSH

Le centre de contrôle principal du comportement du client SSH est le fichier de configuration situé à ~/.ssh/config. Si ce fichier n'existe pas, vous pouvez le créer en toute sécurité. Ce fichier vous permet de définir des paramètres spécifiques à un Hôte, ce qui signifie que vous pouvez avoir une configuration pour votre serveur de production et une autre pour votre environnement de test.

Structure du fichier de configuration

Les configurations sont structurées à l'aide de directives appliquées globalement (en haut) ou spécifiquement à un bloc Host. Les paramètres d'un bloc Host remplacent les paramètres globaux.

# Paramètres globaux appliqués à toutes les connexions sauf si remplacés
Host *
    ServerAliveInterval 60

# Paramètres spécifiques pour un serveur de développement
Host devserver
    HostName 192.168.1.100
    User developer_user
    Port 2222
    IdentityFile ~/.ssh/id_rsa_dev

Optimiser la persistance des connexions et les délais d'attente

Les déconnexions fréquentes, surtout sur des réseaux instables ou via VPN, peuvent gravement nuire à la productivité. Les clients SSH utilisent des mécanismes pour maintenir la connexion active.

Mécanismes KeepAlive

Pour éviter que les connexions inactives n'expirent en raison des paramètres d'inactivité du pare-feu ou du routeur, vous pouvez configurer le client pour envoyer périodiquement des "paquets nuls".

ServerAliveInterval : Spécifie un délai d'attente en secondes après lequel le client envoie un message au serveur pour maintenir la connexion active si aucune donnée n'a été reçue. Une valeur de 60 est courante.
ServerAliveCountMax : Spécifie le nombre de tentatives du client sans réponse du serveur avant d'abandonner et de se déconnecter.

Exemple de configuration pour la stabilité :

Host stable-server
    HostName production.example.com
    User sysadmin
    ServerAliveInterval 30
    ServerAliveCountMax 3

Cette configuration enverra un paquet nul toutes les 30 secondes. Si elle envoie ce paquet 3 fois sans réponse, le client se déconnectera.

Délai d'attente de connexion

Si une tentative de connexion reste bloquée indéfiniment lorsqu'un serveur est en panne ou inaccessible, vous pouvez définir un délai d'attente pour la phase initiale de connexion :

ConnectTimeout : Définit le temps maximum (en secondes) que le client SSH attendra pour qu'une connexion soit établie avant d'abandonner la tentative.

Renforcer la sécurité grâce au durcissement du client

Bien que la configuration du serveur dicte une grande partie de la posture de sécurité, le client peut imposer des préférences de sécurité et simplifier l'authentification complexe.

Imposer l'authentification par clé

Pour les serveurs critiques, vous devez toujours imposer l'authentification par clé et désactiver les invites de mot de passe. La directive PreferredAuthentications contrôle l'ordre et le type de méthodes d'authentification que le client tente.

Pour prioriser l'authentification par clé publique :

Host critical-db
    HostName db.internal.net
    PreferredAuthentications publickey
    PubkeyAuthentication yes
    PasswordAuthentication no

Spécifier les fichiers d'identité

Si vous utilisez plusieurs paires de clés (une pour le travail, une pour les projets personnels, etc.), vous pouvez mapper des clés spécifiques à des hôtes spécifiques en utilisant IdentityFile.

Host gitlab.work.com
    IdentityFile ~/.ssh/id_rsa_gitlab_work

Host github.com
    IdentityFile ~/.ssh/id_rsa_personal

Meilleure pratique de sécurité : Assurez-vous que vos clés privées ont des permissions restrictives (par exemple, chmod 600 ~/.ssh/id_rsa).

Optimiser les performances : chiffrements et compression

Les performances SSH peuvent être affectées par les algorithmes cryptographiques utilisés pour le chiffrement et la surcharge de la compression des données.

Sélection des chiffrements

Les clients SSH modernes prennent en charge une large gamme de chiffrements. Vous pouvez spécifier une liste préférée en utilisant Ciphers pour vous assurer d'utiliser des algorithmes forts et rapides pris en charge à la fois par le client et le serveur, ou pour imposer des normes plus anciennes si du matériel hérité l'exige.

Les chiffrements modernes préférés incluent souvent les implémentations AES-GCM.

Host fast-connection
    HostName remote.fastlane.io
    Ciphers [email protected],[email protected],[email protected]

Compression

La compression des données (Compression) peut accélérer les sessions sur des liaisons très lentes, mais elle ajoute une charge CPU aux deux extrémités. Elle est généralement désactivée sur les réseaux rapides.

Compression no : (Par défaut) Pas de compression.
Compression yes : Active la compression en utilisant l'algorithme ZLIB.

Host slow-wan-link
    Compression yes

Simplifier les connexions avec les alias et les ProxyJumps

L'une des fonctionnalités les plus puissantes de ~/.ssh/config est la simplification des chemins de connexion complexes, comme le saut via un hôte bastion (un "jumpbox").

Alias d'hôtes

Au lieu de taper le nom complet du serveur et l'utilisateur à chaque fois, vous pouvez créer un alias simple :

Host web
    HostName 172.16.0.50
    User alice

Vous pouvez maintenant vous connecter simplement en utilisant : ssh web.

ProxyJump pour les hôtes bastion

La directive ProxyJump (ou son équivalent plus ancien, ProxyCommand) permet au client de tunnelliser automatiquement via un serveur intermédiaire avant d'atteindre la destination finale. Cela évite d'avoir besoin d'appels ssh séparés ou de configurations nc (netcat).

Pour se connecter à database via jumpbox :

Host jumpbox
    HostName 203.0.113.5
    User bastion_user

Host database
    HostName 10.0.0.5
    User db_user
    ProxyJump jumpbox

Maintenant, la commande ssh database se connecte automatiquement d'abord à jumpbox, puis transmet la session au serveur database.

À retenir

Le fichier ~/.ssh/config est l'endroit où vous transformez des commandes SSH répétitives en profils nommés clairs. Commencez par les alias, User, HostName, IdentityFile et ServerAliveInterval ; puis ajoutez ProxyJump, les préférences de chiffrement ou la compression uniquement là où votre environnement en a besoin. Avant d'imposer une option stricte globalement, testez-la sur vos hôtes plus anciens pour ne pas vous verrouiller hors d'un serveur qui prend en charge un ensemble de fonctionnalités SSH plus restreint.