Sécuriser SSH : vérifier l’empreinte du serveur à la première connexion

Ce que vous saurez faire

Ce tutoriel vous apprend a utiliser SSH (Secure Shell) pour administrer vos serveurs Linux a distance en toute sécurité. Pour une PME sénégalaise qui heberge son site, ses emails, ou son ERP sur un serveur distant, SSH est l’outil quotidien incontournable. Vous apprendrez a vous connecter avec mot de passe puis en cle publique (bien plus sécurisée), a configurer un fichier ~/.ssh/config pour multiplier les raccourcis, a transférer des fichiers avec scp et rsync, a tunneliser des ports pour acceder a des services internes, et a durcir votre serveur SSH contre les attaques automatisées. A la fin de ce guide, vous administrerez vos 3, 5, ou 20 serveurs avec des commandes de deux caractères, sans jamais taper de mot de passe, tout en ayant renforce la sécurité globale de votre infrastructure contre 99% des tentatives d’intrusion automatisées.

Étape 1 : Première connexion SSH

SSH fonctionne en mode client-serveur. Votre ordinateur est le client, le serveur distant execute sshd. La syntaxe de base est ssh utilisateur@serveur. Le port par défaut est 22.

# Connexion simple
ssh admin@srv.monentreprise.sn

# Specifier un port
ssh -p 2222 admin@srv.monentreprise.sn

# Premiere connexion : verifier l'empreinte
# The authenticity of host 'srv.monentreprise.sn (41.82.x.x)' can't be established.
# ECDSA key fingerprint is SHA256:abc123...
# Are you sure you want to continue connecting (yes/no)?

# Taper yes, le serveur est ajoute a ~/.ssh/known_hosts

# Sortir de la session
exit
# ou Ctrl+D

Vérifiez toujours l’empreinte lors de la première connexion. Demandez-la au fournisseur du serveur ou consultez-la via la console du VPS.

Étape 2 : Générer une paire de cles SSH

L’authentification par cle est plus sure que par mot de passe. Generez une paire sur votre poste client. La cle publique sera déposée sur les serveurs, la privée reste chez vous.

# Generer une cle ED25519 (moderne, rapide, sure)
ssh-keygen -t ed25519 -C "admin@pme-dakar.sn"

# Generating public/private ed25519 key pair.
# Enter file in which to save the key (/home/admin/.ssh/id_ed25519): [Entree]
# Enter passphrase (empty for no passphrase): [passphrase forte]
# Enter same passphrase again: [passphrase]

# Les fichiers generes
ls -la ~/.ssh/
# -rw------- 1 admin admin 411 Apr 23 id_ed25519       (privee, ne pas partager)
# -rw-r--r-- 1 admin admin 101 Apr 23 id_ed25519.pub   (publique, a deposer)

La passphrase protege votre cle privée en cas de vol de votre ordinateur portable. Utilisez ssh-agent pour ne la taper qu’une fois par session.

Étape 3 : Déployer la cle publique sur le serveur

La méthode simple utilise ssh-copy-id. Sinon, copiez manuellement le contenu de votre cle publique dans ~/.ssh/authorized_keys sur le serveur.

# Methode 1 : ssh-copy-id (recommandee)
ssh-copy-id admin@srv.monentreprise.sn

# /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s)
# admin@srv.monentreprise.sn's password: [mot de passe serveur]
# Number of key(s) added: 1

# Methode 2 : manuelle
cat ~/.ssh/id_ed25519.pub | ssh admin@srv "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

# Verifier
ssh admin@srv.monentreprise.sn "cat ~/.ssh/authorized_keys"

# Permissions correctes (obligatoire)
ssh admin@srv "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

Étape 4 : Se connecter sans mot de passe

Une fois la cle déployée, la connexion ne demande plus le mot de passe du serveur, seulement la passphrase locale (si définie).

# Connexion par cle
ssh admin@srv.monentreprise.sn

# Avec ssh-agent pour ne saisir la passphrase qu'une fois
eval "$(ssh-agent)"
ssh-add ~/.ssh/id_ed25519

# Verifier les cles chargees
ssh-add -l

# Desormais, plus de prompt de passphrase jusqu'a fermeture de session

Étape 5 : Configurer ~/.ssh/config

Le fichier ~/.ssh/config permet de créer des alias et de mémoriser les options. Au lieu de ssh -p 2222 -i ~/.ssh/cle_prod admin@srv.monentreprise.sn, tapez simplement ssh prod.

nano ~/.ssh/config

Host prod
    HostName srv.monentreprise.sn
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod

Host staging
    HostName 41.82.10.50
    User deploy
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Host *.monentreprise.sn
    User admin
    ForwardAgent yes
    ServerAliveInterval 60
    ServerAliveCountMax 3

chmod 600 ~/.ssh/config

# Usage simplifie
ssh prod
ssh staging

Étape 6 : Transférer des fichiers avec scp

