Linux pour ingénieurs blockchain

Une question de départ

Vous louez un petit serveur chez un hébergeur. Quelques minutes après sa mise en ligne, les journaux montrent des dizaines de tentatives de connexion venues du monde entier. Personne ne vous « vise » : des programmes essaient en continu des mots de passe sur toute adresse qui répond sur le port 22. Un mot de passe, même long, est une cible permanente. Une clé résout le problème, mais seulement si on l'utilise correctement.

Ce que fait SSH

SSH (Secure Shell) ouvre un terminal chiffré sur une machine distante. Il utilise le port TCP 22 par défaut (atelier 101). Il fait deux choses distinctes :

1. Authentifier le serveur auprès de vous (pour que vous ne parliez pas à un imposteur).
2. Authentifier l'utilisateur auprès du serveur.

Authentification par clé : l'idée

Une paire de clés comprend une clé privée, secrète, qui produit des signatures, et une clé publique que n'importe qui peut utiliser pour vérifier ces signatures (principe détaillé à l'atelier 105). Pour SSH :

• Sur votre poste, vous créez une paire : ssh-keygen -t ed25519 -C "mon-portable". Le fichier ~/.ssh/id_ed25519 est la clé privée ; ~/.ssh/id_ed25519.pub est la clé publique.
• Vous copiez la clé publique dans ~/.ssh/authorized_keys sur le serveur (la commande ssh-copy-id utilisateur@serveur le fait).
• À la connexion, votre client signe avec la clé privée des données liées à cette session (c'est une simplification : il n'y a pas de défi aléatoire séparé) ; le serveur vérifie la signature avec la clé publique. La clé privée ne quitte jamais votre poste et n'est jamais envoyée au serveur.

Protégez le fichier privé par une phrase de passe : s'il est volé, il reste chiffré.

Première connexion : l'empreinte du serveur

La première fois, le client affiche :

The authenticity of host 'srv.example.test (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789FICTIF.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

(L'adresse 203.0.113.10 et l'empreinte sont des exemples fictifs ; la plage 203.0.113.0/24 est réservée à la documentation.) Comparez l'empreinte avec celle que l'hébergeur affiche dans sa console. Si vous répondez « yes » sans comparer, vous acceptez peut-être un imposteur. Une fois acceptée, l'empreinte est mémorisée dans ~/.ssh/known_hosts. Si elle change plus tard, SSH affiche un grand avertissement (« REMOTE HOST IDENTIFICATION HAS CHANGED ») : ne l'ignorez pas, enquêtez (réinstallation légitime ou interception).

Permissions : sans elles, SSH refuse

SSH refuse une clé privée lisible par d'autres. Règles usuelles :

Le message « Permissions 0644 for 'id_ed25519' are too open. UNPROTECTED PRIVATE KEY FILE! » vous dit exactement cela. Correction : chmod 600 ~/.ssh/id_ed25519.

Fermer l'accès par mot de passe — sans s'enfermer dehors

Le fichier /etc/ssh/sshd_config configure le serveur SSH. Les réglages utiles :

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

(KbdInteractiveAuthentication no ferme une autre voie par laquelle un mot de passe peut encore être demandé sur certaines images de serveur ; selon la version d'OpenSSH, ce mot-clé peut s'appeler ChallengeResponseAuthentication.)

Procédure sûre, dans l'ordre :

