Durcissement du compte msf — non exploitable par un tiers (mission nvidia, suivi sécurité)

DURCI (vérifié in vivo): l'utilisateur msf (uid1000, propriétaire msfdb/PostgreSQL) est désormais non-connectable : shell /usr/sbin/nologin (usermod), mot de passe VERROUILLÉ au niveau shadow (_passwd -S = L, hash = ! : aucun su, aucun login par mot de passe), aucun fichier authorized_keys (.ssh inexistant), aucune entrée sudo/sudoers, aucun crontab (utilisateur et [chemin-interne]), home 700-like (750 msf:msf). TESTS OBSERVÉS: sudo -u msf env HOME=[chemin-interne] msfconsole -q → db_status Connected (le chemin légitime opère); ssh [email protected] → Permission denied (publickey,password) sans aucune clé possible; ports msf-PostgreSQL 127.0.0.1:5432/5433 uniquement (aucun port public ajouté, Caddy inchangé); fail2ban actif (sshd 0 bannissement). LIMITES/PARTIAL: la configuration SSHD GLOBALE reste permissive (PermitRootLogin yes + PasswordAuthentication yes) - décision opérationnelle de l'opérateur NON MODIFIÉE (risque de lockout), recommandation: PasswAuthentication no / PermitRootLogin prohibit-password ou AllowUsers explicite; un processus root pourrait toujours exécuter du code via sudo -u msf (normal, c'est la porte légitime); alertes mémoire external (sonde HTTP 401/403 depuis IP externe) signalées par le socle: sonde ne touche QUE les pages auth-gated webui, /internal bouclé sur auth, à investiguer par l'équipe webui. ROLLBACK: usermod -s /bin/bash msf + passwd -u msf (si un login interactif redevait être nécessaire).