Chapitre 5.1 — Première connexion

⏱️ TL;DR — Ton VPS vient de naître : le fournisseur t’a donné une IP et un accès root (par mot de passe, ou déjà par clé si tu l’as fournie à la création). Première connexion : ssh root@ip. Puis, avant tout le reste, les réflexes de premier jour : mettre à jour le système (apt update && apt upgrade), régler le fuseau horaire et la locale, donner un hostname propre (hostnamectl set-hostname formacampus-prod), vérifier qui écoute (ss -tulpn), le disque (df -h) et la RAM (free -h), et — sur un petit VPS — ajouter un peu de swap. On ne durcit pas encore : on pose le décor, on prend la mesure de la machine, et on la rend saine avant d’y toucher sérieusement.

🎯 Objectifs

• Se connecter à un VPS neuf en root et comprendre ce que le fournisseur a (et n’a pas) configuré.
• Exécuter les premiers réflexes : mise à jour complète, fuseau, locale, hostname, /etc/hosts.
• Inspecter l’état de la machine : ports à l’écoute, espace disque, mémoire.
• Ajouter et régler du swap sur un petit VPS pour éviter les crashs mémoire.

Se connecter : ssh root@ip

Le fournisseur t’a livré deux choses dans son interface : l’adresse IP publique du VPS et un accès root. Deux cas de figure :

• Tu as collé ta clé publique à la création du VPS → tu te connectes directement, sans mot de passe.
• Tu n’as rien fourni → le fournisseur t’a envoyé un mot de passe root (par mail ou dans le panneau). Tu t’en sers pour cette première connexion, et on le remplacera vite par une clé.

Depuis ta machine locale (rappel de la Partie 4) :

🐚 Au terminal

ssh root@203.0.113.10          # remplace par l'IP de TON VPS
# Première connexion : SSH te montre l'empreinte de la clé du serveur
# et demande de confirmer. Tape "yes" (c'est le TOFU : trust on first use).

La première fois, SSH affiche une empreinte et te demande de confirmer que tu veux ajouter ce serveur à tes hôtes connus (known_hosts). C’est normal : SSH n’a jamais vu cette machine. Tape yes. Si un mot de passe t’est demandé, c’est celui du fournisseur.

Une fois dedans, ton invite ressemble à root@ubuntu-2gb-fsn1-1:~#. Le # final, c’est la marque de root : tu es tout-puissant. C’est pratique pour installer, et dangereux pour tout le reste — on ne restera pas root longtemps (chapitre 5.3).

🔒 Sécurité — À la seconde où ce VPS a une IP publique, il est scanné. Des robots testent root avec des mots de passe courants en boucle. Tant que la connexion par mot de passe et l’accès root sont ouverts, la machine est vulnérable au bruteforce. C’est exactement pour ça qu’on ne traîne pas : on met à jour, on crée deploy, on coupe root et le mot de passe, on pose le pare-feu. Considère cette session root comme un chantier temporaire, pas comme un état stable.

Réflexe n°1 : mettre à jour, tout de suite

Une image de VPS a beau être « fraîche », elle date du jour où le fournisseur l’a figée — souvent des semaines, avec des correctifs de sécurité en retard. Le tout premier geste, c’est donc de rafraîchir l’index des paquets puis d’appliquer les mises à jour disponibles.

🐚 Au terminal

apt update            # rafraîchit la LISTE des paquets et de leurs versions
apt upgrade           # installe les mises à jour disponibles (demande confirmation)
# En root, pas besoin de sudo. On détaille apt au chapitre 5.2.

apt update ne met rien à jour : il télécharge la liste à jour de ce qui existe dans les dépôts. apt upgrade fait le vrai travail : il installe les nouvelles versions. Toujours dans cet ordre — sinon upgrade travaille avec une liste périmée. On dissèque cette distinction au chapitre 5.2.

💡 Réflexe — « Nouveau serveur = apt update && apt upgrade avant toute autre chose. » Le && enchaîne les deux : upgrade ne se lance que si update a réussi. C’est le premier réflexe du premier jour, et tu le rejoueras sur chaque machine neuve.

Si le noyau (kernel) a été mis à jour, un redémarrage peut être nécessaire pour qu’il prenne effet. Ubuntu te prévient parfois via un fichier /var/run/reboot-required. Sur un serveur qui ne sert encore rien, un reboot est indolore.

reboot                # redémarre le serveur ; ta session SSH se coupe.
# Attends ~30 s, puis reconnecte-toi : ssh root@203.0.113.10

Réflexe n°2 : fuseau, locale, hostname

Un serveur mal réglé sur ces trois points, ça se paie plus tard : des logs à la mauvaise heure (galère pour corréler un incident), des messages système illisibles, un nom de machine générique qui ne dit rien.

Le fuseau horaire

Par défaut, un VPS est souvent en UTC. C’est un choix défendable (tous tes serveurs sur le même fuseau), mais pour un serveur unique au service d’un public français, l’heure locale rend les logs plus lisibles.

🐚 Au terminal