scp (secure copy) copie des fichiers entre machines via SSH. Syntaxe proche de cp avec la notation user@host:path.

# Du local vers le serveur
scp rapport.pdf admin@srv:/home/admin/

# Du serveur vers le local
scp admin@srv:/var/log/nginx/access.log ./

# Dossier recursif
scp -r ./site_web/ admin@srv:/var/www/html/

# Via l'alias config
scp backup.tar.gz prod:/backups/

# Port specifique
scp -P 2222 fichier.txt admin@srv:/tmp/

# Preserver les permissions et dates
scp -p fichier.txt admin@srv:/tmp/

# Afficher la progression
scp -v gros_fichier.zip admin@srv:/tmp/

Étape 7 : Synchroniser avec rsync

rsync est plus puissant que scp : il ne transfere que les différences, gere les gros volumes, et peut reprendre une synchronisation interrompue. Idéal pour les sauvegardes.

# Syntaxe : rsync [options] source destination

# Synchro locale vers serveur
rsync -avz ./site_web/ admin@srv:/var/www/html/

# Options courantes
# -a : mode archive (preserve tout)
# -v : verbeux
# -z : compression
# -h : tailles lisibles
# --progress : barre de progression
# --delete : supprime a destination ce qui n'existe plus a la source

# Sauvegarde incrementale
rsync -avzh --delete --progress \
    admin@srv:/var/www/html/ \
    /backups/www/

# Exclure certains fichiers
rsync -avz --exclude 'node_modules' --exclude '.git' \
    ./projet/ admin@srv:/var/www/projet/

# Dry-run (simulation sans action)
rsync -avz --dry-run ./src/ admin@srv:/app/

Étape 8 : Exécuter des commandes a distance

SSH permet d’exécuter une commande sans session interactive. Idéal pour scripter des opérations sur plusieurs serveurs.

# Commande unique
ssh admin@srv "df -h"

# Plusieurs commandes
ssh admin@srv "sudo systemctl restart nginx && sudo systemctl status nginx"

# Script local execute a distance
ssh admin@srv "bash -s" < ./script_local.sh

# Boucle sur plusieurs serveurs
for srv in srv-web-01 srv-web-02 srv-web-03; do
    echo "=== $srv ==="
    ssh admin@$srv "uptime"
done

# Avec sudo (necessite tty)
ssh -t admin@srv "sudo apt update"

Étape 9 : Tunnels SSH (port forwarding)

Les tunnels SSH permettent d’acceder a des services qui ne sont pas exposes publiquement. Exemple : administrer une base MySQL qui ecoute seulement sur localhost du serveur.

# Tunnel local : mon port 3307 -> MySQL du serveur (port 3306)
ssh -L 3307:localhost:3306 admin@srv

# Dans un autre terminal, se connecter a MySQL comme si local
mysql -h 127.0.0.1 -P 3307 -u root -p

# Tunnel en arriere-plan
ssh -f -N -L 3307:localhost:3306 admin@srv

# Acceder a l'interface web d'un outil interne
ssh -L 8080:localhost:8080 admin@srv
# Puis ouvrir http://localhost:8080 dans le navigateur

# Tunnel remote (exposer un service local au serveur)
ssh -R 9000:localhost:3000 admin@srv

# SOCKS proxy dynamique
ssh -D 1080 admin@srv
# Configurer le navigateur : SOCKS5 127.0.0.1:1080

Étape 10 : Utiliser un jump host (bastion)

Dans une infrastructure professionnelle, les serveurs internes ne sont pas exposes sur internet. On passe par un serveur bastion. SSH gere cela nativement avec ProxyJump.

# En ligne de commande
ssh -J bastion.entreprise.sn admin@srv-interne

# Dans ~/.ssh/config
Host bastion
    HostName bastion.entreprise.sn
    User adminbastion
    Port 22

Host srv-interne
    HostName 10.0.1.50
    User admin
    ProxyJump bastion

# Puis simplement
ssh srv-interne
# La connexion passe transparent par le bastion

# Copie de fichier via bastion
scp -J bastion fichier.txt admin@srv-interne:/tmp/

Étape 11 : Durcir la configuration SSH du serveur

Par défaut, SSH est trop permissif. Durcissez /etc/ssh/sshd_config pour bloquer les attaques automatisées.

sudo nano /etc/ssh/sshd_config

# Changer le port (reduit 90% des tentatives automatiques)
Port 2222

# Desactiver login root
PermitRootLogin no

# Desactiver mot de passe (uniquement cles)
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

# Limiter les utilisateurs autorises
AllowUsers admin deploy

# Timeout et tentatives
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

# Desactiver X11 si inutile
X11Forwarding no

# Tester la config AVANT de redemarrer
sudo sshd -t

# Redemarrer SSH
sudo systemctl restart sshd

# ATTENTION : gardez une session ouverte pour tester !
# Ouvrir un NOUVEAU terminal et tester la connexion
# Si echec, corriger via la session restee ouverte

