Configuration des 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 à distance des systèmes, généralement accomplie avec une simple commande ssh utilisateur@hôte. Cependant, pour les professionnels travaillant sur plusieurs serveurs, la gestion de la stabilité, de la vitesse et de la sécurité des sessions nécessite d'aller au-delà de ces paramètres par défaut. Ce guide explore en profondeur le fichier de configuration côté client—~/.ssh/config—pour vous aider à affiner votre expérience SSH afin d'obtenir des performances optimales, une fiabilité accrue et un renforcement robuste de la sécurité.

En maîtrisant ces paramètres côté client, vous obtenez un contrôle granulaire sur la manière dont votre machine locale interagit avec les serveurs distants, réduisant ainsi la saisie manuelle, prévenant les chutes de connexion frustrantes et appliquant les normes de sécurité nécessaires à toutes vos sessions.

Comprendre le fichier de configuration SSH

Le principal centre de contrôle du comportement SSH côté client 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 configuration différente 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 à l'intérieur d'un bloc Host remplacent les paramètres globaux.

# Paramètres globaux appliqués à TOUTES les connexions sauf si remplacés
Host *
    ForwardAgent yes

# 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

Optimisation de la persistance des connexions et des délais d'expiration

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

Mécanismes KeepAlive

Pour empêcher les connexions inactives d'expirer en raison des paramètres d'inactivité du pare-feu ou du routeur, vous pouvez configurer le client pour qu'il envoie des « paquets nuls » périodiques.

ServerAliveInterval : Spécifie un délai en secondes après lequel le client envoie un message au serveur pour maintenir la connexion active s'il n'a reçu aucune donnée. Une valeur de 60 est courante.
ServerAliveCountMax : Spécifie le nombre de tentatives du client sans recevoir de 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'expiration de la connexion

Si une tentative de connexion reste indéfiniment en suspens lorsqu'un serveur est arrêté ou inaccessible, vous pouvez définir un délai d'expiration 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'annuler la tentative.

Amélioration de la sécurité par le renforcement du client

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

Imposition de l'authentification par clé

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

Pour privilégier l'authentification par clé publique :

Host critical-db
    HostName db.internal.net
    PreferredAuthentications publickey,keyboard-interactive
    PubkeyAuthentication yes

Spécification des 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).

Optimisation des 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 un large éventail de chiffrements. Vous pouvez spécifier une liste préférée à l'aide de Ciphers pour vous assurer d'utiliser des algorithmes forts et rapides pris en charge par le client et le serveur, ou pour imposer d'anciennes normes si le matériel hérité l'exige.

Les chiffrements modernes préférés incluent souvent des 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 liens très lents, mais elle ajoute une surcharge CPU aux deux extrémités. Elle est généralement désactivée sur les réseaux rapides.

Compression no : (Par défaut) Aucune compression.
Compression yes : Active la compression à l'aide de l'algorithme ZLIB.

Host slow-wan-link
    Compression yes

Simplification des connexions avec des alias et ProxyJumps

L'une des fonctionnalités les plus puissantes de ~/.ssh/config est la simplification des chemins de connexion complexes, tels que le passage par un serveur bastion (un "jumpbox").

Alias d'hôtes

Au lieu de taper à chaque fois le nom complet du serveur et l'utilisateur, 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 serveurs bastion

La directive ProxyJump (ou son équivalent plus ancien, ProxyCommand) permet au client de passer automatiquement par 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 le 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 transfère la session vers le serveur database.

Résumé et prochaines étapes

Le fichier ~/.ssh/config est un outil essentiel pour tout utilisateur avancé de SSH. En définissant des paramètres explicites pour la stabilité de la connexion (ServerAliveInterval), les méthodes d'authentification (PreferredAuthentications) et les chemins réseau (ProxyJump), vous allez au-delà des connexions génériques pour un flux de travail hautement optimisé, répétable et sécurisé. Revoyez votre configuration actuelle, identifiez vos connexions les plus fréquemment utilisées ou les plus instables, et appliquez ces directives pour améliorer immédiatement l'efficacité de votre travail à distance quotidien.