timedatectl                                   # affiche l'heure, le fuseau, l'état de la synchro NTP
timedatectl set-timezone Europe/Paris         # règle le fuseau sur Paris
timedatectl list-timezones | grep Europe      # pour retrouver le nom exact d'un fuseau

timedatectl gère aussi la synchronisation de l’horloge (NTP). Vérifie que System clock synchronized: yes apparaît : une horloge qui dérive casse TLS, les certificats et l’authentification.

La locale

La locale détermine la langue et le format des messages système, l’encodage, le tri. Un serveur bien configuré est en UTF-8. Si tu vois des avertissements du type locale not set, règle-la.

locale                                # montre les variables de locale actuelles
# En cas d'avertissement, sur Ubuntu :
locale-gen en_US.UTF-8                 # génère la locale (adapte si tu veux fr_FR.UTF-8)
update-locale LANG=en_US.UTF-8         # la définit comme locale par défaut
# Reconnecte-toi pour que ça prenne effet.

⚠️ Piège — Garder l’UTF-8 non configuré parce que « ça a l’air de marcher ». Une locale absente fait planter certains scripts et paquets de façon obscure (perl: warning: Setting locale failed), et casse l’affichage des accents. Deux minutes de réglage évitent des heures de débogage plus tard.

Le hostname

Le hostname, c’est le nom de la machine. ubuntu-2gb-fsn1-1, c’est le nom générique du fournisseur — inutile et anonyme. Donne-lui un nom parlant : il apparaîtra dans ton invite, tes logs, tes alertes.

hostnamectl                                    # affiche le hostname actuel et les infos système
hostnamectl set-hostname formacampus-prod      # baptise la machine

Complète le fichier /etc/hosts pour que le nom résolve en local (sinon certains outils râlent avec un sudo: unable to resolve host). Édite-le avec nano /etc/hosts et assure-toi d’avoir une ligne qui associe le nom à l’adresse de bouclage :

127.0.0.1   localhost
127.0.1.1   formacampus-prod

🧭 Sur FormaCampus — L’équipe rapatrie sa prod d’un PaaS vers un VPS Ubuntu LTS. Premier geste sur la machine neuve : hostnamectl set-hostname formacampus-prod, fuseau Europe/Paris, locale UTF-8. Ce nom formacampus-prod va suivre toute la partie : il s’affichera dans les logs journalctl, dans les mails de fail2ban, dans le monitoring plus tard. Un serveur bien nommé, c’est un serveur qu’on identifie d’un coup d’œil quand on en gère plusieurs (formacampus-prod, formacampus-staging…).

Réflexe n°3 : prendre la mesure de la machine

Avant de construire dessus, regarde ce qui tourne déjà et ce dont tu disposes. Trois commandes suffisent.

Qui écoute sur le réseau ?

ss -tulpn        # liste les sockets qui ECOUTENT (serveurs), avec le programme et le port
# -t TCP  -u UDP  -l en écoute  -p le processus  -n en numérique (pas de résolution de noms)

Sur un VPS neuf, tu devrais voir peu de choses : sshd sur le port 22, éventuellement un resolver DNS local. Chaque ligne est une porte : un service qui écoute sur 0.0.0.0 est joignable depuis Internet, un service sur 127.0.0.1 ne l’est qu’en local. Si tu vois un service inattendu écouter sur 0.0.0.0, c’est une surface d’attaque à questionner.

🔒 Sécurité — ss -tulpn est ton inventaire des ouvertures. La règle d’or : moins il y a de lignes en 0.0.0.0, mieux c’est. Retiens la différence, elle est centrale dans tout le cours — un service sur 127.0.0.1 (localhost) est privé à la machine ; sur 0.0.0.0, il est exposé au monde. Ta base de données, plus tard, devra écouter sur 127.0.0.1, jamais sur 0.0.0.0.

Combien d’espace disque ?

df -h            # espace disque par système de fichiers, en tailles LISIBLES (-h : human)
# Regarde la ligne montée sur "/" : Size, Used, Avail, Use%.

Un disque plein, c’est un serveur qui tombe : plus de logs, plus de base qui écrit, Nginx qui renvoie des erreurs. df -h te donne l’état ; surveille surtout la colonne Use% de la partition /. On reparlera de surveillance disque en Partie 14.

Combien de mémoire ?

free -h          # RAM et swap : total, utilisé, libre, cache
# La colonne "available" indique la mémoire réellement mobilisable.

free -h t’affiche la RAM et le swap. Sur un petit VPS (1–2 Go), c’est ici qu’on décide s’il faut ajouter du swap — juste en dessous.

Réflexe n°4 : ajouter du swap sur un petit VPS

Le swap est un espace disque utilisé comme rallonge de la RAM : quand la mémoire physique sature, le noyau y déplace des pages plutôt que de tuer un processus. Sur un petit VPS, c’est un filet de sécurité précieux — un next build ou Postgres + Node en pointe peuvent frôler la limite, et l’OOM killer (celui qui tue un process quand la RAM est pleine) est brutal.

