Secure SSH key for VPS with PassCypher HSM PGP

Threat Model — Attack surface

Before deploying a key-only SSH VPS, it is essential to map out the threats. Any Internet-facing server becomes an immediate target for automated scans. Attackers don’t need to know who you are: botnets probe your IP as soon as it goes live. Understanding this threat model helps size a defense with sovereign controls.

• SSH bots & brute force ⛓ — Millions of dictionary attempts hit port 22 every day. Within 30 minutes of exposure, a weak VPS is already under attack. Mitigation: PasswordAuthentication no, a non-standard port (49152), and private key stored in PassCypher HSM.

• Software compromise (browser, password manager) ⚠ — Cloud password managers and browser extensions live in the DOM, making them prone to exfiltration via phishing, redressing, or XSS injection. Moving key generation and storage to an NFC/PGP HSM removes this vector.

• Private key leakage client-side ⎔ — A cleartext key in ~/.ssh or cloud vault is a gift to malware. PassCypher encrypts the key with AES-256 (PGP), decrypts only on demand, and never leaves it in persistent memory.

• Insider & supply chain threats ⚯ — Whether from a malicious employee, a compromised provider, or a tainted build pipeline, insider risk is real. Hardware segmentation (key in PassCypher NFC HSM, backup in EviKey NFC) adds a provider-independent barrier.

Weak Signals — Early warnings

Defense doesn’t stop at today’s threats. Weak signals highlight tomorrow’s risks. Ignoring them means suffering what could have been anticipated.

• Smarter brute force ⚠ — Scanners no longer blindly hit 22/tcp. They now detect custom ports like 49152 and adapt their wordlists. Going key-only with an HSM becomes vital since port-hopping is not enough.

• Ransomware staging on VPS ⛓ — More APT groups use compromised VPS as relays, staging servers, or exfiltration nodes. A weak VPS can be weaponized against others without your knowledge.

• Regulatory pressure (NIS2 / DORA) ⚯ — EU regulations demand strict traceability and segmentation of privileged access. Soon, critical SSH keys will be required to be off-cloud, audited, and segmented. What is best practice today will soon be mandatory.

• Industrialized SSH phishing ⎔ — Dark web kits now deliver fake SSH login prompts to trap admins. If the private key stays inside an HSM rather than in a vulnerable client, phishing loses its bite.

Secure SSH key for VPS with PassCypher — key-only on 49152

The first lock: completely disable password authentication. As long as the server accepts a password, even a long one, it remains vulnerable to credential leaks and dictionary attacks. With a key-only SSH setup, the password is out of the equation, and the server only validates cryptographic proofs (OpenSSH man page). Combined with port 49152, this greatly reduces the attack surface.

1. sshd configuration

Edit the cloud-init drop-in to disable password logins:

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

Restart the service:

sudo systemctl restart sshd

2. Block port 22

Port 22 is the first target for bots. Don’t just change ports — explicitly block 22:

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

This prevents rollback by mistake: even if someone re-enables PasswordAuthentication on 22, traffic is dropped upstream.

3. Password lock test

Once applied, test the lock yourself:

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

This forced test confirms that the server rejects passwords, even if bots hammer it.

Secure VPS SSH Keys with PassCypher HSM PGP

An SSH key is not just a file in ~/.ssh. When generated hastily on a laptop, it can leak, be copied into a cloud backup, or remain in plain text on a disk. With PassCypher NFC HSM PGP, the logic changes completely: the private key is born inside an offline Hardware Security Module (HSM), encrypted with AES-256 via PGP, and never leaves in clear form. Only the public part exits the HSM.

1. RSA / ECC Key Generation

Depending on your needs, you can choose:

• RSA 2048 / 3072 / 4096 for maximum compatibility.
• ECC P-256 / P-384 / P-521 or ed25519 for modern, compact, and resilient keys.

In both cases, the private key is immediately encapsulated in *.key.gpg, protected by a sovereign passphrase defined by the user, entropy-checked in real time (Shannon), and requested via NFC.

2. Multi-format Exports

PassCypher offers several export modes to fit different environments:

• *.pub: standard OpenSSH public key (to inject in authorized_keys).
• *.key.gpg: PGP AES-256 encrypted private key, for daily use.
• QR Code: temporary scannable container for quick injection into another NFC HSM.
• Segmented JSON: encrypted multi-fragment export, ideal for distributed storage or air-gapped vaults.

3. Step-by-Step Sovereign Workflow

• Step 1 — Sovereign Input: label name, login = SSH public key (.pub), password = PGP AES-256 encrypted private key.
• Step 2 — Encoded QR: sovereign backup artifact, storable online or offline (air-gap).
• Step 3 — Restoration: read QR Code via “Retrieve Label”, reuse via NFC HSM or BLE HID keyboard emulator (CLI included).
• Step 4 — Multi-mode Use: NFC HSM (physical read), QR → NFC (camera transfer), BLE HID emulator (inject passphrase and key locally).
• Step 5 — Air-gap Doctrine: keep the key encrypted, portable, and usable without network. Store it on EviKey NFC, export in encrypted JSON, or scan a temporary QR. Always encrypted, never in the cloud.