1. Gardez une seconde session ouverte (ne fermez jamais votre seule connexion).
2. Vérifiez qu'une clé fonctionne : ouvrez une nouvelle connexion avec la clé.
3. Modifiez la configuration, puis testez sa syntaxe : sudo sshd -t (aucune sortie = syntaxe correcte).
4. Rechargez le service (sudo systemctl reload ssh sur Ubuntu ; le nom du service est sshd sur d'autres distributions). Un changement de port peut demander un redémarrage plutôt qu'un rechargement, surtout si le service est lancé par un socket systemd : vérifiez avec ss -tlnp.
5. Depuis un troisième terminal, vérifiez que la connexion par clé marche encore et qu'une tentative par mot de passe est refusée.

Ce que cela ne garantit PAS

• Une clé protège la connexion, pas la machine : si votre portable est compromis, la clé l'est aussi. D'où la phrase de passe et une clé par appareil.
• Désactiver le mot de passe n'empêche pas les tentatives, seulement leur succès. Changer de port peut réduire le bruit des journaux, ce n'est pas une protection.
• Un compte sans mot de passe peut encore être attaqué par d'autres services ouverts : fermer SSH n'est pas fermer le serveur.

À retenir

Créez une paire de clés, déposez la publique, comparez l'empreinte à la première connexion, mettez les bonnes permissions, puis désactivez mot de passe et root distant — en gardant une session ouverte et en vérifiant la valeur effective.

Le problème

Un développeur lance son nœud avec sudo « pour que ça marche ». Le nœud tourne donc en root. Une faille dans le programme donne alors à l'attaquant la machine entière. Le principe du moindre privilège : chaque programme tourne avec un compte qui ne peut faire que son travail.

Comptes : un humain, un service

• Un compte d'administration pour vous (non root) : sudo adduser deploy puis sudo usermod -aG sudo deploy (sur Ubuntu, le groupe sudo autorise sudo). Vous vous connectez avec ce compte et élevez vos droits seulement quand il le faut.
• Un compte de service pour le nœud : sudo useradd --system --no-create-home --shell /usr/sbin/nologin nodeuser. Personne ne s'y connecte ; il possède seulement le dossier de données du nœud.

Lire les permissions

$ ls -l /var/lib/mynode
drwxr-x--- 4 nodeuser nodeuser 4096 Mar  4 10:12 chain
-rw------- 1 nodeuser nodeuser   64 Mar  4 10:12 node.key
-rw-r--r-- 1 root     root      210 Mar  4 09:58 README.txt

Chaque ligne commence par dix caractères : le type (d dossier, - fichier) puis trois groupes de trois droits pour le propriétaire, le groupe, les autres. Chaque groupe vaut : lecture r = 4, écriture w = 2, exécution x = 1. On additionne.

• rwx = 4 + 2 + 1 = 7 ; r-x = 4 + 0 + 1 = 5 ; r-- = 4 ; rw- = 6 ; --- = 0.
• drwxr-x--- → dossier, 7 5 0 → 750.
• -rw------- → 6 0 0 → 600 : seul le propriétaire lit et écrit. C'est le mode attendu pour une clé.
• -rw-r--r-- → 6 4 4 → 644 : lisible par tous.

Pour un dossier, x signifie « pouvoir y entrer » : sans lui on ne traverse pas le dossier, même avec r.

Commandes : chmod 600 fichier, chmod 750 dossier, sudo chown -R nodeuser:nodeuser /var/lib/mynode.

Pare-feu avec ufw

Un pare-feu filtre les connexions entrantes. Sur Ubuntu, ufw (Uncomplicated Firewall) est une interface simple au pare-feu du noyau. Règle de départ : tout refuser en entrée, ouvrir seulement ce qui est nécessaire.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH          # ou: sudo ufw allow 22/tcp
sudo ufw allow 30333/tcp        # port p2p du nœud (exemple; voir la doc du client)
sudo ufw enable
sudo ufw status verbose

L'ordre compte : si vous activez ufw avant d'avoir autorisé SSH, vous vous coupez du serveur. Le port 30333 est un exemple ; chaque logiciel de nœud documente ses ports.

RPC : lier à localhost

Un nœud de chaîne expose souvent une interface RPC (une API que les applications appellent à distance). Si elle écoute sur 0.0.0.0, elle répond sur toutes les interfaces, donc depuis Internet. Si elle écoute sur 127.0.0.1, seul le serveur lui-même peut l'appeler. Vérifiez avec ss -tlnp :

State  Recv-Q Send-Q  Local Address:Port  Peer Address:Port Process
LISTEN 0      4096        127.0.0.1:8545       0.0.0.0:*    users:(("mynode",pid=812,fd=20))
LISTEN 0      128           0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=701,fd=3))

