Configurer un serveur Linux débutant pas à pas sans stress

Le serveur que vous voyez dans les tutoriels n'existe pas. Celui des captures d'écran propres, où chaque commande fonctionne du premier coup, où personne n'a jamais perdu l'accès SSH à 23 h un dimanche. Le vrai, c'est celui sur lequel on tape une commande et où le terminal répond Permission denied sans plus d'explication. Je le sais parce que j'ai monté mon premier serveur Linux il y a quelques années pour héberger un Nextcloud familial — et j'ai passé les trois premières heures à me demander pourquoi mon adresse IP changeait toute seule.

Configurer un serveur Linux quand on débute, ça n'est pas compliqué en soi. C'est juste qu'on vous explique rarement l'ordre des choses, et encore moins ce qui casse quand on saute une étape. Ce qui suit est le chemin que j'aurais aimé qu'on me donne : installer, sécuriser, vérifier — dans cet ordre, avec les commandes exactes.

Comment configurer un serveur Linux quand on débute vraiment : le bon ordre

La première décision n'est pas technique, elle est stratégique : quelle distribution poser ? On va vous sortir dix noms. La vérité, c'est que pour un débutant, deux familles suffisent — et le choix entre elles dépend d'un seul critère : voulez-vous des versions stables qui bougent peu, ou les dernières nouveautés ?

Quelle distribution pour un serveur Linux maison ou perso ?

Ubuntu Server et Debian sortent du même tronc commun : paquets .deb, gestionnaire apt, documentation pléthorique. Une question posée sur un forum trouvera une réponse dans la demi-heure. Alma Linux et Rocky sont d'excellentes options aussi, mais dès que vous tapez une commande un peu exotique, vous tomberez sur des réponses écrites pour Red Hat et il faudra traduire.

Franchement, en 2026, pour quelqu'un qui n'a jamais ouvert un terminal serveur, je recommande Ubuntu Server LTS. Les versions LTS reçoivent des mises à jour pendant plusieurs années, ce qui vous laisse le temps d'apprendre sans recommencer tous les dix-huit mois.

Distribution	Public idéal	Ce qui coince
Ubuntu Server LTS	Premier serveur, maison, apprentissage	Encombrée de paquets par défaut
Debian stable	Serviteurs qui doivent tourner sans qu'on y touche	Logiciels plus anciens
Alma / Rocky	Environnement d'entreprise existant	Doc souvent orientée Red Hat

Installer un serveur Linux : la clé USB et l'ISO

Une image ISO, un outil pour la graver (Rufus sous Windows, dd sous Linux, Balena Etcher partout), une machine — physique ou virtuelle. Pas besoin d'un gros serveur dédié pour apprendre : une VM avec 2 Go de RAM et 20 Go de disque suffit largement pour tester. C'est d'ailleurs ce que j'ai fait pendant deux semaines avant de toucher à un vrai serveur, et c'est ce qui m'a évité de casser quelque chose d'important.

Pendant l'installation, trois choix comptent :

1. Le partitionnement. Prenez l'option automatique. Le LVM manuel, c'est pour plus tard.
2. Installez OpenSSH Server si l'installeur le propose — sinon vous devrez le faire à la main.
3. Définissez un mot de passe solide pour l'utilisateur que vous créez. Il servira une seule fois.

Redémarrez. Vous arrivez sur une invite de connexion en mode texte, sans souris. C'est normal, et c'est même bon signe : un serveur n'a pas besoin d'interface graphique.

Première connexion et configuration réseau : les deux réglages à ne pas rater

Tapez ip a. Si votre machine a récupéré son adresse automatiquement (DHCP), cette IP peut changer au prochain redémarrage. Et là, votre accès SSH tombe en erreur connection timed out sans que rien n'ait bougé. J'ai vécu ça une fois — j'ai cherché pendant quarante minutes avant de comprendre que le routeur avait juste réattribué une autre adresse.

Fixer une adresse IP statique

Sous Ubuntu récent, le réseau se configure avec Netplan, via un fichier YAML. Deux règles simples : l'indentation en espaces (jamais de tabulation) et la syntaxe stricte.

sudo nano /etc/netplan/50-cloud-init.yaml

Vous y déclarerez l'interface, l'adresse avec un suffixe /24, la passerelle et les serveurs DNS. Puis :

sudo netplan apply

Vérifiez immédiatement avec ip a et un ping vers l'extérieur. Si le ping échoue, c'est généralement que la passerelle est mal écrite — l'erreur numéro un des débutants sur Netplan.

Se connecter en SSH et vérifier que ça tient

Depuis votre poste de travail :

ssh [email protected]

