Installation et configuration d’Ubuntu Serveur 26.04 LTS avec OpenSSH, réseau Netplan et pare-feu UFW

Ubuntu Serveur 26.04 LTS : installer, configurer et sécuriser votre serveur

User avatar placeholder
Écrit par Vincent

Mis à jour le 12 août 2026

Ubuntu Serveur est la variante d’Ubuntu destinée aux machines qui rendent un service : serveur web, serveur de fichiers, hyperviseur, machine de sauvegarde. Elle s’installe sans environnement de bureau et s’administre en ligne de commande, localement ou par SSH. La version courante est Ubuntu 26.04 LTS « Resolute Raccoon », publiée le 23 avril 2026 et maintenue jusqu’en avril 2031.

L’essentiel
Version recommandée : Ubuntu Server 26.04 LTS (Resolute Raccoon), sortie le 23 avril 2026
Support : correctifs de sécurité jusqu’en avril 2031, dix ans avec Ubuntu Pro
Prérequis (installation par ISO) : 1,5 Go de RAM et 5 Go de disque au minimum, 3 Go et 25 Go recommandés
Prix : le système est gratuit, y compris en usage professionnel
Fiabilité : procédure conforme à la documentation officielle Canonical, consultée le 11 août 2026

Ubuntu Serveur ou Ubuntu Desktop : la différence en pratique

Comparatif Ubuntu Serveur et Ubuntu Desktop : criteres de choix selon l'usage de la machine

 

Les deux éditions partagent le même noyau, les mêmes dépôts de paquets et le même gestionnaire apt. Ce qui les sépare tient à la sélection de logiciels installés par défaut, et cette différence a des conséquences concrètes.

  Ubuntu Desktop Ubuntu Serveur
Environnement de bureau GNOME préinstallé Aucun
Interface d’administration Graphique et terminal Terminal uniquement
Installateur Graphique Texte (Subiquity)
RAM annoncée par Canonical 6 Go pour un usage confortable 1,5 Go minimum, 3 Go recommandés
Surface d’attaque Étendue Réduite au strict nécessaire
Accès distant par défaut Non configuré OpenSSH proposé à l’installation
Noyau Identique Identique

Un serveur sans interface graphique consomme moins de mémoire et de processeur, et expose moins de composants susceptibles d’être attaqués. Vous n’installez que ce dont vous avez besoin, au lieu de retirer ce dont vous ne voulez pas.

Rien ne vous empêche de transformer une Ubuntu Desktop en serveur, ou l’inverse, en ajoutant les paquets manquants. Partir de l’édition serveur reste plus propre.

Si votre machine est un ordinateur de bureau ou un portable, c’est l’édition Desktop qu’il vous faut : notre guide Ubuntu Desktop 26.04 LTS détaille son installation et la mise à niveau depuis la 24.04.

Ubuntu Serveur est-il gratuit ?

Oui. Ubuntu Serveur est un logiciel libre, téléchargeable et utilisable sans licence ni frais, y compris en production et dans un cadre commercial. Aucune fonctionnalité n’est réservée à une édition payante.

Cette question revient parce que les résultats de recherche affichent des tarifs en euros par mois. Ces prix ne concernent pas le système d’exploitation : ils correspondent à la location d’une machine chez un hébergeur, qui installe Ubuntu Serveur dessus. Deux dépenses distinctes se confondent facilement :

  • Le système : gratuit, quelle que soit la machine.
  • Le matériel ou l’hébergement : payant si vous louez un VPS ou un serveur dédié, gratuit si vous réutilisez une machine que vous possédez déjà.

Canonical propose séparément Ubuntu Pro, qui étend le support de sécurité de cinq à dix ans sur l’ensemble de l’archive Ubuntu, et jusqu’à quinze ans avec le module Legacy. Cet abonnement est payant en entreprise, mais gratuit pour un usage personnel sur cinq machines physiques au maximum, et cinquante pour les membres officiels de la communauté Ubuntu. Pour un serveur domestique, la couverture étendue ne vous coûte donc rien.

Quelle version d’Ubuntu Serveur installer en 2026

