SSH, clés et premiers réflexes

Prérequis (cursus dev) : terminal et SSH, processus, ports.

Pourquoi

Le SSH est la porte d'entrée de ton serveur : tout l'internet la scanne en permanence. Un mot de passe, même costaud, se brute-force (essais automatiques massifs) ; une clé ED25519 — un algorithme moderne de signature, plus sûr et plus rapide que le vieux RSA — non. Et en arrivant sur une machine, tu dois savoir en 30 secondes si elle va bien.

Concepts

• Serveur privé (VPS) : une machine louée chez un fournisseur, administrée à distance. Sa console provider (écran d'urgence sur le site du fournisseur) sert quand SSH est mort : repère-la avant d'en avoir besoin.
• Bétail, pas animal de compagnie : image du métier — un serveur doit être remplaçable (reconstructible), pas choyé à la main. Tout ce qui suit découle de là.
• Charge (load average) : file d'attente du CPU sur 1/5/15 min. Au-delà du nombre de cœurs, ça rame (détaillé ici).
• Swap : mémoire de secours sur disque, bien plus lente que la RAM. Un peu de swap utilisé de temps en temps, c'est normal ; beaucoup en permanence = mémoire à genoux.

Exemple : clés, déploiement, verrouillage

Sur ton PC :

ssh-keygen -t ed25519 -C "portable-2026"
ssh-copy-id deploy@serveur
ssh deploy@serveur   # ne doit plus demander de mot de passe

Côté serveur, dans /etc/ssh/sshd_config (fichier de conf du daemon SSH, le programme serveur) :

PasswordAuthentication no
PermitRootLogin no

Puis systemctl reload sshd (systemd est détaillé au cours suivant ; retiens juste : reload recharge la conf sans couper les sessions). Règle de survie : garde ta session ouverte et teste une deuxième connexion. Si tu t'enfermes dehors, reste la console provider — lente et douloureuse.

Bon à savoir : ~/.ssh/authorized_keys en 600, le dossier ~/.ssh en 700, sinon le serveur refuse tes clés (côté user : silence ; côté serveur : log consultable via journalctl).

Cas réel

Un mot de passe root « temporaire » laissé pour un prestataire, jamais retiré : 6 mois plus tard, connexion depuis l'étranger à 4h du matin. Avec PermitRootLogin no + clés uniquement, cette classe d'incident n'existe pas.

Pièges

• Couper PasswordAuthentication sans session de secours ouverte.
• ssh-copy-id vers le mauvais user (root au lieu de ton user) : la clé atterrit au mauvais endroit.
• Oublier reload après avoir édité la conf : le fichier seul ne change rien.

À retenir

Clés ED25519 uniquement, root interdit, double session pour tester, cinq commandes d'auscultation (uptime, df -h, free -h, ss -tlnp, journalctl -p err -b) par cœur. Et note chaque commande manuelle : HISTFILE (le fichier où bash enregistre ton historique, ~/.bash_history par défaut) est une mémoire, pas une documentation.