Secure SSH key for VPS with PassCypher HSM PGP

Secure SSH key for VPS with PassCypher HSM PGP and NFC passphrase unlock

Secure SSH key for VPS with PassCypher — Deploy a key-only posture from first boot using PassCypher NFC HSM PGP, port 22 blocking, Fail2ban jail, DROP-first iptables policy, and upstream firewall hardening for audit-ready SSH access.

Executive Summary

Reader’s note — In a hurry? The Executive Summary gives you the essentials in less than a minute. For the full technical walkthrough, allow about 19 minutes of reading.

⚡ Goal

Deploy an auditable key-only posture from the very first boot: PasswordAuthentication no, public key injection, blocking port 22, Fail2ban jail, host firewall, and upstream firewall (e.g. OVH Network Firewall). Dedicated port: 49152.

💥 Scope

Server vps-d39243a8 (Debian). Root access via debian (public key injected). HSM used: PassCypher NFC HSM PGP. Optional hardware storage with EviKey NFC (hardware lock, no imposed encryption). Multi-cloud compatible: OVH, AWS, GCP, Proxmox, bare-metal.

🔑 Doctrine

Hardware trust chain: private keys encrypted with PGP (AES-256) via PassCypher, ephemeral local decryption, public-only injection on the VPS side, systematic logging (known_hosts.audit, rotation.log).
Zero trust posture: zero passwords, zero plaintext private keys, zero implicit trust. Portability: NFC, QR Code, JSON, BLE HID.
Key rotation: HSM generation, testing, injection, atomic replacement, sovereign traceability.

🌍 Strategic Differentiator

PassCypher NFC HSM PGP adopts a zero cloud, zero disk, zero DOM posture, with multi-format portability (QR, JSON, NFC) and multi-mode usage (NFC, BLE HID, camera). Up to 100 passphrases can be injected via a secure Bluetooth HID keyboard emulator (AES-128 CBC), and the number of SSH key pairs that can be created is unlimited — extremely cost-effective compared to competing solutions.

Technical Note
Summary reading time: ~1 minute
Full reading time: ~19 minutes
Test & verification time (commands included): 10–15 minutes
Total reading time (with tests): ~30–35 minutes
Level: Infra / SecOps
Posture: Key-only, defense-in-depth
Section: Tech Fixes & Security Solutions
Available in: FR · EN · CAT · ES
Editorial type: Note
About the author: Jacques Gascuel, Freemindtronic® inventor — sovereign HSM architectures, key segmentation, and offline resilience.
TL;DR — Disable PasswordAuthentication, run SSH on 49152, inject the public key generated by PassCypher NFC HSM PGP, block TCP/22, enable Fail2ban (3 attempts/5 min, 30 min ban), enforce iptables with default DROP policy allowing only 49152 + ESTABLISHED, and filter upstream via network firewall. Log everything: host fingerprints, SSH/Fail2ban logs, key rotation ledger.
Visual legend — Secure SSH key for VPS with PassCypher HSM PGP: upstream filtering → host firewall → SSH policy → Fail2ban → sovereign key rotation (defense-in-depth, key-only SSH).
✺ Flux souverain flow for Secure SSH key on VPS with PassCypher: upstream filtering → host firewall → SSH policy → Fail2ban → hardware key rotation.

✺ Sovereign flow: upstream filtering → host firewall → SSH policy → Fail2ban → PassCypher key cycle

2025 Tech Fixes Security Solutions Technical News

SSH VPS Sécurisé avec PassCypher HSM

2025 Tech Fixes Security Solutions

Secure SSH key for VPS with PassCypher HSM PGP

2023 EviKey & EviDisk EviKey NFC HSM NFC HSM technology Tech Fixes Security Solutions Technical News

Secure SSH Key Storage with EviKey NFC HSM

2025 Tech Fixes Security Solutions

NFC HSM SSL Cert IP: Trigger HTTPS Certificate Issuance DNS-less

2025 Tech Fixes Security Solutions

Let’s Encrypt IP SSL: Secure HTTPS Without a Domain

2025 Tech Fixes Security Solutions

Emoji and Character Equivalence: Accessible & Universal Alternatives

2024 Tech Fixes Security Solutions

How to Defending Against Keyloggers: A Complete Guide

2024 Tech Fixes Security Solutions

Unlock Write-Protected USB Easily (Free Methods)

In infrastructure cybersecurity this note belongs to the Tech Fixes & Security Solutions section and is part of Freemindtronic’s sovereign operational toolkit (HSM, key segmentation, audit).

