Secure SSH key VPS PassCypher with HSM PGP

Threat Model — Modèle de menace

Avant de déployer un VPS avec SSH key-only, il faut cartographier les menaces. Un serveur exposé sur Internet devient immédiatement la cible de scans automatisés. Les attaquants n’ont pas besoin de savoir qui vous êtes : un botnet va tester votre IP dès qu’elle est active. Comprendre ce modèle de menace, c’est anticiper les attaques réelles et dimensionner une défense souveraine.

• Bots & brute force SSH ⛓ — Des millions de tentatives par dictionnaire frappent chaque jour les ports standards (22/tcp). En 30 minutes après mise en ligne, un VPS non durci reçoit déjà ses premières salves. La parade : PasswordAuthentication no, port non conventionnel (49152), clé privée en HSM PassCypher.
• Compromission logicielle (navigateur, gestionnaire) ⚠ — Les gestionnaires de mots de passe et les extensions de navigateur restent dans le DOM. Ils peuvent être exfiltrés par redressing, phishing ou injection XSS. Déporter la génération et le stockage dans un HSM NFC/PGP élimine ce vecteur.
• Fuite de clé privée côté client ⎔ — Une clé privée en clair dans ~/.ssh ou dans un gestionnaire cloud est un cadeau pour un malware. PassCypher chiffre la clé avec AES-256 (PGP), ne la déchiffre qu’à la demande et jamais en mémoire persistante. Sans HSM, la fuite devient quasi inévitable tôt ou tard.
• Menaces internes & supply chain ⚯ — Qu’il s’agisse d’un employé malveillant, d’un fournisseur de cloud compromis ou d’une chaîne de build infectée, la menace interne reste une réalité. La segmentation matérielle (clé dans un PassCypher NFC HSM, sauvegarde sur EviKey NFC) introduit une barrière supplémentaire, indépendante du fournisseur.

Weak Signals — Signaux faibles

Une défense ne s’arrête pas à ce qu’on voit aujourd’hui. Les signaux faibles, eux, annoncent les risques de demain. Ignorer ces micro-tendances, c’est subir demain ce qu’on aurait pu anticiper aujourd’hui.

• Hausse des brute force SSH ciblés ⚠ — Les scanners ne se contentent plus de taper 22/tcp au hasard. Ils détectent désormais les custom ports comme 49152 et adaptent leurs dictionnaires. Le passage en key-only via HSM devient vital, car changer de port ne suffit plus.
• Exploitation des VPS dans les ransomwares ⛓ — De plus en plus de groupes APT utilisent des VPS compromis comme relais, staging ou nœud d’exfiltration. Un VPS faible devient non seulement une porte d’entrée, mais aussi une arme retournée contre d’autres. Votre machine peut servir à attaquer un tiers sans que vous le sachiez.
• Pression réglementaire (NIS2 / DORA) ⚯ — L’Europe impose une traçabilité et une segmentation stricte des accès. Les autorités exigent bientôt que les clés SSH critiques soient hors cloud, auditées et segmentées. Ce qui est aujourd’hui une bonne pratique deviendra demain un impératif légal.
• Industrialisation du phishing SSH ⎔ — Des kits vendus sur le darkweb proposent désormais de piéger les administrateurs SSH via fake login prompts. Si la clé privée reste dans un HSM et non dans un client vulnérable, le phishing perd son effet.

Secure SSH key VPS PassCypher — key-only sur 49152

Premier verrou : éteindre complètement l’authentification par mot de passe. Tant que le serveur accepte un mot de passe, même long, il reste vulnérable aux attaques par dictionnaire ou par fuite d’identifiants. Avec un key-only SSH, le mot de passe disparaît de l’équation et Le serveur ne reconnaît que des preuves cryptographiques (OpenSSH man page). Couplé au port 49152, on réduit la surface d’exposition.

1. Configuration sshd

Éditez le drop-in cloud-init pour désactiver toute tentative password :