Étape 12 : Protéger avec fail2ban

fail2ban bannit automatiquement les IPs qui echouent trop souvent a se connecter. Indispensable sur un serveur expose.

# Installation
sudo apt install fail2ban -y

# Configuration
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 3
ignoreip = 127.0.0.1/8 196.1.95.0/24

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

sudo systemctl restart fail2ban

# Verifier le statut
sudo fail2ban-client status sshd

# Status for the jail: sshd
# |- Filter
# |  |- Currently failed: 2
# |  |- Total failed:     47
# |  `- File list:        /var/log/auth.log
# `- Actions
#    |- Currently banned: 5
#    |- Total banned:     89
#    `- Banned IP list:   103.x.x.x 185.x.x.x

# Debannir une IP
sudo fail2ban-client set sshd unbanip 192.168.1.100

Étape 13 : Authentification a deux facteurs

Ajoutez un code Google Authenticator pour une sécurité maximale. Même avec la cle privée volee, l’attaquant aura besoin du code TOTP.

# Installer
sudo apt install libpam-google-authenticator -y

# Configurer pour l'utilisateur
google-authenticator

# Repondre yes aux questions, scanner le QR code avec l'app Google Authenticator
# Sauvegarder les codes de secours

# Activer dans PAM
sudo nano /etc/pam.d/sshd
# Ajouter en haut : auth required pam_google_authenticator.so

# Activer dans SSH
sudo nano /etc/ssh/sshd_config
# ChallengeResponseAuthentication yes
# AuthenticationMethods publickey,keyboard-interactive

sudo systemctl restart sshd

Étape 14 : Sessions persistantes avec tmux

Si votre connexion SSH tombe, votre session est perdue. tmux permet de detacher et reattacher une session. Indispensable pour les opérations longues.

# Installer tmux sur le serveur
sudo apt install tmux -y

# Se connecter
ssh admin@srv

# Demarrer une session nommee
tmux new -s deploiement

# Faire un travail long (upgrade, compilation, etc.)
sudo apt upgrade -y

# Detacher avec Ctrl+B puis D
# La session continue meme apres deconnexion SSH

# Se reconnecter plus tard
ssh admin@srv
tmux attach -t deploiement

# Lister les sessions
tmux ls

# Tuer une session
tmux kill-session -t deploiement

# Splitter la fenetre (panneaux)
# Ctrl+B %    : split vertical
# Ctrl+B "    : split horizontal
# Ctrl+B fleche : naviguer entre panneaux

Erreurs

Permission denied (publickey) : presque toujours un probleme de permissions sur ~/.ssh. Le dossier doit être 700, authorized_keys doit être 600. Aussi vérifier que PubkeyAuthentication yes est actif dans sshd_config.

Perdre l’acces après durcissement : erreur classique, changer le port ou désactiver les mots de passe sans tester avec une session de secours. Gardez toujours une session SSH ouverte en parallele lors de changements critiques, et testez depuis un nouveau terminal avant de fermer l’ancienne.

Partager sa cle privée : la cle privée (id_ed25519 sans .pub) ne doit JAMAIS sortir de votre machine. Si vous la perdez ou qu’elle fuite, supprimez la cle publique correspondante sur tous les serveurs et régénérez une paire.

Utiliser le port 22 sur internet : les bots scannent massivement le port 22. Changer pour un port eleve (entre 10000 et 65535) réduit drastiquement les tentatives automatiques sans coûter en sécurité réelle.

Ne pas utiliser de passphrase : une cle sans passphrase est comme une cle de maison laissée sur la porte. Si votre laptop est vole, l’attaquant a acces a tous vos serveurs. Utilisez toujours une passphrase et ssh-agent pour le confort.

Oublier ServerAliveInterval : sur un réseau instable (4G sénégalaise par exemple), les sessions SSH tombent souvent. Configurez ServerAliveInterval 60 pour envoyer un paquet de maintien toutes les 60 secondes.

Checklist

Paire de cles ED25519 générée avec passphrase forte.

Cle publique déployée avec ssh-copy-id ou manuellement.

Permissions correctes : ~/.ssh en 700, authorized_keys en 600, cle privée en 600.

Fichier ~/.ssh/config cree avec alias pour chaque serveur.

ssh-agent actif pour ne taper la passphrase qu’une fois.

Port SSH change (different de 22) dans sshd_config.

PermitRootLogin no et PasswordAuthentication no.

AllowUsers restreint aux comptes admin légitimes.

Configuration testée avec sshd -t avant redémarrage.

Session de secours ouverte lors de changements critiques.

fail2ban installe et configuré pour bannir les IPs abusives.

2FA active via google-authenticator pour les comptes sensibles.

tmux utilise pour les opérations longues a distance.

Bastion/jump host configuré pour acceder aux serveurs internes.

rsync utilise pour les sauvegardes incrementales vers serveur distant.