SEC.01

Le playbook

Le run démarre en lecture seule : les sondes de reconnaissance décident de la suite. Les étapes qui suivent sont adaptées à la distribution et à l'état trouvés — une vraie machine est rarement propre.

1. 01recondistro et version d’OpenSSH (KbdInteractiveAuthentication ≥ 8.7)
2. 02reconla config SSH effective (port, root, mot de passe, emplacement des clés)
3. 03reconsshd_config inclut-il sshd_config.d/ ? quels drop-ins existent (50-cloud-init.conf peut réactiver le mot de passe) ?
4. 04reconquels comptes ont des clés autorisées et lesquels sont sudoers (sans clé → NE PAS couper le mot de passe)
5. 05recon2FA TOTP en place ? (alors garder KbdInteractiveAuthentication)
6. 06reconnom de l’unité : ssh (Debian/Ubuntu), sshd (RHEL), ssh.socket (activation socket)
7. 07reconla config SSH est-elle valide avant de toucher ?
8. 08agirSauvegarder sshd_configvérif
9. 09agirInclure sshd_config.d (seulement si l’Include manque)vérif
10. 10agirDésactiver root par mot de passe + login par mot de passedestructifvérif
11. 11agirContrôler la config effective avant reloadvérif
12. 12agirRecharger sshd (sans couper les sessions)destructifvérif

SEC.02

Ce qu'elle vérifie

Chaque étape embarque sa propre vérification. Le run ne continue que si elle passe, donc ce que la recette annonce comme fait est ce qui est réellement sur le serveur.

1. 01vérifSauvegarder sshd_configVérifié parls -1 /etc/ssh/sshd_config.bak.* | tail -1attendu : un fichier de sauvegarde
2. 02vérifInclure sshd_config.d (seulement si l’Include manque)Vérifié pargrep -cE '^\s*Include\s+/etc/ssh/sshd_config.d/' /etc/ssh/sshd_config && sshd -t && echo okattendu : au moins 1 puis ok
3. 03vérifDésactiver root par mot de passe + login par mot de passeVérifié parsshd -t 2>&1 && echo okattendu : ok (config valide)
4. 04vérifContrôler la config effective avant reloadVérifié parsshd -T | grep -Ei '^(permitrootlogin|passwordauthentication) 'attendu : permitrootlogin = valeur de root_login, passwordauthentication no
5. 05vérifRecharger sshd (sans couper les sessions)Vérifié parsystemctl is-active ssh.service sshd.service ssh.socket 2>/dev/null | grep -c '^active'attendu : au moins 1

SEC.03

Les garde-fous

Les consignes non négociables que le run doit respecter, quoi qu'il trouve sur le serveur.

SEC.04

Les variables

Ce que vous choisissez avant de lancer — la recette s'occupe du reste.

SEC.05

Comment une recette s'exécute dans Servor

Servor est zero-knowledge : la plateforme ne peut rien exécuter seule. Quand vous lancez cette recette, un run lit la reconnaissance, planifie les étapes et demande votre validation. Chaque commande approuvée est signée par votre navigateur — avec une clé que le serveur ne voit jamais — puis relayée telle quelle à l'agent, qui vérifie la signature localement avant d'exécuter.

SEC.06

Bouton Deploy on Servor

Vous maintenez Durcir SSH ou un projet qui en dépend ? Ajoutez ce bouton à votre README ou à votre site : en un clic, vos utilisateurs l'installent sur leur propre serveur.

SEC.07

D'autres recettes sécurité

1. 01fail2banfail2ban avec la jail SSH sur le bon port, actif et vérifié.
2. 02Pare-feu UFWUFW : refuse l’entrant par défaut, autorise le port SSH réel + ports choisis, avec filet de sécurité. Destructif : garde SSH ouvert.
3. 03Mises à jour de sécurité autoActive les mises à jour de sécurité automatiques : unattended-upgrades (Debian/Ubuntu) ou dnf-automatic (RHEL/Fedora).
4. 04CrowdSecIPS collaboratif CrowdSec, collections SSH et bouncer pare-feu.
5. 05ClamAVAntivirus ClamAV avec signatures tenues à jour, démon optionnel.