Ça fonctionne ? Parfait. Ne touchez à rien d'autre tout de suite. Avant de sécuriser, générez une paire de clés sur votre poste, puis copiez la clé publique sur le serveur :

ssh-keygen -t ed25519
ssh-copy-id [email protected]

Testez la connexion par clé dans un deuxième terminal, en gardant le premier ouvert. C'est un réflexe de survie : si vous fermez votre session unique et que la clé ne fonctionne pas, vous êtes bon pour rebrancher un écran et un clavier.

Sécuriser son serveur Linux : cinq minutes qui évitent bien des dégâts

Un serveur neuf, exposé sur internet, commence à recevoir des tentatives de connexion en quelques heures. Sur le mien, les premières lignes de log sont apparues la nuit suivant la mise en ligne — des dizaines d'essais sur le compte root, tous automatisés. Rien de personnel : c'est un balayage permanent.

Durcir SSH sans se couper l'accès

Ouvrez le fichier de configuration :

sudo nano /etc/ssh/sshd_config

Trois modifications, dans cet ordre :

• PermitRootLogin no — on n'entre jamais en root directement.
• PasswordAuthentication no — uniquement par clé.
• Ajoutez votre utilisateur dans le groupe sudo s'il n'y est pas déjà.

Avant de redémarrer le service, vérifiez la syntaxe : sudo sshd -t. Aucune sortie = tout va bien. Ensuite :

sudo systemctl restart ssh

Et surtout, ne fermez pas votre session actuelle. Ouvrez-en une nouvelle. Si elle passe, vous pouvez respirer. Sinon, vous avez encore la première pour corriger.

Pare-feu et mises à jour automatiques

Le pare-feu d'Ubuntu s'appelle UFW. Deux commandes :

sudo ufw allow OpenSSH
sudo ufw enable

L'ordre est capital. Autorisez SSH d'abord, activez ensuite. J'ai inversé ces deux lignes une fois sur un serveur distant — j'ai dû passer par la console de secours de l'hébergeur. Vingt minutes de stress pour une inversion.

Pour les mises à jour, unattended-upgrades fait le travail seul : on installe le paquet, on accepte la configuration proposée, et les correctifs de sécurité s'appliquent sans intervention. Ajoutez fail2ban si le serveur est exposé sur internet : il bannit les adresses qui accumulent les échecs de connexion.

Installer un service : l'exemple du serveur de fichiers

Un serveur sans service est une machine inutile. Le cas d'usage le plus courant en maison, c'est le partage de fichiers. Samba, open source et gratuit, fait ça très bien.

sudo apt update
sudo apt install samba

Puis on déclare un dossier dans /etc/samba/smb.conf, on crée un utilisateur Samba avec smbpasswd -a votrenom, et on redémarre le service. La vérification qui compte :

sudo systemctl status smbd
ss -tlnp | grep 445

Si le port 445 n'apparaît pas, le service n'écoute pas — inutile de chercher plus loin côté client. Cette gymnastique (systemctl status, puis ss) est la première chose à réflexe à acquérir : on vérifie le service avant de suspecter le réseau.

Les erreurs de débutant que j'ai vraiment commises

Une liste courte, mais qui vous fera gagner des heures.

Perdre l'accès SSH après le pare-feu

Déjà décrit : on autorise SSH avant d'activer UFW, jamais l'inverse.

Une clé SSH copiée dans le mauvais dossier

Le fichier doit finir dans ~/.ssh/authorized_keys, avec les permissions 600 sur .ssh. Un chmod 700 ~/.ssh et chmod 600 ~/.ssh/authorized_keys règle 90 % des refus de connexion par clé.

Oublier de mettre à jour avant d'installer

apt update sans apt upgrade laisse des paquets incohérents. Les deux, à chaque fois.

Et une règle générale : quand une commande échoue, lisez le message. Vraiment. Les débutants (moi le premier) cliquent souvent sur « fermer » sans lire. La moitié des erreurs se règlent en comprenant les trois mots que le terminal vient d'afficher.

Ce qui reste quand on a fini

Un serveur Linux configuré pour débuter, ce n'est pas un serveur parfait. C'est un serveur qui redémarre, qui accepte votre clé SSH, qui refuse les mots de passe, et qui tient une adresse fixe. Le reste — les services, les sauvegardes, les certificats — viendra avec l'usage.

La vraie compétence, celle qui ne s'apprend pas dans un tutoriel, c'est de savoir où regarder quand ça casse. Un log, un statut de service, un port qui écoute. Une fois que vous avez ce réflexe, aucun serveur ne vous fait plus peur.

Et puis un jour, vous taperez sudo systemctl status par habitude, sans y penser. Ce jour-là, vous ne serez plus débutant.