/etc/ssh/sshd_config.d/50-cloud-init.conf
PasswordAuthentication no

Puis redémarrez le service :

sudo systemctl restart sshd

2. Blocage du port 22

Le port standard est la première cible des bots. Il faut non seulement changer de port, mais aussi bloquer explicitement le 22 :

sudo iptables -A INPUT -p tcp --dport 22 -j DROP

Cette règle empêche tout retour en arrière “par accident” : même si quelqu’un réactive PasswordAuthentication sur 22, le trafic sera bloqué en amont.

3. Test de verrouillage password

Une fois la bascule faite, testez vous-même pour être sûr :

ssh -o PreferredAuthentications=password -p 49152 debian@51.75.200.82
# Attendu : Permission denied (publickey)

Ce test forcé confirme que le serveur n’accepte plus de mot de passe, même si un bot tente en boucle.

Clés Secure SSH key VPS PassCypher avec HSM PGP

Une clé SSH n’est pas qu’un fichier dans ~/.ssh. Générée à l’arrache sur un laptop, elle peut fuiter, se retrouver copiée dans un backup cloud, ou dormir en clair sur un disque. Avec PassCypher NFC HSM PGP, la logique change radicalement : la clé privée naît dans un Hardware Security Module (HSM) hors ligne, chiffrée en AES-256 via PGP, et ne circule jamais en clair. Seule la partie publique quitte le HSM.

1. Génération RSA/ECC

Selon le besoin, on choisit :

• RSA 4096 pour la compatibilité maximale.
• ECC P-384 pour une sécurité moderne et des clés plus compactes.

Dans les deux cas, la clé privée est immédiatement encapsulée en *.key.gpg, protégée par un mot de passe souverain demandé via NFC.

2. Exports multi-formats

PassCypher propose plusieurs modes d’export pour s’adapter aux environnements :

• *.pub : clé publique OpenSSH classique (à injecter dans authorized_keys).
• *.key.gpg : clé privée chiffrée PGP AES-256, usage quotidien.
• QR Code : conteneur temporaire scannable pour injection rapide dans un autre HSM NFC.
• JSON segmenté : export chiffré multi-fragments, parfait pour stockage distribué ou coffre-fort air-gap.

3. Utilisation multi-mode : NFC, HID, QR

La clé privée chiffrée n’est utilisable qu’après déverrouillage matériel :

• NFC HSM : lecture physique par un terminal PassCypher.
• QR Code → NFC : transfert via caméra, utile pour mobilité ou restauration.
• Émulateur HID Bluetooth : usage comme un “clavier matériel” injectant la clé localement, sans jamais la stocker.

Résultat : on sort de la dépendance aux gestionnaires logiciels et des extensions de navigateur exposées.

4. Doctrine air-gap et portabilité

L’approche est simple : la clé reste chiffrée, portable et exploitable même sans réseau. Vous pouvez la stocker sur un support EviKey NFC verrouillé, l’exporter en JSON chiffré ou scanner un QR Code temporaire pour la restaurer. Dans tous les cas, jamais en clair, jamais dans le cloud.

Fail2ban : jail sshd

Changer de port et désactiver le mot de passe réduit déjà le bruit. Mais les bots continuent de scanner et d’essayer. Fail2ban agit ici comme un vigile automatique : il scrute les logs, détecte les échecs répétés et bannit l’IP à la volée. Un rempart simple, efficace et indispensable.

1. Installation & configuration

Installez le paquet :

sudo apt install fail2ban

Puis créez le fichier /etc/fail2ban/jail.local avec un bloc spécifique SSH :

[sshd]
enabled  = true
port     = 49152
filter   = sshd
logpath  = %(sshd_log)s
maxretry = 3
findtime = 5m
bantime  = 30m

2. Seuils d’alerte (maxretry, bantime)

