SSH : administrer un serveur à distance proprement

SSH (Secure Shell) est un protocole de connexion à distance chiffré. C'est l'outil du quotidien pour tout développeur qui déploie sur un VPS — souvent pour faire tourner une application Docker — administre un serveur Linux, ou transfère des fichiers. macOS et Linux l'ont en natif. Sur Windows, il est inclus depuis Windows 10.

Se connecter

# Syntaxe de base
ssh utilisateur@adresse_ip
 
# Sur un port non standard
ssh -p 2222 user@serveur.com

Lors de la première connexion, SSH demande si vous faites confiance à la clé du serveur. Tapez yes — elle sera mémorisée dans ~/.ssh/known_hosts. Si cette clé change lors d'une connexion future, SSH vous avertira : c'est un signal d'alerte potentiel.

Authentification par clés

Les mots de passe sont pratiques mais faibles face aux attaques par force brute. Les clés SSH sont bien meilleures : une clé privée sur votre machine, une clé publique sur le serveur.

# Générer une paire de clés ed25519 (recommandé)
ssh-keygen -t ed25519 -C "votre.email@example.com"
 
# Copier la clé publique sur le serveur
ssh-copy-id utilisateur@serveur.com

Ensuite, plus aucun mot de passe demandé. Si vous gérez plusieurs serveurs, le fichier ~/.ssh/config évite de tout retaper :

Host monserveur
    HostName 192.168.1.100
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
 
Host production
    HostName prod.monsite.com
    User deploy
    IdentityFile ~/.ssh/id_ed25519

Puis simplement : ssh monserveur ou ssh production.

Transférer des fichiers

# Copier un fichier vers le serveur
scp fichier.txt user@serveur.com:/chemin/destination/
 
# Copier un dossier complet
scp -r mon_dossier/ user@serveur.com:/var/www/
 
# Télécharger depuis le serveur
scp user@serveur.com:/var/log/app.log ./

Pour la synchronisation continue, rsync est plus efficace — c'est aussi l'outil utilisé dans les pipelines GitHub Actions pour le déploiement continu. Il ne retransfère que les fichiers modifiés.

rsync -avz --delete /home/user/ user@backup.com:/backups/

Sécuriser le serveur SSH

Par défaut, sshd écoute sur le port 22 et accepte les mots de passe. Changez ça. Éditez /etc/ssh/sshd_config sur le serveur :

Port 2222
PasswordAuthentication no
PermitRootLogin no
AllowUsers admin deploy

# Appliquer les changements
sudo systemctl restart ssh

Désactiver l'authentification par mot de passe est le changement le plus impactant — les scans automatiques qui testent des combinaisons user/password en brute force deviennent inutiles.

Tunneling et proxying

SSH ne sert pas qu'à ouvrir un terminal. Vous pouvez rediriger des ports locaux vers le serveur :

# Accéder à une base de données distante sur localhost:3306
ssh -L 3306:localhost:3306 user@serveur-db.com
 
# Proxy SOCKS pour router tout le trafic via le serveur
ssh -D 1080 user@serveur.com

Dépannage courant

Si vous avez Permission denied (publickey), vérifiez les permissions des fichiers :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Pour déboguer une connexion refusée, -v (ou -vvv pour plus de détail) affiche tout ce qui se passe :

ssh -v user@serveur.com

fail2ban est complémentaire à tout ça — il bloque automatiquement les IPs qui accumulent les tentatives de connexion échouées. Combiné à UFW pour la gestion des ports et à l'authentification par clés, vous couvrez l'essentiel des vecteurs d'attaque courants.