Configurer un VPS Ubuntu pour publier un site en HTTPS

Préparer le serveur, le domaine et un accès de secours

Prévoyez une instance neuve, une IPv4 publique, SSH sur le port 22, un compte initial autorisé à utiliser sudo et un domaine que vous contrôlez. Ouvrez la console de récupération avant toute modification d’accès ou de pare-feu.

Les commandes locales s’exécutent dans Bash sous Linux, macOS ou WSL ; les commandes serveur s’exécutent après connexion SSH. Remplacez partout 203.0.113.10, app.example.com et, si nécessaire, l’utilisateur initial ubuntu. L’adresse et le domaine sont des exemples documentaires.

Arrêtez-vous si les chemins first-site ou le compte deploy appartiennent à une installation existante. Les images Oracle Ubuntu demandent la branche pare-feu spécifique indiquée plus loin.

Créer une clé avant la VM ou utiliser un accès existant

Sur votre ordinateur, choisissez un nom de clé inutilisé et une phrase secrète. Le fichier privé reste local ; seule la partie .pub se partage.

mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pub

Pour un nouveau VPS, fournissez la clé publique à la création de l’instance Ubuntu puis passez au contrôle d’empreinte. Les deux blocs suivants concernent uniquement un serveur vide déjà créé et accessible.

Pour ce serveur déjà créé, gardez la session qui fonctionne. Depuis un autre terminal local, copiez la nouvelle clé publique avec les identifiants actuels. Remplacez existing_vps_key par votre clé existante ; si l’accès établi utilise un agent ou un mot de passe, omettez cette option -i sans modifier la politique du serveur.

scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

Dans la session distante existante, validez la clé et ajoutez-la aux clés du compte initial. Cette opération conserve les entrées déjà présentes. Sans accès fonctionnel, utilisez d’abord la récupération du fournisseur.

if ssh-keygen -lf ~/ubuntu-vps-admin.pub; then
    mkdir -p ~/.ssh
    chmod 700 ~/.ssh
    printf '\n' >> ~/.ssh/authorized_keys
    cat ~/ubuntu-vps-admin.pub >> ~/.ssh/authorized_keys
    chmod 600 ~/.ssh/authorized_keys
fi

Pour les deux parcours, comparez l’empreinte proposée à celle du même type de clé lue dans la console de récupération fiable. Pour Ed25519, exécutez dans cette console :

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Depuis votre ordinateur, ouvrez ensuite une nouvelle connexion avec la clé préparée. Gardez le premier accès disponible.

ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Depuis un autre terminal local, copiez la clé publique nécessaire au futur administrateur. Cette nouvelle copie est sans conséquence si le parcours précédent avait déjà transmis ce fichier temporaire.

scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

Créer un administrateur et tester sa session

Sur le serveur, vérifiez d’abord getent passwd deploy. Aucun compte ne doit être renvoyé. Si deploy existe, choisissez un autre nom inutilisé et adaptez aussi les groupes et chemins de son répertoire personnel : ne remplacez pas ses clés.

Contrôlez le système, examinez les mises à jour puis créez le compte. Choisissez un mot de passe solide pour ses demandes sudo. Les permissions ci-dessous limitent l’accès au fichier de clé.

cat /etc/os-release
free -h
df -h /
sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy ~/ubuntu-vps-admin.pub /home/deploy/.ssh/authorized_keys

Ouvrez un nouveau terminal local et connectez-vous avec ce compte :

ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10

Dans cette nouvelle session distante, sudo doit afficher root après acceptation du mot de passe. Continuez ici lorsque les deux tests passent, en conservant l’ancien accès.

sudo whoami

Installer Nginx et choisir la bonne branche de pare-feu

Dans la session du nouvel administrateur, installez et activez Nginx :

sudo apt install nginx
sudo systemctl enable --now nginx

Dans le pare-feu du fournisseur, autorisez TCP 22 depuis votre emplacement d’administration et TCP 80/443 pour les visiteurs. Si SSH utilise un autre port, préservez-le. Le pare-feu réseau et celui d’Ubuntu peuvent tous deux bloquer une connexion.