Introduction — SSH and access hardening

For more than two decades, SSH (Secure Shell) has been the backbone of remote administration. Born in 1995 to replace Telnet and rlogin (RFC 4251), SSH brought encrypted traffic, strong authentication, and session integrity. Quickly adopted across GNU/Linux distributions and hosting providers, SSH has become the standard tool to manage dedicated servers, VPS, and cloud infrastructures.
SSH has evolved alongside the threat landscape. Initially focused on transport encryption, it soon integrated asymmetric key authentication. While passwords can be intercepted, reused, or brute-forced, an SSH key relies on a cryptographic pair (public/private). The server never stores the private key — it only keeps the authorized public key (authorized_keys). Authentication comes from a mathematical proof, not a reusable secret.

This paradigm shift has immediate impact:

  • Resistance to brute force — an RSA 4096 or ECC P-384 key cannot be dictionary-attacked like a password.
  • Passwordless posture — enabling PasswordAuthentication no ensures the server refuses any password attempt.
  • Cryptographic proof — every session is signed uniquely with the private key.
  • Auditability — each registered public key is traceable and can be revoked instantly.

In practice, using SSH keys turns a VPS into a stronger bastion, especially when combined with complementary measures like Fail2ban, a DROP-first iptables firewall, or a provider-level filter (e.g., OVHcloud Network Firewall).
This Tech Fixes & Security Solutions note focuses on a Debian VPS hosted by OVHcloud, illustrating the use of Secure SSH key for VPS with PassCypher. The same methods apply to any remote server, regardless of platform: an AWS VPS, a self-hosted LXC container, a Proxmox VM, or a physical server in a data center. The principle remains: no passwords, no implicit trust, no private keys in the clear.

⮞ Key point: SSH is universal, but its security depends on the authentication mode. With a private key stored in a PassCypher NFC/PGP HSM, the key never exists unencrypted on disk, never touches the browser or the cloud, and remains usable even in air-gapped mode.

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.
⮞ Summary
Most attacks target SSH first. With Secure SSH key for VPS PassCypher, the private key never exists unencrypted, reducing client- and server-side risk.

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.
⮞ Summary
Weak signals converge: smarter brute force, ransomware staging, regulatory push, and phishing kits. Sovereign response: PassCypher HSM PGP for off-cloud SSH keys, auditable rotation, and defense-in-depth through layered hardware and compliance.

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.

⮞ Summary
With PasswordAuthentication no and port 22 blocked, the server disappears from dictionary radars. Combined with port 49152 and keys generated in a PassCypher NFC HSM PGP, access becomes a bastion: no password attempts possible, only a valid hardware key can open the session.

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.

Secure SSH key generation on VPS with PassCypher HSM PGP and sovereign NFC passphrase.
✺ PassCypher interface for sovereign SSH key creation on VPS: RSA/ECC/ed25519 options, NFC-protected passphrase, AES-256 encryption.

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

SSH personalized password generator with PassCypher HSM PGP — secure PGP AES-256 encrypted exports.
✺ Generate a personalized SSH password with PassCypher HSM PGP: AES-256 encryption, QR code, JSON split, NFC HSM.

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.
QR Code Workflow — Sovereign Backup & Restore
With PassCypher HSM PGP, the SSH pair can be encapsulated in an encrypted QR Code (public key + private key encrypted with passphrase).
Encryption relies on PGP AES-256 (OpenPGP); the passphrase is validated with real-time Shannon entropy checks.
This QR Code becomes a sovereign artifact: portable backup online or offline (air-gap), controlled restoration, and traceability — aligned with the Secure SSH key VPS PassCypher doctrine.

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.
ℹ️ For experts: PassCypher applies PGP AES-256 in AES-256-CFB (Cipher Feedback) mode for data streams, with a session key derived via S2K SHA-256/512, plus a Modification Detection Code (MDC) to detect tampering. This follows the OpenPGP RFC 4880 standard.
⮞ Summary
With PassCypher NFC HSM PGP, an SSH key is no longer just a sensitive file but a sovereign artifact: generated offline, encrypted with AES-256-CFB and sovereign passphrase, exportable as QR or segmented JSON, and usable via NFC or BLE HID.
Zero password storage, zero cloud, zero leakage.

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.