Fail2ban: jail sshd

Changing the port and disabling password authentication already reduces the noise. But bots will still keep scanning and trying. Fail2ban acts here like an automated security guard: it watches logs, detects repeated failures, and bans the offending IP on the spot. A simple, efficient, and indispensable shield.

1. Installation & configuration

Install the package:

sudo apt install fail2ban

Create the file /etc/fail2ban/jail.local with a dedicated SSH block:

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

2. Cleanup, activation & verification

Before enabling, clean any duplicates in [DEFAULT] and convert the file if needed:

sudo dos2unix /etc/fail2ban/jail.local

Start and check:

sudo systemctl restart fail2ban
sudo fail2ban-client status

3. Alert thresholds

By default, maxretry is often too permissive. Here, after 3 failures in 5 minutes, the IP is banned for 30 minutes.
On a sensitive bastion, you can increase bantime to several hours, or even set permanent bans.

SSH keys with PassCypher NFC HSM PGP

• Type: RSA 4096 or ECC P-384 generated on an air-gapped NFC HSM.
• Export: FMT-VPS.pub (OpenSSH), private encrypted as *.key.gpg (PGP AES-256, passphrase via NFC).
• Local decryption (usage):

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

• Public key injection into the 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"
  

• OVHcloud command: during VPS creation, paste FMT-VPS.pub into the “public SSH key” field for immediate key-only boot.

System firewall (iptables)

Here’s the step-by-step logic: first, block absolutely all incoming traffic. Then, open only what is essential — your custom SSH port (49152) and already established connections. This so-called DROP-first model (Netfilter.org) is a sovereign best practice: it drastically reduces the attack surface and turns your VPS into a key-only SSH bastion.

1. Default policy (DROP-first)

Block everything inbound, except what you explicitly allow:

# Default policy
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

2. Minimal exceptions (49152 + ESTABLISHED)

Next, add survival rules:

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

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

# Established connections
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Result: 49152 is the only open door, and any unexpected traffic is dropped by default.

3. Persistence with netfilter-persistent

Without persistence, your rules vanish after a reboot. Save them properly:

sudo apt install iptables-persistent
sudo netfilter-persistent save

At every restart, the system reloads your rules automatically, ensuring defensive consistency.

Upstream firewall (provider level)

Your VPS doesn’t live in a vacuum — it’s plugged into the global Internet, constantly swept by scanners and bots. Letting everything reach your server is like trying to filter a storm with a colander. That’s where the upstream firewall comes in, offered by most providers (OVHcloud, AWS Security Groups, Proxmox datacenter firewall, etc.).

1. Dashboard configuration

With OVHcloud, you can enable a network firewall (OVHcloud docs) directly from the customer panel. This is an upstream filter that blocks traffic before it even reaches the VPS public IP. It reduces background noise and shields your system resources from endless scans.

2. TCP/49152 filtering

The baseline rule:

• Allow only TCP/49152 (your custom SSH port).
• Optional: allow ICMP (ping) if monitoring is required.
• Block everything else: no default openings beyond this.

With this policy, even if someone runs a massive scan, the traffic never reaches your VPS. It’s your first layer of hardware defense.

3. Upstream + iptables = defense-in-depth

The upstream firewall doesn’t replace iptables — it complements it. The sovereign logic is simple:

• Layer 1 — provider: filters traffic before it hits the VM.
• Layer 2 — system: iptables only allows 49152 and established connections.
• Layer 3 — application: Fail2ban bans abusive IPs based on log analysis.

This is the very definition of defense-in-depth: multiple independent walls, absorbing the attack before it becomes critical.

Logging & audit doctrine

Securing a server is one step — continuously auditing it is what ensures resilience. In other words, logging becomes your digital surveillance system: SSH host key fingerprinting, Fail2ban jail activity, and system diagnostics. Every recorded line is a sovereign artifact. This way, you can always prove your VPS compliance with regulatory frameworks (NIS2, DORA) and align with a zero-trust security posture.

1. Server fingerprint (ssh-keyscan)

Document your VPS public fingerprint at first contact:

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

This creates a host key fingerprinting registry. If the fingerprint ever changes, you know something is wrong (Man-in-the-Middle attack, unexpected rebuild, etc.).

2. SSH & Fail2ban logs

Export logs regularly:

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

These files tell the story of who connected, who failed, and who was banned. They form your incident black box and your ongoing audit trail.

3. Config diagnostics (sshd & jail.local)

A proactive audit helps you avoid simple mistakes:

# Check for stray PasswordAuthentication yes
sudo grep -Ri password /etc/ssh/sshd_config.d/

# Debug active Fail2ban jails
sudo fail2ban-client -d

# Continuously read Fail2ban events
sudo journalctl -u fail2ban -l --no-pager

With this, you detect conflicting directives, duplicate ports, and broken jails.

4. Security artifact ledger

