Ce que vous saurez faire
Ce tutoriel vous apprend a utiliser SSH (Secure Shell) pour administrer vos serveurs Linux a distance en toute securite. Pour une PME senegalaise 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 securisee), a configurer un fichier ~/.ssh/config pour multiplier les raccourcis, a transferer 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 automatisees. A la fin de ce guide, vous administrerez vos 3, 5, ou 20 serveurs avec des commandes de deux caracteres, sans jamais taper de mot de passe, tout en ayant renforce la securite globale de votre infrastructure contre 99% des tentatives d’intrusion automatisees.
Etape 1 : Premiere 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 defaut 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
Verifiez toujours l’empreinte lors de la premiere connexion. Demandez-la au fournisseur du serveur ou consultez-la via la console du VPS.
Etape 2 : Generer 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 deposee sur les serveurs, la privee 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 privee en cas de vol de votre ordinateur portable. Utilisez ssh-agent pour ne la taper qu’une fois par session.
Etape 3 : Deployer la cle publique sur le serveur
La methode 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"
Etape 4 : Se connecter sans mot de passe
Une fois la cle deployee, la connexion ne demande plus le mot de passe du serveur, seulement la passphrase locale (si definie).
# 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
Etape 5 : Configurer ~/.ssh/config
Le fichier ~/.ssh/config permet de creer des alias et de memoriser 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
Etape 6 : Transferer 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/
Etape 7 : Synchroniser avec rsync
rsync est plus puissant que scp : il ne transfere que les differences, gere les gros volumes, et peut reprendre une synchronisation interrompue. Ideal 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/
Etape 8 : Executer des commandes a distance
SSH permet d’executer une commande sans session interactive. Ideal pour scripter des operations 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"
Etape 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
Etape 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/
Etape 11 : Durcir la configuration SSH du serveur
Par defaut, SSH est trop permissif. Durcissez /etc/ssh/sshd_config pour bloquer les attaques automatisees.
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
Etape 12 : Proteger 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
Etape 13 : Authentification a deux facteurs
Ajoutez un code Google Authenticator pour une securite maximale. Meme avec la cle privee 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
Etape 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 operations 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 etre 700, authorized_keys doit etre 600. Aussi verifier que PubkeyAuthentication yes est actif dans sshd_config.
Perdre l’acces apres durcissement : erreur classique, changer le port ou desactiver 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 privee : la cle privee (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 regenerez une paire.
Utiliser le port 22 sur internet : les bots scannent massivement le port 22. Changer pour un port eleve (entre 10000 et 65535) reduit drastiquement les tentatives automatiques sans couter en securite reelle.
Ne pas utiliser de passphrase : une cle sans passphrase est comme une cle de maison laissee 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 reseau instable (4G senegalaise 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 generee avec passphrase forte.
Cle publique deployee avec ssh-copy-id ou manuellement.
Permissions correctes : ~/.ssh en 700, authorized_keys en 600, cle privee 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 legitimes.
Configuration testee avec sshd -t avant redemarrage.
Session de secours ouverte lors de changements critiques.
fail2ban installe et configure pour bannir les IPs abusives.
2FA active via google-authenticator pour les comptes sensibles.
tmux utilise pour les operations longues a distance.
Bastion/jump host configure pour acceder aux serveurs internes.
rsync utilise pour les sauvegardes incrementales vers serveur distant.