Par défaut, maxretry est souvent trop permissif. Ici, après 3 échecs en 5 minutes, l’IP est bannie pendant 30 minutes. Ajustez selon vos besoins : sur un bastion sensible, vous pouvez allonger le bantime à plusieurs heures, voire basculer sur un bannissement définitif.

3. Audit des jails actifs

Avant d’activer, nettoyez les doublons de configuration ([DEFAULT], backends multiples). Convertissez si besoin :

sudo dos2unix /etc/fail2ban/jail.local

Activez et vérifiez :

sudo systemctl restart fail2ban
sudo fail2ban-client status

La présence du jail [sshd] actif sur le port 49152 ne suffit pas : elle doit s’inscrire dans un socle défensif cohérent, complémentaire à l’approche Secure SSH key VPS PassCypher.

Clés SSH avec PassCypher NFC HSM PGP

• Type : RSA 4096 ou ECC P‑384 générée sur HSM NFC air‑gapped.
• Export : FMT-VPS.pub (OpenSSH), privée chiffrée *.key.gpg (PGP AES‑256, mot de passe via NFC).
• Déchiffrement local (usage) :

  gpg --decrypt --output ~/.ssh/FMT-VPS ~/.ssh/vps-fmt-ad-08-2025/FMT-VPS.key.gpg
  chmod 600 ~/.ssh/FMT-VPS
  

• Injection publique vers le VPS :

  cat ~/.ssh/vps-fmt-ad-08-2025/FMT-VPS.pub | ssh -p 49152 debian@51.75.200.82 
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && 
  cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
  

• Commande OVHcloud : lors de la création, collez FMT-VPS.pub dans le champ “clé SSH publique” pour un boot key-only immédiat.

Fail2ban : jail sshd

sudo apt install fail2ban

/etc/fail2ban/jail.local
[sshd]
enabled  = true
port     = 49152
filter   = sshd
logpath  = %(sshd_log)s
maxretry = 3
findtime = 5m
bantime  = 30m

Nettoyez les doublons dans [DEFAULT], convertissez si nécessaire, démarrez et vérifiez :

sudo dos2unix /etc/fail2ban/jail.local
sudo systemctl restart fail2ban
sudo fail2ban-client status

Pare-feu système (iptables)

Voici la logique, étape par étape : d’abord, on bloque absolument tout le trafic entrant. Ensuite, on ouvre uniquement l’essentiel, à savoir votre port SSH personnalisé (49152) et les connexions déjà établies. Ce modèle dit DROP-first (Netfilter.org) est une bonne pratique souveraine : il réduit drastiquement la surface d’attaque et transforme votre VPS en bastion SSH key-only.

1. Politique par défaut (DROP-first)

Bloquez tout en entrée, sauf ce que vous autorisez :

# Politique par défaut
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

2. Exceptions minimales (49152 + ESTABLISHED)

Ensuite, on ajoute les règles de survie :

# Loopback
sudo iptables -A INPUT -i lo -j ACCEPT

# SSH sur 49152
sudo iptables -A INPUT -p tcp --dport 49152 -j ACCEPT

# Connexions déjà établies
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Résultat : 49152 est la seule porte ouverte, et tout trafic inattendu est éjecté par défaut.

3. Persistance via netfilter-persistent

Sans persistance, vos règles disparaissent au redémarrage. Sauvegardez-les proprement :

sudo apt install iptables-persistent
sudo netfilter-persistent save

À chaque reboot, le système recharge automatiquement vos règles, garantissant la cohérence défensive.

Pare-feu en amont (hébergeur)

Votre VPS ne vit pas dans un vide intersidéral : il est branché sur l’Internet global, balayé en permanence par des scanners et des bots. Laisser tout passer jusqu’au serveur revient à filtrer l’orage avec une passoire. D’où l’intérêt du pare-feu en amont, fourni par la plupart des hébergeurs (OVHcloud, AWS Security Groups, Proxmox avec firewall datacenter, etc.).

1. Configuration dashboard