The Freemindtronic doctrine recommends recording every event into a dedicated ledger:

• known_hosts.audit → host key fingerprints
• ssh-access.log → SSH connections
• fail2ban.log → Fail2ban jail bans
• rotation.log → SSH key rotation history

This isn’t paperwork — it’s sovereign proof. If tomorrow someone asks “who had access and when was the key rotated”, you open the ledger, not your memory. It effectively acts as your SSH key rotation ledger for zero-trust audit.

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.

Note EviKey NFC (verrouillage matériel)

EviKey NFC n’est pas un gestionnaire logiciel ni un simple coffre chiffré. C’est avant tout une clé USB matérielle souveraine, qui repose sur un verrouillage physique par NFC. Tant qu’elle reste verrouillée, le système d’exploitation ne la voit même pas : elle est littéralement invisible. Une fois déverrouillée via NFC, elle se comporte comme une clé USB classique, mais avec un auto-lock programmable (30 s, 2 min, etc.) qui réduit les risques d’oubli ou de compromission.

Concrètement, dans notre doctrine de sécurité, la clé privée SSH est déjà chiffrée par PassCypher HSM PGP (AES-256). Il n’y a donc aucun besoin de double chiffrement. EviKey vient en complément en apportant deux garanties décisives : un contrôle physique (pas de déverrouillage NFC = pas d’accès) et une résilience hors-ligne air-gap.

Résultat : EviKey devient l’outil idéal pour transporter une clé SSH souveraine chiffrée (fichier *.key.gpg, QR Code temporaire ou JSON segmenté), sans craindre une fuite en clair. Elle agit comme un pare-feu matériel portable, parfaitement intégré à la doctrine souveraine Freemindtronic.

Usage complémentaire

• Stockage matériel : clé privée déjà chiffrée (ex. *.key.gpg) placée sur EviKey.
• Verrouillage physique : invisible tant que non activée par NFC.
• Auto-lock : isolation automatique après usage.
• Couche optionnelle : pas un remplacement de PassCypher, mais un complément de portabilité et de résilience.

📖 Ressource associée

Pour un dossier complet sur l’usage d’EviKey NFC dans le stockage sécurisé des clés SSH (mode d’emploi, cas d’usage, doctrine souveraine), consultez : Secure SSH key storage with EviKey NFC HSM.

Appendix: key commands

Here are the essential commands to harden a Debian VPS with key-only SSH on port 49152, a fail2ban jail, and a DROP-first iptables policy. Each commented line (#) explains its role:

# 1. Block port 22 for defense-in-depth
sudo iptables -A INPUT -p tcp --dport 22 -j DROP

# 2. Test forced password login (must fail)
ssh -o PreferredAuthentications=password -p 49152 debian@51.75.200.82
# Expected result: Permission denied (publickey)

# 3. Export SSH logs for audit
sudo journalctl -u ssh > ~/ssh-access.log

# 4. Export fail2ban logs
sudo journalctl -u fail2ban > ~/fail2ban.log

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABB188vMKS
[... truncated for readability ...]
-----END OPENSSH PRIVATE KEY-----

A modern OpenSSH private key always appears in this base64-wrapped form. When protected by a passphrase, it is readable only if the user provides that secret.

With Secure SSH key for VPS with PassCypher, this private key never exists in cleartext: it is encapsulated and protected by PGP AES-256 encryption, with the passphrase stored sovereignly inside the NFC HSM.

⮞ Result: even if a *.key file leaked, it would remain unusable without both the HSM and the passphrase.

Sovereign Countermeasures

Software password managers (Bitwarden, 1Password, LastPass…) do not handle the hardware generation of SSH keys. They only store private keys in encrypted databases, often exposed to the browser or cloud. This broadens the attack surface and introduces software dependency. The LastPass breaches proved it: once a vault is compromised, the entire ecosystem falls.

In contrast, PassCypher HSM PGP enforces sovereign guardianship. The SSH private key is not a vulnerable file: it is generated directly inside an HSM, encrypted with OpenPGP AES-256-CFB, and never leaves the enclave in cleartext. It becomes a sovereign artifact, inviolable and portable.

Sovereign strengths

• Multi-format portability: export in *.key.gpg, QR code, or segmented JSON container.
• Multi-mode usage: NFC HSM, QR camera import, BLE HID keyboard emulator injection.
• Air-gapped doctrine: key usable offline, physical NFC unlock mandatory.
• Zero DOM / Zero Cloud: no secret exposed in the browser DOM, no dependency on cloud servers.
• Resilience: backup possible on EviKey NFC (auto-lock hardware storage) or QR → NFC HSM transfer.

Zero Trust & Zero Knowledge doctrine

• Zero Trust: no external actor (hoster, cloud, hypervisor) ever has access to the private key.
• Zero Knowledge: the private key never exists in cleartext outside the HSM enclave.

What We Didn’t Cover

FAQ — Frequently Asked Questions

This FAQ compiles recurring questions from sysadmins and SecOps across forums, tickets, and field feedback.
It evolves with weak signals and sovereign operational practices.