⮞ Summary
Fail2ban monitors your SSH logs, enforces your thresholds, and bans abusive IPs automatically.
With 3 attempts max / 5 min on port 49152, automated scans stop cold.
Result: less noise, clearer logs, and a complementary defensive layer to the key-only + PassCypher HSM approach.
Every Secure SSH key for VPS with PassCypher becomes traceable, logged, and auditable.
[/col]

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.
⮞ Summary
Keys created on HSM, private always encrypted at rest, only the public key is transferred to the server; OVH provisioning = security from the very first 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.

⮞ Summary
A VPS without a firewall is an unintentional honeypot. With a DROP-first strategy + a single SSH exception on 49152, your attack surface collapses and reinforces the use of Secure SSH key for VPS with PassCypher. Combined with Fail2ban and the upstream firewall, iptables becomes the second barrier in a true defense-in-depth doctrine.

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.

⮞ Summary
An upstream firewall (OVH or equivalent) acts as an external shield: it blocks global Internet noise before it ever hits your VPS. Combined with iptables and Fail2ban, your architecture effectively shifts into bastion mode.

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.

⮞ Summary
No audit, no trust. With host key fingerprinting, exported logs, and a security artifact ledger, every key is traceable, every ban verifiable, and every anomaly detectable. This forms a continuous audit trail, the backbone of a zero-trust doctrine and the foundation of Secure SSH key for VPS with PassCypher.

Secure SSH key for VPS with PassCypher — PGP AES-256 Encrypted Private Key

An SSH key, even when generated in a sovereign HSM, is never permanent. At regular intervals — or as soon as doubt arises — it must be replaced. This is the principle of operational rotation: generate a new pair, test it, inject it, then log the event. In a VPS secured with PassCypher HSM, this rotation is the equivalent of changing the cryptographic locks of your infrastructure.

⮞ Outcome

No obsolete key remains active, and the entire system stays aligned with the defense-in-depth doctrine, with built-in traceability and resilience.

⮞ Next Step

To maintain the cryptographic posture of a VPS secured with PassCypher HSM, each rotation must be paired with rigorous generation and sovereign export of the new keys.

Secure SSH key for VPS with PassCypher — PGP AES-256 Encrypted SSH Private Key, Zero Exposure with HSM

In a VPS secured with PassCypher HSM, each private key is generated inside an NFC HSM, then immediately encrypted with PGP AES-256. It never exists in cleartext, except during a temporary decryption in RAM for local use. This posture guarantees sovereign security — cloud-free and disk-free.

1. Generation & Export

From your HSM, generate a new pair:

# OpenSSH public key + encrypted private key
FMT-VPS-new.pub
FMT-VPS-new.key.gpg

The private key is immediately encrypted with PGP AES-256. It never exists in cleartext unless you decrypt it temporarily in RAM for usage.

2. Temporary Local Decryption

To use the new key, decrypt it only into 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

The passphrase is entered via NFC, and the key is removed from disk if auto-purge is enabled.

3. Atomic authorized_keys Replacement

Connect with the old key while still valid, then overwrite the file:

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

This is an atomic replacement: the old key is eliminated in a single step, leaving no duplicates.

4. Testing & Logging

Validate access immediately:

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

Then log the operation:

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

The ledger (rotation.log) keeps a record: which key, on which day, with which justification.

⮞ Summary

Sovereign SSH key rotation prevents operational drift: each new key is generated in the HSM, tested, injected, and logged. Result: complete traceability and security always aligned with the zero trust doctrine.

Rotation is not optional but a sovereign routine. Generation in HSM, temporary local usage, atomic replacement, and logging: each cycle becomes a traceable artifact, ensuring infrastructure remains up to date and immune to obsolete keys.

EviKey NFC Note (Hardware Locking)

EviKey NFC is neither a software manager nor just an encrypted vault. It is first and foremost a sovereign hardware USB key, relying on NFC-based physical locking. While locked, the operating system doesn’t even see it: it is literally invisible. Once unlocked via NFC, it behaves like a standard USB drive, but with a programmable auto-lock (30s, 2min, etc.), reducing the risks of forgetfulness or compromise.

In practice, within our security doctrine, the SSH private key is already encrypted by PassCypher HSM PGP (AES-256). There is therefore no need for double encryption. EviKey adds two decisive guarantees: physical control (no NFC unlock = no access) and offline air-gap resilience.

Outcome: EviKey becomes the ideal tool to transport a sovereign SSH private key already encrypted (*.key.gpg file, temporary QR Code, or segmented JSON), without fearing cleartext leakage. It acts as a portable hardware firewall, perfectly integrated into Freemindtronic’s sovereign doctrine.