Pour une nouvelle installation, prenez Ubuntu Server 26.04 LTS. Les versions intermédiaires, publiées tous les six mois, ne reçoivent que neuf mois de mises à jour : elles n’ont pas leur place sur une machine censée fonctionner sans intervention.

Situation Version à installer
Nouvelle installation 26.04 LTS
Parc existant en 24.04 LTS, stable Rester en 24.04
Machine en 22.04 LTS Migrer, mais par étapes (voir ci-dessous)
Besoin d’un support de dix à quinze ans 26.04 LTS + Ubuntu Pro

Avertissement — On ne saute pas une version LTS. Depuis Ubuntu 22.04 LTS ou 25.04, vous devez d’abord passer en 24.04 LTS ou 25.10 avant de pouvoir rejoindre la 26.04 LTS. Une tentative de migration directe échoue.

Quatre composants changent par rapport à la 24.04. Trois sont des remplacements introduits dans la version intermédiaire 25.10, le quatrième est une montée de version majeure d’OpenSSH. Aucun ne pose problème sur une installation neuve ; chacun peut surprendre lors d’une migration ou dans un script d’automatisation.

sudo est désormais fourni par sudo-rs

Depuis Ubuntu 25.10, la commande sudo provient du paquet sudo-rs, une réimplémentation en Rust. Le sudo historique de Todd C. Miller reste installé sous le nom sudo.ws, avec ses outils associés suffixés de la même façon (visudo.ws).

Pour un usage courant, le changement est invisible. Quatre différences comptent :

  • L’invite de mot de passe change. sudo.ws affiche [sudo] password for utilisateur, sudo-rs affiche [sudo: authenticate] suivi de la méthode d’authentification. Tout script qui reconnaît l’ancienne invite par expression régulière échoue avec un dépassement de délai.
  • La journalisation des entrées-sorties disparaît. Les programmes sudoreplay, sudo_logsrvd et sudo_sendlog ne sont pas fournis.
  • sudoers.ldap n’existe plus. Le paquet sudo-ldap a été retiré : l’authentification LDAP passe désormais par PAM.
  • La liste des options prises en charge diffère. Consultez sudo-rs --help sur votre système, et man sudoers-rs pour les directives acceptées dans /etc/sudoers.

Pour revenir à l’implémentation historique, si un outil que vous utilisez en dépend :

# Basculer vers le sudo historique
sudo update-alternatives --set sudo /usr/bin/sudo.ws

# Revenir à sudo-rs
sudo update-alternatives --set sudo /usr/lib/cargo/bin/sudo

# Ou choisir interactivement
sudo update-alternatives --config sudo

Canonical déconseille explicitement ce retour en arrière. Ne le faites que si un besoin précis le justifie.

Les coreutils GNU cèdent la place à rust-coreutils

Les utilitaires de base du système — ls, cat, base64 et la plupart des autres — proviennent depuis la 25.10 du paquet rust-coreutils. La compatibilité n’étant pas totale, Canonical a conservé deux garde-fous.

D’abord, cp, mv et rm restent fournis par GNU, à cause de bogues non résolus. Ensuite, les utilitaires GNU classiques restent disponibles, accessibles en préfixant leur nom par gnu :

# Version rust-coreutils (par défaut)
ls -l

# Version GNU équivalente
gnuls -l

Ce point mérite votre attention si vous exécutez des scripts anciens qui s’appuient sur le comportement précis d’une option peu courante. Testez-les avant de mettre la machine en production.

Avertissement — Les deux commandes ci-dessous utilisent --allow-remove-essential, qui autorise APT à retirer un paquet marqué comme essentiel au système. Une erreur de frappe peut rendre la machine inutilisable. Ne les exécutez que sur une machine dont vous avez une sauvegarde ou un instantané.

# Repasser l'ensemble du système aux coreutils GNU
sudo apt install coreutils-from-gnu --allow-remove-essential

# Revenir à rust-coreutils
sudo apt install coreutils-from-uutils --allow-remove-essential

Chrony remplace systemd-timesyncd