Ici le RPC (port d'exemple 8545) n'est accessible que localement ; SSH est ouvert à tous. Attention : une adresse IPv6 comme [::] (« toutes les interfaces » en IPv6) expose le service de la même façon que 0.0.0.0. Pour exposer un RPC au public, placez devant un proxy inverse (reverse proxy) avec limitation de débit, jamais le nœud brut.

Exemple chiffré : un diagnostic de permissions

Le nœud (compte nodeuser) échoue avec « Permission denied » sur /var/lib/mynode/node.key, dont le mode est -rw------- et le propriétaire root. Raisonnement : le propriétaire (root) a 6, le groupe 0, les autres 0 ; nodeuser n'est ni propriétaire ni dans le groupe : il n'a aucun droit. Correction : sudo chown nodeuser:nodeuser /var/lib/mynode/node.key (garder 600). Pas de chmod 777.

Ce que cela ne garantit PAS

• Un pare-feu local ne protège pas de ce qui est déjà autorisé : un service ouvert vulnérable reste vulnérable.
• Les droits Unix limitent les comptes ordinaires, mais pas root : un attaquant qui obtient root contourne tout.
• Un pare-feu du système et le pare-feu de l'hébergeur sont deux niveaux distincts : une règle dans l'un n'ouvre pas ce que l'autre bloque.
• Un port publié par Docker peut contourner les règles ufw (vous le verrez à l'atelier 117) : ne vous fiez pas à ufw status seul, vérifiez avec ss -tlnp et depuis l'extérieur.

À retenir

Un compte par rôle, des droits minimaux (600 pour un secret, 750 pour un dossier de service), un pare-feu qui refuse par défaut, et des interfaces RPC liées à localhost.

Le problème

Vous lancez votre nœud dans un terminal. Vous fermez le terminal : le nœud s'arrête. Le serveur redémarre après une coupure de courant : le nœud ne revient pas. Un programme sérieux doit être un service : démarré au boot, redémarré en cas de plantage, avec ses messages conservés.

systemd en deux mots

systemd est le gestionnaire de services de la plupart des distributions modernes, dont Ubuntu. Un service se décrit dans un fichier d'unité (.service), placé dans /etc/systemd/system/.

[Unit]
Description=Example chain node (training)
After=network-online.target
Wants=network-online.target

[Service]
User=nodeuser
EnvironmentFile=/etc/mynode/env
ExecStart=/usr/local/bin/mynode --data-dir /var/lib/mynode --rpc-bind 127.0.0.1
Restart=on-failure
RestartSec=5
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

• User : le compte de service (moindre privilège).
• ExecStart : la commande, de préférence avec un chemin absolu. systemd refuse un chemin relatif comme ./mynode ; un simple nom sans / est cherché dans quelques répertoires fixes, ce qui dépend de l'installation : le chemin absolu évite toute ambiguïté.
• Restart=on-failure + RestartSec=5 : redémarrage 5 s après un plantage.
• WantedBy=multi-user.target : démarré au boot normal une fois activé.
• EnvironmentFile : un fichier de variables, qu'on met en mode 600 propriétaire root s'il contient des secrets. Évitez d'écrire un secret directement dans le fichier d'unité, lisible par tous les comptes.

Les commandes

sudo systemctl daemon-reload          # relire les fichiers d'unité après modification
sudo systemctl enable --now mynode    # démarrer au boot ET maintenant
sudo systemctl status mynode          # état, derniers messages
sudo systemctl restart mynode
sudo systemctl stop mynode

Après chaque modification d'un fichier d'unité, daemon-reload est nécessaire : sans lui, systemd garde l'ancienne version en mémoire.

Un status ressemble à ceci :

● mynode.service - Example chain node (training)
     Loaded: loaded (/etc/systemd/system/mynode.service; enabled; preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Wed 2026-03-04 10:31:02 UTC; 3s ago
    Process: 2345 ExecStart=/usr/local/bin/mynode ... (code=exited, status=1/FAILURE)
   Main PID: 2345 (code=exited, status=1/FAILURE)

« activating (auto-restart) » avec « exited, status=1/FAILURE » signifie : le programme plante en boucle, systemd le relance toutes les cinq secondes. Le redémarrage automatique cache le problème : il faut lire les journaux.

Les journaux avec journalctl

systemd regroupe les messages de tous les services dans le journal.

journalctl -u mynode -n 50            # 50 dernières lignes de ce service
journalctl -u mynode -f               # suivre en direct
journalctl -u mynode --since "1 hour ago"
journalctl -u mynode -p err           # seulement les erreurs

Exemple de sortie :

Mar 04 10:31:02 srv mynode[2345]: ERROR: cannot open /var/lib/mynode/node.key: Permission denied
Mar 04 10:31:02 srv systemd[1]: mynode.service: Main process exited, code=exited, status=1/FAILURE

Elle explique tout : c'est la fin du diagnostic de la leçon précédente (propriétaire du fichier).

Journaux et disque : la rotation

Des journaux qui grossissent sans limite finissent par remplir le disque (voir leçon 4). Deux outils :

• journald (journal de systemd) plafonne déjà sa taille par défaut (une fraction du système de fichiers, limitée à quelques Go selon sa documentation, journald.conf). journalctl --disk-usage affiche l'espace pris ; sudo journalctl --vacuum-size=500M supprime les plus anciens jusqu'à 500 Mo ; et pour une limite permanente et prévisible, SystemMaxUse=500M dans /etc/systemd/journald.conf (puis redémarrage de systemd-journald). Cette limite borne tout le journal, toutes unités confondues, pas un seul service.
• logrotate : pour les fichiers de journaux écrits par un programme lui-même (par exemple /var/log/mynode/*.log), là où la croissance sans limite est le vrai risque. Une configuration dans /etc/logrotate.d/ dit combien de fichiers garder, s'il faut compresser et à quelle fréquence tourner :

# /etc/logrotate.d/mynode (exemple)
/var/log/mynode/*.log {
    daily
    rotate 7
    compress
    missingok
    copytruncate
}

(copytruncate copie puis vide le fichier : pratique si le programme garde le fichier ouvert, au prix d'un risque de perdre quelques lignes écrites pendant la copie.)

Exemple chiffré

Un nœud écrit 40 Mo de messages par jour dans un fichier /var/log/mynode/node.log qu'il gère lui-même. Sans rotation, un an représente 40 × 365 = 14 600 Mo, soit environ 14,6 Go : cela ne tombe pas en panne le premier mois, mais finit par se remarquer. Avec la configuration logrotate ci-dessus (rotate 7 : sept fichiers gardés, en gros une semaine d'historique), le volume reste de l'ordre de quelques centaines de Mo, compression comprise. Côté journald, SystemMaxUse=500M garantit que le journal de tout le système ne dépasse pas 500 Mo : on perd les plus anciens messages, on garde le disque. Si vous avez besoin d'un historique plus long, exportez les journaux vers un autre système plutôt que de les empiler sur le disque du nœud.

Ce que cela ne garantit PAS

• Restart=on-failure ne répare rien : un nœud qui plante à chaque démarrage boucle indéfiniment. Surveillez ; limitez avec les réglages de démarrage de systemd si besoin.
• Restart=on-failure ne relance pas après un arrêt considéré comme normal : selon la documentation de systemd, un arrêt par SIGTERM (ce que fait un simple kill) compte comme une sortie propre. Pour simuler un plantage, utilisez sudo kill -9 <PID> (SIGKILL).
• enable ne démarre pas tout de suite (sans --now) ; start n'active pas au boot. Ce sont deux choses.
• Un journal n'est pas une sauvegarde : si la machine meurt, il disparaît avec elle.

À retenir

Un fichier d'unité avec utilisateur de service et chemin absolu, daemon-reload après chaque modification, journalctl -u pour comprendre, et une limite de taille sur les journaux.

Le problème

À 3 h du matin, votre nœud s'arrête. Trois causes ordinaires : disque plein, mémoire épuisée, port déjà pris. Il faut les reconnaître en une minute dans la sortie d'une commande. La méthode : observer, formuler une hypothèse, confirmer par une seconde commande, et seulement ensuite agir.

1. Disque

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       200G  188G  2.2G  99% /
tmpfs           3.9G     0  3.9G   0% /dev/shm

df -h montre l'occupation des systèmes de fichiers. Ici la racine est à 99 %. Remarquez que Size − Used (12 Go) ne vaut pas Avail (2,2 Go) : sur le système de fichiers ext4, une partie (5 % par défaut, soit environ 10 Go ici) est réservée à root. C'est normal.

Pour trouver ce qui occupe la place :

$ sudo du -xh --max-depth=1 /var | sort -h | tail -4
1.4G    /var/cache
12G     /var/log
171G    /var/lib
185G    /var

(-x reste sur un seul système de fichiers.) Les données de chaîne (/var/lib) pèsent 171 Go, les journaux 12 Go. Deux leviers : limiter les journaux (leçon 3), et surtout prévoir un volume de données plus grand (les données d'un nœud de chaîne croissent sans cesse).

Deux variantes à connaître :

• Inodes épuisés : df -i. Un disque peut être « plein » en nombre de fichiers alors qu'il reste de la place en octets (des millions de petits fichiers).
• Fichier supprimé mais encore ouvert : df montre beaucoup d'espace utilisé, mais du ne retrouve pas les fichiers. Un processus tient encore un fichier supprimé ; sudo lsof +L1 le liste. L'espace revient à l'arrêt du processus.

2. Mémoire

$ free -m
               total        used        free      shared  buff/cache   available
Mem:            3913        3611         101          12         189         120
Swap:              0           0           0

Lisez la colonne available (mémoire que le système peut donner à un programme sans recourir au swap), pas free. Linux utilise la mémoire libre pour son cache : un free bas est normal. Ici available = 120 Mo sur 3 913 Mo et pas de swap : le système est en danger.

Quand la mémoire manque, le noyau peut déclencher l'OOM killer, qui tue un processus. Sa trace est dans le journal du noyau :

$ journalctl -k | grep -i "out of memory"
Mar 04 03:12:44 srv kernel: Out of memory: Killed process 812 (mynode) total-vm:6120344kB, anon-rss:3402112kB

C'est la preuve : le nœud n'a pas « planté seul », il a été tué faute de mémoire. Remèdes : une machine avec plus de mémoire, une configuration de cache moins gourmande (selon le logiciel), ou un autre service qui consomme moins. Le swap peut amortir, mais un nœud sur disque lent qui swappe devient très lent.

3. Ports

Un programme ne peut pas écouter sur un port déjà utilisé :

mynode: ERROR: failed to bind 0.0.0.0:30333: Address already in use (os error 98)

Qui l'utilise ?

$ sudo ss -tlnp | grep :30333
LISTEN 0 128 0.0.0.0:30333 0.0.0.0:* users:(("mynode",pid=2210,fd=18))

Ici, c'est une autre instance de mynode (PID 2210), souvent un ancien processus oublié ou deux services lancés par erreur. Remède : arrêter le bon service (systemctl stop), pas tuer au hasard. Ne confondez pas avec un port fermé par le pare-feu : alors le programme écoute bien, mais les connexions venues d'ailleurs n'arrivent pas (avec la politique par défaut de ufw, qui ignore les paquets, le symptôme est un délai d'attente côté client, pas une erreur côté serveur ; une règle qui rejette activement donnerait « connexion refusée »).

Exemple chiffré : arbitrer entre trois alarmes

Trois alarmes arrivent : disque à 99 %, mémoire available à 120 Mo, port occupé. Voici un classement raisonnable par ordre de risque (c'est un jugement, pas une loi : un nœud qui boucle sur des OOM kills peut passer devant) : (1) le disque plein peut corrompre une base de données ; (2) la mémoire basse mène à un OOM kill ; (3) un port occupé n'empêche que le démarrage. Agissez d'abord sur (1), après avoir confirmé par du ce qui occupe la place, et ne supprimez jamais le dossier de données de la chaîne pour « faire de la place ».

Ce que cela ne garantit PAS

• Une commande donne un instantané : un pic de mémoire d'une seconde peut ne pas apparaître. Surveillez dans le temps (la supervision est un sujet à part).
• Ces symptômes ont d'autres causes possibles : un disque défectueux, une limite de descripteurs de fichiers, un pare-feu. L'hypothèse doit être confirmée.
• Libérer de la place ne règle pas la cause : si les données croissent, il faut un volume plus grand.

À retenir

Disque : df -h puis du ; mémoire : free -m colonne available et trace OOM dans le journal du noyau ; ports : ss -tlnp pour voir qui écoute. Confirmez avant d'agir.