Complementary Use

  • Hardware storage: private key already encrypted (e.g. *.key.gpg) stored on EviKey.
  • Physical lock: invisible until unlocked by NFC.
  • Auto-lock: automatic isolation after use.
  • Optional layer: not a replacement for PassCypher, but a complement for portability and resilience.

⮞ Summary

EviKey NFC adds a physical layer of locking and auto-lock, ideal for transporting your encrypted artifacts. It complements PassCypher: the key remains protected with AES-256, while EviKey ensures hardware invisibility when not in use.

📖 Related Resource

For a full guide on using EviKey NFC for secure SSH key storage (instructions, use cases, sovereign doctrine), see: 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
⮞ Summary
These commands are your survival kit: port 22 blocking, forced password test, and log export. Simple but vital, they guarantee instant verification of your sovereign posture and provide traceability in case of incident.
Educational example — SSH private key (OpenSSH) generated by PassCypher HSM PGP
-----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 creation of SSH keys. They only store private keys in encrypted vaults, often exposed to the browser or the cloud. This widens the attack surface and introduces software dependency. The LastPass incidents proved it: once a vault is compromised, the whole ecosystem collapses.

By contrast, PassCypher HSM PGP enforces sovereign custody. The SSH private key is not a vulnerable file: it is generated directly inside an HSM, encrypted with PGP AES-256, and never circulates in cleartext. It becomes a sovereign artifact, tamper-proof and portable.

Sovereign Advantages

  • Multi-format portability: export as *.key.gpg, QR Code, or segmented JSON container.
  • Multi-mode usage: NFC HSM, QR camera import, Bluetooth HID keyboard injection.
  • Air-gap doctrine: offline usability, NFC physical unlocking mandatory.
  • Zero DOM / Zero Cloud: no secret exposed in the browser, no server dependency.
  • Resilience: backup possible on EviKey NFC (auto-lock hardware protection) or QR → NFC HSM transfer.

Zero Trust & Zero Knowledge Doctrine — zero password, zero plaintext key

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

Strategic Differentiator — why choose PassCypher

Unlike cloud HSMs (AWS CloudHSM, Azure Key Vault) or proprietary keys (Yubikey, Nitrokey, SoloKeys), PassCypher NFC HSM PGP is built on a zero cloud, zero disk, zero DOM architecture. No third-party software required, no secrets exposed to the browser, no server dependency.

Its multi-format portability (QR, JSON, NFC), multi-mode usage (NFC, BLE HID, camera), and full air-gap compatibility make it a unique, sovereign, and auditable solution — tailored for critical, self-hosted, or multi-cloud environments.

⮞ Cost-effectiveness and Scalability

The PassCypher NFC HSM can store up to 100 secure passphrases for SSH private keys, injectable via a secure Bluetooth keyboard emulator (BLE HID in AES-128 CBC). These passphrases can inject SSH keys, passwords, or secrets — without ever exposing the private key in cleartext.

The number of SSH private key pairs generated with PassCypher HSM PGP is unlimited, with no per-key cost, since this functionality is natively included in its passwordless secret and password management services. This makes PassCypher particularly cost-effective for high-rotation infrastructures, multi-user environments, or role-segmented architectures.

⮞ Outcome

A sovereign, portable, scalable, and independent solution, designed for architectures requiring security, traceability, and operational autonomy. PassCypher HSM PGP enables unlimited SSH key pair generation, secure injection via BLE HID, and the storage of 100 passphrases without per-key cost — ensuring built-in ROI and seamless multi-cloud compatibility without software dependency.

⮞ Summary

Unlike software password managers, PassCypher HSM PGP generates and stores your SSH keys outside the cloud, outside the disk, and outside the DOM. The private key never exists in cleartext, not even locally. With its multi-format portability (QR, JSON, NFC), multi-mode usage (NFC, BLE HID, camera), and zero trust doctrine, PassCypher delivers sovereign independence, complete traceability, and uncompromised operational security.

What We Didn’t Cover

Note — outside the scope of this guide:

  • Kernel hardening (sysctl.conf, AppArmor, SELinux) — complementary measures but not treated here.
  • IDS/IPS (Snort, Suricata) — real-time intrusion detection, outside minimal SSH + firewall scope.
  • Reverse proxy / HAProxy — application flow management (HTTP/HTTPS), deliberately excluded.
  • Resilience snapshots & backups — OVHcloud provides snapshot/backup mechanisms not covered here.

The objective here is to focus exclusively on the SSH chain: sovereign key generation, system hardening, and defense-in-depth layers.

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.

Why choose port 49152?