Sur une installation neuve en 26.04, la synchronisation horaire est assurée par chrony et non plus par systemd-timesyncd. Chrony utilise par défaut le protocole NTS, qui authentifie et chiffre les échanges, avec les serveurs de temps d’Ubuntu.

Une horloge décalée casse la validation des certificats TLS et fausse tous les horodatages de journaux. Sur un serveur, ce n’est pas un détail.

La bascule n’est pas automatique lors d’une mise à niveau depuis la 24.04. Si vous migrez une machine existante :

# Marquer l'ancien service comme installé automatiquement, puis installer chrony
sudo apt-mark auto systemd-timesyncd
sudo apt install chrony

Les serveurs de temps d’Ubuntu sont définis dans /etc/chrony/sources.d/ubuntu-ntp-pools.sources. Si vous aviez personnalisé /etc/chrony/chrony.conf, vérifiez qu’aucun serveur n’y est déclaré une seconde fois.

OpenSSH passe de la version 9.6 à la version 10.2

L’écart entre les deux versions LTS est important, et deux changements peuvent bloquer une connexion existante.

Changement Conséquence
Algorithme DSA supprimé Une clé DSA ancienne n’est plus acceptée. Les clés hôte DSA ne sont plus générées.
Échange de clés post-quantique mlkem768x25519-sha256 disponible par défaut Un avertissement s’affiche lorsque la négociation n’aboutit pas à un algorithme post-quantique
Nouvelle option PerSourcePenalties Pénalise les adresses clientes qui n’achèvent pas leur authentification
Alias sshd.service ajouté systemctl accepte désormais ssh.service et sshd.service
~/.pam_environment n’est plus lu à la connexion Les variables définies par ce fichier ne s’appliquent plus

Si vous utilisez encore une clé DSA, générez une clé Ed25519 avant de migrer. Le format DSA est considéré comme faible depuis des années.

Prérequis

Élément Minimum Recommandé
Mémoire vive (installation ISO) 1,5 Go 3 Go ou plus
Stockage (installation ISO) 5 Go 25 Go ou plus
Architecture amd64, arm64, armhf, ppc64el, riscv64, s390x —
Clé USB 4 Go —
Réseau Recommandé, pas indispensable à l’installation —

Une précision utile, car les sources de Canonical ne concordent pas entre elles : la page de référence des prérequis annonce ces valeurs pour Ubuntu 24.04 LTS en amd64, en indiquant que les autres versions peuvent différer légèrement. La page de téléchargement de la 26.04 annonce 1,5 Go de RAM et 5 Go d’espace disque, ce qui recoupe le tableau ci-dessus. Le tutoriel d’installation, lui, recommande 2 Go de RAM. Retenez 1,5 Go comme plancher absolu et 3 Go comme cible confortable. Une image cloud, plus légère qu’une installation par ISO, descend à 1 Go de RAM et 4 Go de stockage.

Notez aussi que la liste d’architectures ci-dessus vient de la page de référence ; le tutoriel d’installation n’en cite que quatre (amd64, arm64, ppc64el, s390x). Si vous visez armhf ou riscv64, vérifiez la disponibilité de l’image avant de vous engager.

Vous n’êtes pas obligé de dédier une machine physique. Ubuntu Serveur s’installe très bien dans une machine virtuelle, ce qui reste la meilleure façon de s’entraîner sans risque. Si vous disposez d’un hyperviseur, la procédure d’installation de Proxmox VE et de création de machines virtuelles vous donnera un environnement de test réutilisable.

Schema des 8 etapes pour installer Ubuntu Serveur 26.04 LTS, de la cle USB au pare-feu

 

Étape 1 : télécharger l’image ISO et vérifier son intégrité

Téléchargez l’image depuis la page officielle de téléchargement d’Ubuntu Server, en choisissant l’installation manuelle plutôt que l’assistant automatisé.

Vérifiez ensuite la somme de contrôle. Un téléchargement interrompu produit une image qui échoue en plein milieu de l’installation, parfois après le partitionnement du disque. Récupérez le fichier SHA256SUMS depuis le même répertoire que l’ISO, placez les deux fichiers dans le même dossier, puis :