⚠️ Piège — Le swap n’est pas un remplacement de la RAM. Il est beaucoup plus lent (c’est du disque). Un serveur qui swappe en permanence rame atrocement (thrashing). Le swap est un coussin pour absorber les pics, pas une excuse pour sous-dimensionner. Si tu swappes tout le temps, il faut plus de RAM (Partie 1.4), pas plus de swap.

Vérifie d’abord si un swap existe déjà (free -h, ou swapon --show qui n’affiche rien s’il n’y en a pas). S’il n’y en a pas, crée un fichier de swap. Une taille raisonnable : 1 à 2 Go sur un petit VPS.

🐚 Au terminal

swapon --show                        # rien affiché => pas de swap actif
fallocate -l 2G /swapfile            # crée un fichier de 2 Go pour le swap
chmod 600 /swapfile                  # lisible/écrivable par root SEULEMENT (sinon faille)
mkswap /swapfile                     # formate le fichier en zone de swap
swapon /swapfile                     # active le swap immédiatement
free -h                              # vérifie : la ligne Swap montre maintenant 2 Go

Le chmod 600 est obligatoire : un fichier de swap lisible par tous exposerait des données mémoire. mkswap prépare le fichier, swapon l’active. Mais cette activation est temporaire : elle disparaît au reboot. Pour la rendre permanente, ajoute une ligne à /etc/fstab (le fichier qui liste les montages au démarrage) :

/swapfile   none   swap   sw   0   0

Édite /etc/fstab avec nano, ajoute cette ligne à la fin, enregistre. Au prochain reboot, le swap sera activé automatiquement.

💡 Réflexe — Après avoir touché /etc/fstab, teste avant de rebooter les yeux fermés : un /etc/fstab cassé peut empêcher la machine de redémarrer. Une vérif simple : swapon --show doit lister /swapfile après un swapon -a (qui relit la config). Sur un fichier de swap, le risque est faible, mais prends l’habitude de vérifier une ligne fstab avant de compter dessus.

Dernier réglage utile : le swappiness, qui règle l’empressement du noyau à utiliser le swap (0 = le plus tard possible, 100 = très volontiers). Sur un serveur, une valeur basse (10) est un bon défaut : on veut que le swap reste un filet, pas un réflexe.

cat /proc/sys/vm/swappiness          # affiche la valeur actuelle (souvent 60)
sysctl vm.swappiness=10              # change la valeur pour la session courante
echo 'vm.swappiness=10' >> /etc/sysctl.conf   # la rend permanente (relue au boot)

📚 La doc — Les détails de timedatectl, hostnamectl, swapon, fallocate et sysctl sont dans leurs pages man (man swapon, man sysctl). Pour le format exact de /etc/fstab, voir man fstab. En cas de doute sur une option, le man fait autorité — n’improvise pas une option de mémoire.

L’ordre des opérations, en résumé

Ce chapitre pose le décor. Tu as un serveur à jour, à l’heure, bien nommé, dont tu connais les ressources et qui a un filet de swap. Rien n’est encore durci : root est toujours ouvert, pas de pare-feu, pas de fail2ban. C’est le sujet des chapitres suivants. L’ordre compte :

✏️ Exercices

Exercice 1 — Le premier quart d’heure. Tu viens de recevoir un VPS Ubuntu LTS : IP 203.0.113.10, mot de passe root fourni par mail. Écris la suite de commandes de tes cinq premières minutes, de la connexion jusqu’au hostname, en une ligne de commentaire par commande.

ssh root@203.0.113.10                        # se connecter (taper "yes" au premier contact)
apt update && apt upgrade                    # rafraîchir l'index puis appliquer les MàJ
timedatectl set-timezone Europe/Paris        # régler le fuseau horaire
hostnamectl set-hostname formacampus-prod    # nommer la machine
nano /etc/hosts                              # ajouter la ligne 127.0.1.1 formacampus-prod
ss -tulpn                                    # vérifier qui écoute (attendu : surtout sshd:22)
df -h                                        # vérifier l'espace disque
free -h                                      # vérifier la RAM et voir s'il faut du swap

Exercice 2 — Ajoute un swap propre. Sur un VPS à 1 Go de RAM sans swap, ajoute un fichier de swap de 1 Go, active-le, rends-le permanent et baisse le swappiness. Donne les commandes et explique le rôle du chmod.

fallocate -l 1G /swapfile                     # créer un fichier de 1 Go
chmod 600 /swapfile                           # accès root SEULEMENT (sécurité)
mkswap /swapfile                              # formater en zone de swap
swapon /swapfile                              # activer maintenant
echo '/swapfile none swap sw 0 0' >> /etc/fstab   # rendre permanent (au boot)
sysctl vm.swappiness=10                        # swap utilisé avec parcimonie
echo 'vm.swappiness=10' >> /etc/sysctl.conf    # permanent
free -h                                        # vérifier : Swap = 1 Go

🧠 Quiz de révision

Chapitre suivant : 5.2 — apt & paquets — comment installer, mettre à jour et supprimer des logiciels proprement, et pourquoi tout curl | bash mérite la méfiance.