Chez OVHcloud, vous pouvez activer un firewall réseau (OVHcloud docs) directement depuis l’espace client. C’est un filtre upstream qui bloque le trafic avant même d’atteindre l’IP publique du VPS. Cela réduit le bruit réseau et protège vos ressources système des flots de scans.

2. Filtrage TCP/49152

La règle de base :

• Autoriser uniquement TCP/49152 (votre port SSH customisé).
• Optionnel : autoriser ICMP (ping) si vous avez besoin de monitoring.
• Bloquer tout le reste : aucune autre ouverture par défaut.

Avec cette politique, même si quelqu’un tente un scan massif, le trafic n’atteindra jamais votre VPS. C’est une première ligne de défense matérielle.

3. Cumul amont + iptables = defense-in-depth

Le firewall amont n’exclut pas iptables : il le complète. La logique souveraine est simple :

• Niveau 1 — hébergeur : filtre le trafic avant qu’il n’arrive à la VM.
• Niveau 2 — système : iptables ne laisse passer que 49152 et les connexions établies.
• Niveau 3 — applicatif : Fail2ban bannit les IP suspectes après analyse des logs.

C’est la définition même de la defense-in-depth : plusieurs murs successifs, indépendants, qui absorbent l’attaque avant qu’elle ne devienne critique.

Journalisation & doctrine d’audit

Sécuriser un serveur est une étape, mais auditer en continu est ce qui garantit la résilience. En d’autres termes, la journalisation devient vos caméras de surveillance numériques : empreintes SSH, logs Fail2ban, diagnostics système… Chaque ligne enregistrée constitue un artefact souverain. Ainsi, vous pouvez prouver à tout moment la conformité de votre VPS face aux exigences réglementaires (NIS2, DORA) et aux doctrines de sécurité zero trust.

1. Empreinte serveur (ssh-keyscan)

Documentez l’empreinte publique de votre VPS dès le premier contact :

ssh-keyscan -p 49152 51.75.200.82 >> ~/.ssh/known_hosts.audit

Vous créez ainsi un registre des clés serveur. Si un jour l’empreinte change, vous savez que quelque chose cloche (attaque Man-in-the-Middle, rebuild inattendu…).

2. Logs SSH & Fail2ban

Exportez régulièrement les journaux :

sudo journalctl -u ssh > ~/ssh-access.log
sudo journalctl -u fail2ban > ~/fail2ban.log

Ces fichiers racontent qui s’est connecté, qui a échoué, et qui a été banni. C’est votre boîte noire d’incidents.

3. Diagnostic config sshd & jail.local

Un audit proactif vous évite des failles stupides :

# Vérifier qu’il n’y a pas de PasswordAuthentication yes qui traîne
sudo grep -Ri password /etc/ssh/sshd_config.d/

# Déboguer les jails actifs
sudo fail2ban-client -d

# Lire en continu les événements Fail2ban
sudo journalctl -u fail2ban -l --no-pager

Avec ça, vous détectez les directives contradictoires, les doublons de ports et les jails cassés.

4. Ledger des artefacts de sécurité

La doctrine Freemindtronic recommande de consigner chaque événement dans un registre dédié :

• known_hosts.audit → empreintes serveur
• ssh-access.log → connexions SSH
• fail2ban.log → bannissements
• rotation.log → historique des clés SSH

Ce n’est pas de la paperasse : c’est une preuve souveraine. Si demain on vous demande “qui avait accès et quand la clé a été changée”, vous ouvrez le ledger, pas un vieux souvenir.

Rotation Secure SSH key VPS PassCypher

Une clé SSH, même générée dans un HSM souverain, n’est pas éternelle. À intervalles réguliers, ou en cas de suspicion, il faut la remplacer. C’est la logique de la rotation opérationnelle : générer une nouvelle paire, tester, injecter et journaliser. En pratique, cela équivaut à changer les serrures cryptographiques de votre VPS. Résultat : une infrastructure alignée sur la doctrine defense-in-depth, où aucune clé obsolète ne reste active.