# LC_ALL=C force la sortie en anglais, --ignore-missing ignore les autres images listées
LC_ALL=C sha256sum --ignore-missing -c SHA256SUMS

Sortie attendue, le nom du fichier variant selon la version téléchargée :

ubuntu-26.04-live-server-amd64.iso: OK

Toute autre réponse que OK signifie que l’image est corrompue. Retéléchargez-la, et ne poursuivez pas.

Étape 2 : créer la clé USB d’installation

Sous Windows, utilisez Rufus ou balenaEtcher, en mode image disque. Sous Linux, la commande dd suffit.

Avertissement — dd écrit directement sur le périphérique indiqué, sans confirmation ni possibilité d’annulation. Une erreur sur la lettre du périphérique efface le disque système ou un disque de données. Identifiez la clé avec lsblk avant de lancer la commande, et vérifiez sa taille pour confirmer qu’il s’agit bien d’elle.

# Identifier le périphérique correspondant à la clé USB
lsblk -o NAME,SIZE,MODEL,MOUNTPOINT
# Écrire l'image sur la clé — remplacez sdX par le périphérique identifié
sudo dd if=ubuntu-26.04-live-server-amd64.iso of=/dev/sdX bs=4M status=progress oflag=sync

dd n’affiche rien tant qu’il n’a pas terminé, hormis la progression. Attendez le retour de l’invite, puis videz le cache d’écriture avant de retirer la clé :

sync

Configurez ensuite le BIOS ou l’UEFI de la machine pour démarrer sur la clé.

Étape 3 : dérouler l’installateur

L’installateur d’Ubuntu Serveur s’appelle Subiquity. Il fonctionne en mode texte : les flèches déplacent la sélection, la barre d’espace coche une case, la touche Entrée valide.

Canonical recommande d’accepter les valeurs par défaut pour une première installation. Les écrans s’enchaînent dans cet ordre :

  1. Langue.
  2. Mise à jour de l’installateur, si elle est proposée. Acceptez : les correctifs de l’installateur sont publiés indépendamment de l’image ISO, celle que vous avez téléchargée peut donc être en retard.
  3. Disposition du clavier.
  4. Réseau. L’installateur tente une configuration automatique par DHCP sur les interfaces filaires. Si elle échoue, vous pouvez continuer sans réseau. Vous passerez en adresse fixe à l’étape suivante.
  5. Proxy et miroir. À laisser tels quels, sauf contrainte propre à votre réseau.
  6. Stockage. Laissez cochée l’option d’utilisation du disque entier, choisissez le disque, validez, puis confirmez.
  7. Profil. Nom d’utilisateur, nom de machine, mot de passe. Le compte créé est ajouté au groupe sudo ; le compte root reste désactivé, avec une empreinte de mot de passe ne correspondant à aucune valeur possible.
  8. SSH. Cochez l’installation du serveur OpenSSH. Sans elle, vous devrez rester physiquement devant la machine pour la configurer. Si vos clés publiques sont déposées sur GitHub ou Launchpad, l’installateur peut les importer.
  9. Snaps. Aucun n’est nécessaire sur un serveur nu. Passez l’écran.
  10. Les journaux d’installation défilent, puis vous redémarrez.

Avertissement — La confirmation de la configuration du stockage efface les données du disque. C’est le dernier point de non-retour. Si la machine contient quoi que ce soit, sauvegardez avant de démarrer sur la clé.

Cette section ne comporte pas de captures. Pour un guide illustré écran par écran, Canonical publie la documentation de l’installateur Subiquity.

Étape 4 : configurer le réseau avec Netplan

Un serveur a besoin d’une adresse IP stable. Ubuntu configure le réseau avec Netplan, dont les fichiers se trouvent dans /etc/netplan/. Le nom du fichier dépend de la méthode d’installation : commencez par lister le répertoire plutôt que de supposer.

ls -l /etc/netplan/

Vous y trouverez typiquement 00-installer-config.yaml après une installation par ISO, ou 50-cloud-init.yaml sur une machine provisionnée par un hébergeur.

