Foxency
Administration Système et Infrastructure

SSH : configuration et sécurisation

SSH est l'outil quotidien de l'administrateur. Clés Ed25519, fichier de configuration client, rebonds, tunnels et réglages serveur essentiels : un guide pratique pour l'utiliser efficacement et proprement.

Par Rédaction Foxency Publié le 5 min de lecture

Connexion SSH chiffrée entre un poste d'administration et un serveur à l'aide d'une paire de clés

SSH (Secure Shell) permet d'administrer des systèmes à distance au travers d'un canal chiffré et authentifié. Défini par les RFC 4251 à 4254, il remplace Telnet, rlogin et FTP pour l'administration. L'implémentation la plus répandue est OpenSSH, présente sur les distributions Linux, macOS et intégrée à Windows 10, Windows 11 et Windows Server depuis 2019.

Objectif : configurer un serveur et un client SSH, utiliser l'authentification par clé, les rebonds et les tunnels. Les aspects de gouvernance (bastion, MFA, certificats SSH, audit) sont traités dans Durcissement SSH et gestion des accès administratifs.

Comment SSH protège la connexion

Une session SSH se déroule en trois phases :

  1. Établissement du transport : négociation des algorithmes, échange de clés (par exemple curve25519 ou, sur les versions récentes d'OpenSSH, un échange hybride résistant aux ordinateurs quantiques), puis chiffrement de la suite des échanges.
  2. Authentification du serveur : le serveur présente sa clé d'hôte. Le client la compare à son fichier ~/.ssh/known_hosts. Lors de la première connexion, il demande de confirmer l'empreinte.
  3. Authentification de l'utilisateur : par clé publique, mot de passe, ou méthodes complémentaires.

Ne validez jamais une empreinte sans la vérifier. Un avertissement « REMOTE HOST IDENTIFICATION HAS CHANGED » peut signaler une réinstallation du serveur… ou une interception. Obtenez l'empreinte par un canal fiable :

# Sur le serveur, depuis la console
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Installer le serveur

sudo apt install openssh-server          # Debian / Ubuntu
sudo dnf install openssh-server          # RHEL et dérivés
sudo systemctl enable --now ssh          # le service s'appelle "sshd" sur RHEL

# Windows Server 2019 et versions ultérieures
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Start-Service sshd
Set-Service -Name sshd -StartupType Automatic

Authentification par clé

Générer une paire de clés

ssh-keygen -t ed25519 -C "admin@poste-admin01"
  • La clé Ed25519 est recommandée : courte, rapide et robuste. Si un équipement ancien ne la prend pas en charge, utilisez RSA avec au moins 3 072 bits (-t rsa -b 4096).
  • Protégez la clé privée par une phrase de passe et utilisez un agent (ssh-agent) pour ne la saisir qu'une fois par session.
  • La clé privée (~/.ssh/id_ed25519) ne quitte jamais votre poste ; seule la clé publique (.pub) est copiée sur les serveurs.

Déployer la clé publique

ssh-copy-id -i ~/.ssh/id_ed25519.pub admin@srv-web01

À défaut, ajoutez le contenu du fichier .pub dans ~/.ssh/authorized_keys sur le serveur, avec des permissions strictes :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

OpenSSH refuse d'utiliser un fichier authorized_keys aux permissions trop ouvertes : c'est une cause fréquente d'échec.

Sur Windows, les clés des comptes membres du groupe Administrateurs se placent dans C:\ProgramData\ssh\administrators_authorized_keys, avec des ACL restreintes.

Configuration du serveur : les réglages essentiels

Le fichier principal est /etc/ssh/sshd_config. Les distributions récentes chargent aussi les fichiers de /etc/ssh/sshd_config.d/, ce qui permet d'isoler vos réglages :

# /etc/ssh/sshd_config.d/50-foxency.conf — exemple
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AllowGroups ssh-admins
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

Procédure sûre pour appliquer une modification :

sudo sshd -t                 # vérifier la syntaxe (aucune sortie = OK)
sudo systemctl reload ssh    # ou sshd selon la distribution

Gardez votre session actuelle ouverte et testez une nouvelle connexion depuis un autre terminal avant de vous déconnecter. Si la configuration est incorrecte, la session existante vous permet de corriger.

Avant de désactiver l'authentification par mot de passe, vérifiez que la connexion par clé fonctionne pour tous les comptes d'administration.

Le fichier de configuration client

Le fichier ~/.ssh/config évite de retaper options et noms :

Host bastion
    HostName bastion.exemple.fr
    User admin
    IdentityFile ~/.ssh/id_ed25519

Host srv-*
    User admin
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519

Host srv-web01
    HostName 10.10.20.80

Host *
    ServerAliveInterval 60
    HashKnownHosts yes

Il suffit ensuite de taper ssh srv-web01 : la connexion passe automatiquement par le bastion.

ProxyJump : rebondir proprement

ssh -J admin@bastion.exemple.fr admin@10.10.20.80

Avec ProxyJump, la clé privée reste sur votre poste : le bastion ne fait que relayer le flux chiffré. C'est préférable à l'agent forwarding (ssh -A), qui expose votre agent à tout administrateur du serveur intermédiaire.

Tunnels SSH

SSH peut transporter d'autres flux TCP de manière chiffrée.

# Redirection locale : accéder à une interface web interne via le bastion
ssh -L 8443:10.10.99.5:443 bastion
# puis ouvrir https://localhost:8443

# Redirection distante : exposer un port local sur le serveur distant
ssh -R 9000:localhost:3000 srv-dev01

# Proxy SOCKS dynamique
ssh -D 1080 bastion

Les tunnels sont pratiques mais peuvent contourner la politique de filtrage : sur les serveurs, limitez-les avec AllowTcpForwarding et PermitOpen, et documentez leur usage.

Transférer des fichiers

scp rapport.pdf srv-web01:/tmp/
sftp srv-web01
rsync -avz --progress ./site/ srv-web01:/var/www/site/

Depuis OpenSSH 9.0, scp utilise par défaut le protocole SFTP plutôt que l'ancien protocole SCP.

SSH sur les équipements réseau

Les routeurs et commutateurs gérés prennent en charge SSH, à activer à la place de Telnet. Sur Cisco IOS, il faut un nom d'hôte, un nom de domaine, une paire de clés RSA et des lignes VTY restreintes à SSH. Voir Configuration initiale d'un routeur Cisco.

Diagnostiquer une connexion SSH

ssh -v admin@srv-web01        # -vv ou -vvv pour plus de détails
sudo journalctl -u ssh -f     # journaux côté serveur ("sshd" sur RHEL)
Message Cause probable
Connection refused Service arrêté ou mauvais port
Connection timed out Filtrage réseau ou hôte injoignable
Permission denied (publickey) Clé non déployée, mauvais utilisateur, permissions de authorized_keys
Host key verification failed Clé d'hôte modifiée : vérifier avant de supprimer l'ancienne entrée
no matching key exchange method Équipement ancien aux algorithmes obsolètes

Erreurs courantes

  • Accepter une empreinte sans vérification.
  • Clé privée sans phrase de passe copiée sur plusieurs machines.
  • Recharger sshd sans tester la syntaxe ni garder une session de secours.
  • Utiliser l'agent forwarding vers des serveurs partagés.
  • Réactiver des algorithmes obsolètes globalement au lieu de limiter l'exception à l'hôte concerné dans ~/.ssh/config.

Conclusion

Des clés Ed25519 protégées par phrase de passe, un sshd_config minimal et vérifié, un ~/.ssh/config avec ProxyJump : ces trois éléments rendent SSH à la fois plus sûr et plus confortable. Pour aller plus loin dans la maîtrise des accès privilégiés, poursuivez avec Durcissement SSH et gestion des accès administratifs.

Références