Images Ubuntu Oracle Cloud : sautez tout le bloc UFW suivant. Préservez les règles iptables livrées avec l’image, notamment celles des volumes iSCSI. Configurez les listes OCI ou NSG et les règles invitées documentées pour HTTP/HTTPS. Ne videz pas iptables et ne remplacez pas les paquets de pare-feu pour contourner un problème.

Autres images Ubuntu neuves compatibles UFW : appliquez ce bloc uniquement lorsque le fournisseur accepte UFW et n’impose pas un autre mécanisme. Autorisez le véritable port SSH avant l’activation ; l’exemple suppose 22.

sudo apt install ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Après l’une ou l’autre branche, testez une nouvelle connexion SSH. Une session déjà ouverte ne valide pas les nouvelles règles. Gardez la console disponible pendant le diagnostic.

Publier une page dans sa propre configuration Nginx

Sur le serveur, vérifiez que /var/www/first-site, la configuration first-site et son lien dans sites-enabled ne sont pas déjà utilisés. Remplacez le domaine à l’intérieur du bloc. Conservez les délimiteurs EOF entre apostrophes pour que le shell ne développe pas la variable Nginx $uri.

sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="fr"><title>Premier déploiement</title><h1>Cette page est servie par un VPS Ubuntu</h1></html>' | sudo tee /var/www/first-site/index.html
sudo tee /etc/nginx/sites-available/first-site >/dev/null <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;
    root /var/www/first-site;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
sudo ln -s /etc/nginx/sites-available/first-site /etc/nginx/sites-enabled/first-site
sudo nginx -t

Rechargez le service uniquement si nginx -t réussit. En cas d’erreur, corrigez le fichier sans abandonner la configuration qui fonctionne.

sudo systemctl reload nginx

Depuis votre ordinateur, testez le nom d’hôte directement contre l’IP avant de changer le DNS. La page doit présenter votre titre, pas l’accueil Nginx par défaut.

curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/

Raccorder le DNS et obtenir le certificat HTTPS

Créez un enregistrement A pour le domaine vers l’IPv4 du VPS. Publiez un AAAA seulement si IPv6 fonctionne jusqu’au service. L’exemple suppose une résolution directe vers la VM, sans proxy.

Depuis votre ordinateur, ouvrez http://app.example.com/ avec votre véritable domaine, sans --resolve. Continuez lorsque la bonne page apparaît. Sur le serveur, les paquets Certbot et le module Nginx proviennent ici des dépôts Ubuntu et nécessitent Universe ; résolvez une erreur de paquet absent avant de poursuivre.

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect
sudo nginx -t
sudo certbot renew --dry-run
systemctl list-timers --all certbot.timer

Suivez les demandes d’adresse e-mail et d’acceptation des conditions. Certbot adapte la configuration et la redirection vers HTTPS. Vérifiez que le timer est planifié ; s’il est inactif, activez-le avec sudo systemctl enable --now certbot.timer. Gardez le port 80 accessible pour la validation HTTP et les renouvellements.

Contrôler depuis l’extérieur puis après redémarrage

Sur votre ordinateur, contrôlez redirection, certificat et contenu. N’ajoutez pas -k à curl : cette option masquerait une erreur de validation du certificat.

curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/

Tant que le déploiement reste un test, exécutez sudo reboot sur le serveur. Cela coupe volontairement les sessions SSH. Reconnectez-vous comme deploy, vérifiez systemctl is-active nginx et refaites la requête HTTPS externe. Utilisez la console si la machine ne revient pas.

Diagnostiquer les échecs et conserver une copie

Faites défiler le tableau pour voir toutes les colonnes →

Le diagnostic SSH sépare réseau, service, clé et identité. Conservez fichiers, configuration Nginx, DNS et procédure de reconstruction hors du VPS. Si vous sauvegardez des clés privées TLS, protégez leur stockage.

L’exercice de restauration vérifie une copie de fichiers sans écraser le site. La récupération complète exige aussi les autres fichiers, certificats et réglages nécessaires. Ajoutez des alertes de disponibilité et d’expiration de certificat.

Ce parcours sert des fichiers statiques. Une base de données ou une application ajoute sa configuration de service et ses propres sauvegardes. Utilisez la méthode de mesure avant d’élargir le budget.

Questions et réponses