C’est ici que la plupart des tutoriels encore en ligne vous feront perdre du temps : ils utilisent la clé gateway4, dépréciée depuis Netplan 0.103. Elle fonctionne encore, mais affiche un avertissement et disparaîtra. La passerelle se déclare désormais comme une route par défaut.

# Syntaxe actuelle — adaptez le nom du fichier et celui de l'interface
network:
  version: 2
  ethernets:
    ens33:
      dhcp4: no
      addresses: [192.168.1.10/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [192.168.1.1, 9.9.9.9]

Remplacez ens33 par le nom réel de votre interface, que ip a vous donnera. À ne plus écrire :

# Syntaxe dépréciée — génère un avertissement
      gateway4: 192.168.1.1

Netplan avertit également lorsque ses fichiers sont lisibles par tous. Restreignez les permissions :

sudo chmod 600 /etc/netplan/*.yaml

Appliquez la configuration en vous laissant une porte de sortie. netplan try restaure automatiquement l’ancienne configuration au bout de 120 secondes par défaut si vous ne confirmez pas, ce qui évite de se couper l’accès à distance. L’option --timeout ajuste ce délai.

# Tester la configuration avec retour arrière automatique
sudo netplan try

Si la connexion tient, confirmez à l’invite : la configuration est alors conservée, sans autre commande à lancer. sudo netplan apply n’est utile que pour appliquer directement une modification, sans filet.

Vérifiez le résultat :

ip -brief address show
ip route show default

Si l’avertissement suivant apparaît, c’est qu’une clé gateway4 subsiste quelque part dans /etc/netplan/ :

`gateway4` has been deprecated, use default routes instead.
See the 'Default routes' section of the documentation for more details.

Étape 5 : mettre à jour et automatiser les correctifs

# Rafraîchir la liste des paquets, puis installer les correctifs
sudo apt update
sudo apt upgrade

Un serveur exposé à Internet doit recevoir les correctifs de sécurité sans attendre votre prochaine connexion :

# Installer et activer les mises à jour de sécurité automatiques
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Vérifiez enfin l’horloge, puisque chrony est désormais le service par défaut :

timedatectl status
chronyc tracking

Étape 6 : déposer votre clé SSH

Cette étape précède le durcissement, et l’ordre n’est pas négociable : couper l’authentification par mot de passe avant d’avoir une clé fonctionnelle vous enferme dehors dès que votre session se termine.

Sur votre poste de travail, pas sur le serveur :

# Générer une paire de clés Ed25519, l'algorithme recommandé par Canonical
ssh-keygen -t ed25519
# Copier la clé publique vers le serveur
ssh-copy-id utilisateur@192.168.1.10

Vérifiez ensuite que la connexion par clé fonctionne, avant toute autre modification :

ssh utilisateur@192.168.1.10

Si la connexion aboutit sans demander votre mot de passe de compte, l’étape est réussie. Sinon, ne passez pas à la suite.

Étape 7 : durcir l’accès SSH

SSH est la porte d’entrée de votre serveur, et la première cible des balayages automatisés. Trois réglages couvrent l’essentiel : authentification par clé, refus du mot de passe, refus de la connexion directe en root.

Un piège documenté par Canonical et ignoré par la plupart des guides : Ubuntu place la ligne Include /etc/ssh/sshd_config.d/*.conf tout en haut de /etc/ssh/sshd_config. Or OpenSSH retient la première valeur rencontrée pour la plupart des directives. Deux conséquences s’enchaînent.

D’abord, une directive placée dans un fichier de /etc/ssh/sshd_config.d/ l’emporte sur celle du fichier principal. Ensuite — et c’est ce que presque tout le monde manque — ces fichiers sont lus dans l’ordre alphabétique : un fichier nommé 99-quelquechose.conf est lu après les autres, donc perd face à un fichier déjà présent comme 50-cloud-init.conf, fréquent sur les VPS.

Commencez donc par regarder ce qui existe déjà :

ls -l /etc/ssh/sshd_config.d/
sudo grep -r "PasswordAuthentication\|PermitRootLogin" /etc/ssh/

Puis écrivez votre configuration dans un fichier au préfixe bas, pour qu’il soit lu en premier :

sudo nano /etc/ssh/sshd_config.d/00-durcissement.conf
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Validez la syntaxe avant de redémarrer le service. Une erreur de configuration empêche sshd de démarrer, et vous enferme dehors si SSH est votre seul accès :

# Contrôler la configuration sans l'appliquer
sudo sshd -t

# Redémarrer seulement si la commande précédente n'affiche rien
sudo systemctl restart ssh.service

Gardez votre session en cours ouverte et testez la connexion depuis un second terminal avant de fermer la première. Le durcissement complet — changement de port, AllowGroups, Fail2ban, double authentification — est traité dans le guide dédié à la configuration et à la sécurisation de SSH sous Linux.

Étape 8 : activer le pare-feu

Ubuntu fournit UFW, une interface simplifiée au-dessus d’iptables, lui-même adossé au sous-système netfilter du noyau. UFW est installé mais inactif par défaut.

Avertissement — Activer UFW sans avoir autorisé SSH au préalable coupe immédiatement votre connexion à distance. Respectez l’ordre des commandes ci-dessous : l’autorisation vient avant l’activation.

# Politique par défaut : tout refuser en entrée, tout autoriser en sortie
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Autoriser SSH AVANT d'activer le pare-feu
sudo ufw allow OpenSSH

# Activer
sudo ufw enable

Le profil OpenSSH est fourni par le paquet openssh-server. Si la commande le refuse, vérifiez les profils disponibles avec sudo ufw app list, ou autorisez le port directement avec sudo ufw allow 22.

Vérifiez les règles actives :

sudo ufw status verbose

N’ouvrez ensuite que les ports réellement nécessaires : sudo ufw allow 80/tcp et sudo ufw allow 443/tcp pour un serveur web, rien de plus. L’option --dry-run affiche les règles qui seraient appliquées sans les appliquer, utile pour vérifier avant d’agir.

Vérifier que tout fonctionne

Une installation n’est terminée que lorsqu’elle est vérifiée. Déroulez ces cinq contrôles :

Contrôle Commande Résultat attendu
Version installée cat /etc/os-release VERSION_ID="26.04"
Service SSH actif systemctl is-active ssh active
Adresse IP correcte ip -brief address show L’adresse fixe configurée
Horloge synchronisée chronyc tracking Un écart de quelques millisecondes
Pare-feu actif sudo ufw status Status: active

Testez enfin la connexion SSH depuis une autre machine, avec votre clé. Tant que ce test n’est pas passé, considérez que le serveur n’est pas prêt.

Faut-il installer une interface graphique sur un serveur ?

Non, dans la quasi-totalité des cas. Un bureau graphique tourne en permanence pour un usage réel de quelques minutes par mois, ajoute des paquets à maintenir et élargit la surface exposée.

Deux exceptions justifient de s’en écarter. Un logiciel métier qui n’existe qu’en version graphique, sans équivalent en ligne de commande. Et l’apprentissage : si la console vous bloque au point de renoncer, mieux vaut une interface graphique qu’un serveur abandonné.

Dans ces deux cas, une interface d’administration web ou une session graphique distante ponctuelle reste préférable à un environnement de bureau complet démarré à chaque redémarrage.

Revenir en arrière

Chaque étape de ce guide est réversible.

# Désactiver le pare-feu
sudo ufw disable

# Annuler le durcissement SSH
sudo rm /etc/ssh/sshd_config.d/00-durcissement.conf
sudo sshd -t && sudo systemctl restart ssh.service

# Revenir au sudo historique
sudo update-alternatives --set sudo /usr/bin/sudo.ws

Pour le réseau, sudo netplan try restaure seul la configuration précédente si vous ne confirmez pas. Conservez malgré tout une copie de votre fichier avant modification, hors de /etc/netplan/ : Netplan analyse tout ce qu’il trouve dans ce répertoire, et un fichier de sauvegarde y génère des avertissements.

# Remplacez le nom du fichier par celui que ls -l /etc/netplan/ vous a donné
sudo cp /etc/netplan/00-installer-config.yaml /root/netplan-avant-modif.yaml

Sur une machine de production, prenez un instantané complet avant toute intervention. Les sauvegardes automatisées avec rsync et crontab couvrent le besoin récurrent, pas la sauvegarde ponctuelle avant manipulation.

Erreurs courantes

Le durcissement SSH reste sans effet. Votre directive est écrasée par un fichier lu avant le vôtre dans /etc/ssh/sshd_config.d/. Recherchez-la dans tout le répertoire avec sudo grep -r PasswordAuthentication /etc/ssh/, puis renommez votre fichier avec un préfixe numérique plus bas que celui qui gagne.

La connexion SSH est refusée après migration. Votre clé est probablement au format DSA, supprimé dans OpenSSH 10. Générez une clé Ed25519 et déposez-la comme indiqué à l’étape 6.

sshd refuse de démarrer après modification. Une directive est mal orthographiée. sudo sshd -t affiche le fichier et la ligne fautifs. Si vous êtes déjà déconnecté, il faudra passer par la console physique ou la console de secours de votre hébergeur.

Un script d’automatisation dépasse son délai d’attente sur sudo. Il attend l’ancienne invite [sudo] password for, alors que sudo-rs affiche [sudo: authenticate]. Adaptez le motif recherché, ou passez --prompt "" pour supprimer l’invite du filtrage.

Questions fréquentes

Le serveur Ubuntu est-il facile à installer ?
Oui, à condition d’accepter un installateur en mode texte. Il pose une dizaine de questions et ne demande aucune connaissance particulière. La difficulté ne vient pas de l’installation mais de ce qui suit : réseau fixe, clés SSH, pare-feu, sauvegardes.

Peut-on installer Ubuntu Serveur dans une machine virtuelle ?
Oui, c’est même la méthode recommandée pour apprendre. VirtualBox, VMware, KVM et Proxmox VE l’acceptent sans configuration particulière. Prévoyez 3 Go de RAM et 25 Go de disque pour rester dans les valeurs recommandées par Canonical.

Debian ou Ubuntu pour un serveur ?
Debian publie moins souvent et n’embarque que du logiciel libre ; Ubuntu suit un calendrier fixe, propose des versions LTS datées et un support commercial. Pour un serveur autonome dont vous maîtrisez le rythme de mise à jour, les deux conviennent. Notre comparatif des distributions Linux détaille les critères.

Quels sont les inconvénients d’Ubuntu Serveur ?
Trois, à connaître avant de choisir. Le cycle de mise à niveau impose de migrer tous les cinq ans, sans saut de version possible. Certaines décisions de Canonical, comme la généralisation des paquets Snap, ne font pas l’unanimité. Enfin, une partie de la documentation francophone en ligne est périmée, ce qui expose aux commandes dépréciées.

Conclusion

Installez la 26.04 LTS pour toute nouvelle machine, et laissez en place les parcs 24.04 encore supportés. Le point de vigilance de cette version n’est pas l’installation, qui n’a pas changé, mais les quatre composants modifiés : sudo-rs, rust-coreutils, chrony et OpenSSH 10.2. Sur une machine neuve, ils sont transparents. Sur une migration, ce sont eux qui casseront vos scripts.

Le réflexe à conserver : vérifier une configuration avant de l’appliquer, sudo sshd -t pour SSH et sudo netplan try pour le réseau. Ces deux commandes évitent l’essentiel des situations où l’on se retrouve verrouillé hors de sa propre machine.

Votre serveur est prêt à recevoir un service. La suite logique est l’installation de Docker pour isoler vos applications, puis la mise en place d’une politique de sauvegarde adaptée à ce que vous allez y héberger.

Sources officielles

Vincent

Vincent est le créateur de MémoLinux. Venu de Windows par curiosité, il est resté sur Linux pour sa logique et le plaisir de comprendre ce qui se passe sous le capot. Il documente ici les commandes et les procédures qu’il utilise lui-même, avec leurs sources officielles et leur date de vérification.

Laisser un commentaire