Si t’es ici c’est que tu te demandes sûrement comment configurer un vps linux. C’est une question légitime parce qu’on sait pas vraiment par où commencer et quelles sont les bonnes pratiques. Après des recherches, des questionnements et des galères, je me suis dis que ça pouvais être bien de mettre quelque part ce que j’ai appris (moi aussi je vais sûrement revenir sur cette doc hein 🤓).
On commence par le début, si t’as loué ton vps normalement (chez un hébergeur comme Hostinger, Ionos…) tu as reçu une adresse IPv4 et un mot de passe root. Tu as peut-être aussi un serveur dans ton salon, c’est pas impossible. Ce qui compte c’est d’avoir l’ip de ta machine et le mot de passe de l’administrateur. Si t’es allé plus loin t’as déjà peut-être un nom de domaine qui pointe vers ta machine (c’est pas obligatoire mais c’est mieux | tu gères ça chez qui t’as loué ton nom de domaine).
Ici, j’ai un vps sous Ubuntu 24.04
Pour commencer tu vas te connecter à ton vps en ssh. Pour ça il suffit de te rendre dans un terminal et de taper la commande suivante :
ssh root@<ip-de-ton-vps> # tu peux remplacer l'ip par ton nom de domaine s'il est paramétré
Ensuite un mot de passe va t’être demandé (celui de root), là c’est à toi de jouer.
Maintenant que t’es connecté, il faut que tu saches plusieurs choses. Sous linux, comme sur tout OS, il peut y avoir différents users. Par défaut, et dans ton cas, t’es en root (aka le Dieu de la machine) donc fait gaffe parce que t’as tous les droits et une fausse manipulation arrive vite.
Pour commencer, tu vas mettre à jour tes packages sur la machine en utilisant ces 2 commandes :
apt update # commande pour chercher les maj
# suivi de
apt upgrade # tu appliques les maj
Maintenant que tout est à jour et que tu as une bonne base, on va configurer un autre utilisateur que root. C’est une bonne pratique d’éviter de trop passer par lui.
Pour ça, tu vas utiliser la commande suivante :
sudo adduser <nom-du-user>
Cette commande va lancer un processus de création de user en demandant plusieurs infos, le plus important est le mot de passe que tu vas lui donner.
Une fois que tu as créé ce user, automatiquement, ta machine lui a créé un home dans /home. Pour vérifier, rends toi dans le répertoire et liste ce qu’il y a à l’intérieur avec :
cd /home # tu te déplaces dans /home
ls # tu listes tout ce qu'il y a dans le répertoire
Tu devrais voir un répertoire à son nom (un groupe avec le nom du user sera aussi créé et automatiquement attribué, c’est bon à savoir -> pour la gestion des droits).
Ce que je te conseille c’est de te créer un user à ton nom et de le rendre super admin de ta machine. Comme ça tu laisse root de côté. Pour ça, une fois ton user créé, tu vas le rendre sudoer avec la commande suivante :
sudo adduser <nom-du-user> sudo
Ainsi, ton user aura aussi les pouvoirs de super admin (il faudra cependant simplement ajouter sudo avant les commandes que tu feras).
Maintenant que ton user est ok 👌, tu vas tester la connexion. Pour ça, tu vas te déconnecter de la session actuelle puis te reconnecter avec le nouveau user :
exit # pour te déconnecter
# puis
ssh <nom-du-user>@<ip-de-ton-vps> # et tu tapes ton mot de passe
Ok, là on commence à être pas mal. Maintenant on va sécuriser ça encore plus.
A présent, on va mettre un firewall. Un firewall ça sert à bloquer certains ports de ta machine pour limiter les accès dessus (chaque port est une porte, sans mauvais jeu de mots).
On va utiliser un truc génial qui s’appelle UFW (Uncomplicated FireWall). Sur Ubuntu, il y est par défaut et en plus il est déjà activé. Pour ça, vérifie avec :
sudo ufw status
Tu devrais voir les accès autorisés par le firewall. Normalement ssh est autorisé, si c’est pas le cas (t’aurais pas pu te connecter mais au cas où), tape :
sudo ufw allow ssh
Cette commande nous servira plus tard pour autre chose… 🌐
Si en vérifiant le status seulement ssh est autorisé, c’est top.
Se connecter à un vps avec un mot de passe, c’est un peu dangereux en termes de sécurité. Déjà, ton vps doit stocker un mot de passe, donc si quelqu’un pour quelconque raison le récupère, c’est 💩. Ensuite, si un agent du FBI écoute ton trafic réseau, il peut récupérer le mot de passe dans la requête (il y a déjà eu des cas de fournisseurs internet un peu curieux), là aussi c’est 💩.
Pour éviter tout risque, on va mettre en place une connexion sécurisée via des clés ssh.
En gros, de ton côté, tu vas générer des clés ssh. Pour ça, rends-toi dans le dossier /.ssh à la racine de ton répertoire User sur ta machine (le répertoire est caché, une fois dans ton répertoire fait cd .ssh et tu arriveras dedans). Pour la génération de clés, des commandes existent comme :
ssh-keygen -t rsa
# ensuite tu rentres le nom de ta clé, moi j'aime bien garder id_rsa à la fin
Tu vas avoir 2 fichiers qui se sont générés, l’un avec le nom que t’as donné et le second a le même simplement avec un .pub à la fin. Le premier est ta clé privée, elle sert à déchiffrer ce que tu chiffres avec le deuxième fichier qui est ta clé publique. La privé faut que tu la donnes à personne, et la publique c’est ce que tu vas fournir aux services auquels tu te connectes.
Dans le cas de notre vps, la connexion va se passer de la sorte (le vps a la clé publique) :
De ce fait, le vps n’a aucune donnée sensible de stockée (si ta clé publique leak on s’en fou on fait rien avec), dans ta requête il n’y a rien de sensible aussi, et le serveur peut quand même savoir que c’est toi ou pas.
Maintenant faut mettre en place ça sur ton pc et sur ton vps.
Tu vas te rendre dans le répertoire .ssh de tout-à-l’heure (à la racine répertoire user) et tu vas créer un fichier config :
# avec nano
nano config
C’est un fichier de configuration, dedans tu vas préciser les différentes infos nécessaire pour se connecter à ton serveur (tu vas configurer toutes tes connexion ssh dedans, donc si t’en as d’autres ça sera ici aussi).
Exemple de configuration
Host <nom-de-la-connexion> # tu mets ce que tu veux
HostName <adresse-de-ton-vps> # ip ou nom de domaine
User <nom-du-user> # tu mets celui que t'as créé juste avant
Port <port-ssh> # si tu l'as pas changé c'est le 22
IdentityFile ~/.ssh/<nom-de-ta-clé-privé> # chemin vers la clé privé
Normalement, t’as fini du côté de ton pc, maintenant on passe sur le vps.
Tu vas te rendre dans le répertoire /home de ton user et tu vas créer un répertoire .ssh qui contient un fichier authorized_keys :
mkdir .ssh
cd .ssh
nano authorized_keys
Et dans ce fichier tu vas tout simplement coller le contenu de ta clé publique dedans (la .pub). Ssh ira voir dans le home du user qui se connecte les clés disponibles et fera sont mixmax (tu peux avoir plusieurs clés publiques si tu as plusieurs machines avec des clés différentes).
Maintenant (une fois déconnecté), tu peux tester la magie en faisant simplement :
ssh <nom-de-la-connexion-vps>
Si tout est ok, tu arrives directement sur ta machine.
Maintenant que ta superbe connexion ssh via clé est opérationnelle, on va empêcher la connexion avec mot de passe (pour limiter les risques). Il est important de faire ça une fois que la connexion via clé est totalement fonctionnelle, sinon tu vas te bloquer tout seul ton accès à la machine donc attention, vérifie bien que ça marche.
Rends-toi dans le dossier /etc/ssh de ton vps et tu vas modifier le fichier sshd_config (ne pas confondre avec ssh_config, sshd sert pour la gestion du serveur ssh)
cd /etc/ssh
sudo nano sshd_config
Il va falloir changer plusieurs paramètres. Quand un paramètre est en commentaire avec une valeur, ça veut dire que c’est la valeur par défaut. Tu vas me changer ces paramètres en mettant ça :
PasswordAuthentication no # désactiver la connexion via mot de passe
KbdInteractiveAuthentication no # Pour éviter de se faire embêter par PAM (j'explique pas ici mais mets no)
PermitRootLogin no # on empêche la connexion sur root (tu seras toujours sur ton user de toute façon)
Ensuite, il faut recharger ta configuration en redémarrant le service :
sudo service ssh restart
Normalement, la connexion via mot de passe est bloquée maintenant. Si ça marche pas faut que tu vérifies 2 trucs :
/etc/pam.d/sshd
# mets en commentaire cette ligne
@include common-auth
et vérifie /etc/ssh/sshd_config.d/50-cloud-init.conf
PasswordAuthentication yes # passe ça en no
Maintenant, ça devrait aller. La suite c’est de sécuriser encore plus ssh.
Fail2Ban c’est un service qui va éviter que ton ssh se fasse attaquer par des bots ou autres trucs relous. Dans notre cas, si une ip tente de se connecter et échoue trop de fois dans un laps de temps, elle sera blacklist pendant une période de temps.
sudo apt install fail2ban # installation du service
systemctl start fail2ban # lancement du service
systemctl enable fail2ban # mettre en démarrage automatique
systemctl status fail2ban # check que tout va bien
Normalement, t’as rien besoin de changer dans la conf de fail2ban pour ce qui est du ssh. Si cependant l’envie t’en prenait, et que tu voudrais modifier les fichiers fail2ban.conf et jail.conf (je t’invite à aller voir la doc de fail2ban), fais des copies fail2ban.local et jail.local. Au moins tu évite d’écraser les fichiers de base s’il y a une maj (fail2ban prend en priorité de manière auto les fichiers .local).
J’imagine que t’es sûrement intéressé de pouvoir héberger tes sites web sur ton vps hein ? Alors écoute bien.
Pour héberger des sites web, tu vas avoir besoin de ce qu’on appelle un serveur web. Un serveur web, c’est ce qui va renvoyer le contenu de tes sites aux personnes qui en font la requête. Tout va passer par lui, donc ça va être important de bien le configurer pour qu’il fonctionne bien. Ici, nous allons utiliser Nginx.
Nginx, une fois déployé, va se mettre à l’écoute sur les ports 80 et 443 de ta machine :
Nginx fonctionne de cette manière :
Tout d’abord, nous allons installer Nginx :
sudo apt install nginx
Une fois installé, on peut aller dans un navigateur et taper l’adresse (ou l’ip) de notre machine et on tombe sur une page de base Nginx. Mais avant ça, il va falloir modifier le paramétrage du firewall pour laisser passer Nginx.
sudo ufw status
Si Nginx n’apparait pas, utilise la commande suivante pour autoriser Nginx :
sudo ufw allow 'Nginx Full'
Vérifie le status à nouveau, normalement 2 nouvelles règles sont apparues.
Dans le répertoire /var/www, nous pouvons retrouver un sous-répertoire /html. C’est le répertoire de base de Nginx où l’on va retrouver la fameuse page de démarrage. On pourrait simplement mettre les sources de notre site dedans et ça marcherait, mais on aurait qu’un seul site accessible donc c’est pas ouf 🤷♂️
Pour pallier ça, on va configurer Nginx pour qu’il serve de reverse proxy pour faire les redirections.
Un reverse proxy, c’est ce qui va prendre les requêtes de tout le monde (extérieures, celles qui arrivent sur ton vps), et qui, en fonction de la provenance (l’url que la personne a utilisé), redirige sur le bon site. L’avantage c’est que tu peux avoir autant de sites que tu veux comme ça 🔥
Là, on peut voir que plusieurs personnes demandent d’accèder à des sites différents, Nginx s’en charge.
Déjà, on va supprimer ce répertoire /html :
sudo rm -r hmtl/
Ensuite, on va créer notre site et y ajouter nos sources :
sudo mkdir <nom-du-site>
cd <nom-du-site>
git clone <ton-repo-git>
(pour cet exemple je prends un site static qui ne nécéssite pas de lancer un serveur. L’idée est juste d’arriver sur une page html)
Dans le répertoire /etc/nginx, 2 sous-répertoires vont nous intéresser :
On va retrouver la même chose dans les deux, ce sont les configurations de nos sites web.
On va venir créer un fichier de configuration de notre site dans sites-available :
cd sites-available
sudo nano <nom-du-site>
Exemple de configuration basique :
server {
listen 80;
server_name <adresse-de-ton-site>; # adresse du site
location / {
root /var/www/<nom-du-site>; # le répertoire que t'as crée avant
index index.html; # optionnal: point d'entrée
}
}
Ensuite, on va aussi mettre cette configuration dans /sites-enabled en faisant un lien symbolique (un raccourci) avec la commande suivante :
sudo ln -s /etc/nginx/sites-available/<nom-du-site> /etc/nginx/sites-enabled/<nom-du-site>
Comme ça, quand tu modifies un fichier, ça modifie aussi l’autre grâce au lien.
Après, lorsque Nginx va voir une requête qui arrive sur l’adresse du site, il va automatiquement rediriger sur le bon répertoire (si t’as pas un site static mais un docker par exemple, il faut rediriger sur l’url qui convient).
Restart ton Nginx et tout sera bon :
sudo systemctl reload nginx
Et ça y est ! ton site est en ligne 😎
Maintenant, si tu vas sur ton site, tu remarqueras que la connexion n’est pas sécurisée car tu y accèdes en http. Pour pallier ça, nous allons installer un certificat ssl pour permettre la connexion via https. On va utiliser Let’s Encrypt.
Tout d’abord, tu vas l’installer :
sudo apt install certbot python3-certbot-nginx
Ensuite, on va faire une demande de certificat pour ton nom de domaine. Pour ça, on va utiliser la commande suivante :
sudo certbot --nginx -d <ton-nom-de-domaine> -d <www.ton-nom-de-domaine> # pour mon sous-domaine docs.lucasgoi.fr, j'ai pas utilisé le deuxième paramètre avec le www
Ensuite, Let’s encrypt se charge de tout. Tu peux simplement vérifier en allant voir le contenu de ta config dans /sites-available par exemple et il devrait y avoir des lignes rajoutées :
cd /etc/nginx/sites-available
cat <nom-du-site>
Ton certificat se renouvelle automatiquement, tu peux vérifier avec la commande :
sudo systemctl status certbot.timer
Et tu peux tester manuellement le renouvellement avec :
sudo certbot renew --dry-run
Pour finir, tu reload une dernière fois ton Nginx et tu devrais être opérationnel champion 💪.
sudo systemctl reload nginx
Maintenant que tu sais gérer un vps, le monde est à toi.
Lucas Goï - Mon site web 🦇