1. Génération et export

Depuis votre HSM, générez une nouvelle paire :

# Clé publique OpenSSH + clé privée chiffrée
FMT-VPS-new.pub
FMT-VPS-new.key.gpg

La clé privée est immédiatement chiffrée en PGP AES-256. Elle n’existe jamais en clair, sauf si vous la déchiffrez temporairement en local pour l’usage.

2. Déchiffrement local temporaire

Pour utiliser la nouvelle clé, déchiffrez-la uniquement en RAM :

gpg --decrypt --output ~/.ssh/FMT-VPS-new ~/.ssh/vps-fmt-ad-08-2025/FMT-VPS-new.key.gpg
chmod 600 ~/.ssh/FMT-VPS-new

Le mot de passe est saisi via NFC, et la clé disparaît de votre disque si vous activez l’option auto-purge.

3. Remplacement atomique authorized_keys

Connectez-vous avec l’ancienne clé encore valide, puis écrasez le fichier :

echo "$(cat ~/.ssh/vps-fmt-ad-08-2025/FMT-VPS-new.pub)" > ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

C’est un remplacement atomique : l’ancienne clé est éliminée en un coup, sans laisser de doublons.

4. Tests et journalisation

Validez immédiatement l’accès :

ssh -i ~/.ssh/FMT-VPS-new -p 49152 debian@51.75.200.82

Et consignez l’opération :

ssh-keyscan -p 49152 51.75.200.82 >> ~/.ssh/known_hosts.audit
echo "# Rotation SSH - $(date)" >> ~/.ssh/rotation.log

Le ledger (rotation.log) garde une trace : quelle clé, quel jour, quelle justification.

La rotation n’est pas une option mais une routine souveraine. Génération sur HSM, usage local temporaire, remplacement atomique et journalisation : chaque cycle devient un artefact traçable, garantissant une infrastructure toujours à jour et hors d’atteinte des clés obsolètes.

Sovereign Countermeasures

Les gestionnaires de mots de passe logiciels (Bitwarden, 1Password, LastPass…) ne gèrent pas la création matérielle des clés SSH. Ils se contentent de stocker les clés privées dans des bases chiffrées, souvent exposées au navigateur ou au cloud. Cela élargit la surface d’attaque et introduit une dépendance logicielle. Les incidents LastPass l’ont démontré : un coffre compromis entraîne la chute de tout l’écosystème.

À l’inverse, PassCypher HSM PGP met en œuvre une garde souveraine. La clé privée SSH n’est pas un fichier vulnérable : elle est générée directement dans un HSM, chiffrée par PGP AES-256, et ne circule jamais en clair. Elle devient un artefact souverain, inviolable et portable.

Atouts souverains

• Multi-format portable : export en *.key.gpg, QR Code, ou conteneur JSON segmenté.
• Multi-mode usage : NFC HSM, import caméra QR, injection HID Bluetooth (émulation clavier).
• Doctrine air-gap : clé utilisable hors-ligne, déverrouillage physique NFC obligatoire.
• Zéro DOM / Zéro Cloud : aucun secret exposé dans le navigateur, aucune dépendance serveur.
• Résilience : sauvegarde possible sur EviKey NFC (verrouillage matériel auto-lock) ou transfert QR → NFC HSM.

Doctrine Zero Trust & Zero Knowledge

• Zero Trust : aucun acteur externe (hébergeur, cloud, hyperviseur) n’a accès à la clé privée.
• Zero Knowledge : la clé privée n’existe jamais en clair en dehors de l’enclave HSM.

What We Didn’t Cover

FAQ — Questions fréquentes

Cette FAQ condense les questions récurrentes des admins système et SecOps sur forums, tickets et retours terrain.
Elle s’enrichit au fil des signaux faibles et des pratiques souveraines.