Architecture, sécurité et commandes de base

Deux machines, deux responsabilités

[LOCAL: WSL2]                                    [REMOTE: VPS]
Lance SSH                                        Exécute sshd
Conserve la clé privée utilisateur               Conserve authorized_keys
Teste les adresses publiques et Tailscale        Configure le système, UFW et Docker
Ne pas y appliquer les changements du serveur    Ne pas dépendre d’un état local implicite

Dans vos notes d’administration, indiquez sur quelle machine exécuter chaque bloc de commandes. Vérifiez hostname, whoami et l’adresse IP avant de vous fier à l’invite ; le titre de la fenêtre ne suffit pas.

Les étapes d’une connexion SSH

Quand vous lancez ssh user@host depuis WSL2, la connexion doit franchir au moins ces étapes, dans cet ordre :

1. La machine locale peut acheminer les paquets vers l’adresse de destination.
2. Le pare-feu de destination autorise l’accès au port TCP 22.
3. sshd écoute et répond.
4. La clé d’hôte SSH correspond à celle qu’attend le client.
5. Le serveur accepte la clé publique de l’utilisateur et le client peut signer avec la clé privée correspondante.
6. Ce compte Linux est autorisé à ouvrir un shell.

Un ping réussi ne valide donc qu’une partie du chemin réseau ; il ne garantit pas que SSH fonctionne. De même, une ancienne session SSH encore ouverte ne prouve pas que le pare-feu autorise de nouvelles connexions.

Pour un site ou une API, le parcours d’une requête fournit les vérifications correspondantes pour DNS, la connexion, TLS et HTTP.

Vérifier l’identité sans rien modifier

[LOCAL: WSL2]

whoami
hostname
uname -a
command -v ssh
ssh -V
ssh-keygen -lf "$LOCAL_SSH_PUBLIC_KEY"

[REMOTE: VPS]

whoami
id
hostnamectl
cat /etc/os-release
uname -a
nproc
free -h
df -h /
ip -brief addr
ip route
systemctl --failed --no-pager

Ces commandes permettent d’identifier l’utilisateur et la machine, le système utilisé, les ressources disponibles, les interfaces réseau et les services éventuellement en échec. Ne poursuivez que si les caractéristiques concordent avec celles de la console du fournisseur.

Préparer une modification

1. Examiner l’état actuel : l’outil, le fichier, la règle ou l’utilisateur existe peut-être déjà.
2. Définir l’état souhaité : par exemple, « seul tailscale0 permet d’accéder au port 22 », plutôt que « exécuter telle commande ».
3. Préparer la vérification : qu’est-ce qui montrera que la modification fonctionne ? Quel accès conserver en cas d’échec ?
4. Procéder par petites étapes : ajouter le chemin de remplacement avant de retirer l’ancien.
5. Retester avec une nouvelle session côté client : le suivi des connexions et les caches peuvent donner une fausse impression de réussite.

Une opération est idempotente si la répéter ne crée pas de configuration en double. mkdir -p, une vérification avant l’ajout d’une règle et un fragment de configuration dédié sont plus faciles à maintenir que le remplacement aveugle d’un fichier entier.

Nom d’hôte, fuseau horaire et paquets

[REMOTE: VPS]

sudo hostnamectl set-hostname infra-01
sudo timedatectl set-timezone America/Toronto
sudo apt update
sudo apt-get -s dist-upgrade
# Examiner les suppressions et changements de services avant la mise à niveau.
sudo apt full-upgrade
sudo apt install -y git curl ca-certificates jq ufw

• apt update actualise l’index des versions disponibles ; il n’installe pas les mises à jour.
• Le manuel d’apt-get décrit -s comme une simulation et précise que dist-upgrade peut supprimer des paquets pour résoudre les dépendances. Examinez d’abord la simulation, puis lancez apt full-upgrade et lisez le résumé réel des installations et suppressions avant de confirmer.
• Pour cette première mise à niveau manuelle, n’ajoutez ni -y ni configuration forcée en mode non interactif. Le plan peut changer entre la simulation et l’exécution ; conservez donc la demande de confirmation.
• Vérifiez ensuite si /var/run/reboot-required existe. Sa présence indique qu’un redémarrage est nécessaire pour que le nouveau noyau ou un composant essentiel prenne pleinement effet.

Ubuntu distribue les mises à jour ordinaires par vagues, selon un mécanisme appelé « phased updates ». Un paquet différé de cette manière n’a pas échoué à l’installation ; les mises à jour de sécurité ne suivent pas ce déploiement progressif. Cherchez d’abord la cause ; ne contournez pas la politique de diffusion simplement pour faire disparaître tous les messages de mises à jour en attente.

Quand s’arrêter

• L’identité ou les caractéristiques de la machine, la version du système ou l’adresse IP diffèrent nettement de ce qui était prévu.
• Continuer exigerait d’afficher ou d’exposer autrement une clé privée, un mot de passe ou un jeton.
• Le gestionnaire de paquets prévoit de supprimer des paquets système essentiels.
• La vérification par une nouvelle connexion SSH échoue.
• Le sens d’une règle de pare-feu est incertain.
• Le disque ou l’infrastructure existante entre en conflit avec le plan.

S’arrêter n’est pas un échec : cela protège un état récupérable, ce qui importe davantage que terminer une liste de vérifications. Sur une machine distante, l’erreur la plus coûteuse est souvent une commande qui « réussit », puis vous empêche de vous reconnecter.

Mes lectures