Ports ≥ 49152 (dynamic/ephemeral range) attract fewer commodity scans than 22/tcp.
It doesn’t replace key-based auth, but it reduces noise and trivial attempts.
Pair it with a fail2ban jail config for custom SSH port 49152 and a DROP-first iptables policy.

What happens if I lose my HSM?

With PassCypher HSM PGP, losing the device does not mean losing access.
From creation, your SSH private key is a PGP AES-256 encrypted OpenSSH private key with NFC HSM,
protected by your sovereign passphrase. You may keep as many encrypted copies as needed on different media
without exposing the raw key. Recovery works via a QR code compatible with NFC HSM or segmented JSON.

How do I back up and restore a sovereign SSH key?

In practice, PassCypher HSM PGP lets you multiply encrypted backups as needed:

  • Passphrase for the SSH private key: QR → PassCypher NFC HSM.
  • Online archive (secure, encrypted SSH key): Cloud, NAS, email, etc.
  • Offline archive (secure, encrypted SSH key): USB, SD, SSD, HDD, CD.
  • Contactless media: NFC NDEF Cardokey™ Pro, EviKey® NFC USB, or EviDisk® NFC SSD.
  • Digital media: QR codes readable by any scanner, including PassCypher’s recovery UI.

Log each step in rotation.log to preserve traceability.
Result: access remains blocked by design for an attacker, yet fully recoverable by you via a
QR code backup for SSH keys air-gapped recovery.

Does PassCypher replace software password managers?

No. PassCypher provides a sovereign guard outside the DOM and the cloud for critical secrets (SSH keys, OTP),
where software managers remain exposed to the browser surface. They can coexist, but sensitive SSH keys should remain in the HSM.

Do these Secure SSH keys work on any VPS (OVH, AWS, GCP, Proxmox, bare-metal)?

Yes. The method is universal (OpenSSH). OVH is just an example.
The principle is the same: generate in PassCypher NFC HSM PGP → inject the public key →
enforce PasswordAuthentication no → filter with provider firewall + iptables.

Why not just rely on FIDO/WebAuthn?

FIDO/WebAuthn targets web authentication. For SSH, the standard chain remains OpenSSH + keys.
PassCypher’s hardware-rooted guard (OpenPGP AES-256-CFB, segmented key options, Zero DOM)
avoids browser exposure and preserves an air-gapped workflow.

Are the QR code and segmented JSON container safe?

Yes, provided they are OpenPGP-encrypted (AES-256-CFB with S2K and MDC).
The QR code is a portable vector (air-gap); segmented JSON requires controlled reconstruction.
Without the decryption phrase (via NFC/PassCypher), the content is unusable.

Daily-use compatibility (Windows/macOS/Linux)?

Yes. PassCypher HSM PGP enables ephemeral local decryption usable with OpenSSH CLI or compatible SSH clients.
Injection can leverage NFC/QR or a BLE HID keyboard emulator for passphrase entry on any host that accepts USB HID.

How do I rotate keys without risking a lock-out?

Use short, atomic steps: add and test the new key first, then remove the old one.
Keep a rescue session open. Log each step in rotation.log and known_hosts.audit.
This feeds your SSH key rotation ledger for zero-trust audit.

What is StrictHostKeyChecking for in SSH?

It prevents connection (StrictHostKeyChecking)
if the server fingerprint changed. With known_hosts.audit, you maintain a registry of
host key fingerprinting. Setting StrictHostKeyChecking yes blocks MITM,
but requires disciplined, manual validation on any fingerprint change.

Do NIS2/DORA audits require SSH key rotation?

Increasingly, yes. NIS2 and DORA mandate traceability and governance of privileged access.
That implies regular SSH key rotation, usage journals (rotation.log), and the ability to revoke keys on the fly.
PassCypher’s hardware-rooted generation, multi-format cycle (QR, JSON, NFC), and native audit support this doctrine.

What if ransomware hits my VPS?

A ransomware can encrypt the disk or block active sessions, but it cannot break SSH key-based auth.
With Secure SSH key for VPS with PassCypher, your private keys stay off-server (HSM, encrypted QR, segmented JSON).
If compromised, you can restore access on a fresh instance by re-injecting the public key from sovereign backups.⮞ Doctrine: keep at least one offline backup (printed QR or air-gapped encrypted JSON) for rapid recovery.


One thought on “Secure SSH key for VPS with PassCypher HSM PGP

  1. Pingback: Secure SSH key VPS PassCypher with HSM PGP - Freemindtronic

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.