DPTCloud
Back to articles
Technology Insight

Securing Remote Infrastructure: Implementing Zero-Trust Single Packet Authorization (SPA) with fwknop and YubiKey for SSH

June 5, 2026

Introduction: The Vulnerability of Public SSH Ports

In the contemporary cybersecurity landscape, maintaining an open SSH port (default 22) on public-facing servers is an architectural liability. Automated network scanners, botnets, and malicious actors continuously probe the IPv4 and IPv6 spaces, generating relentless brute-force attacks and log pollution. While traditional mitigation strategies like shifting the default port, implementing fail2ban, or relying solely on SSH keys mitigate basic risks, they fail to address a fundamental flaw: the port remains visible and reachable. If a zero-day vulnerability in OpenSSH emerges, an exposed port provides an immediate entry point.

To solve this, modern infrastructure security shifts toward a Zero-Trust Network Access (ZTNA) paradigm. The goal is simple: achieve complete network invisibility where a server drops all incoming traffic by default, verifying identity before a network connection is ever established. This blog post explores how to implement an advanced, enterprise-grade Zero-Trust architecture using Single Packet Authorization (SPA) via fwknop (FireWall Knock Operator) coupled with hardware-bound YubiKey multi-factor authentication.

---

Understanding Single Packet Authorization (SPA) vs. Port Knocking

Before diving into the implementation, it is crucial to distinguish Single Packet Authorization from legacy port knocking. Traditional port knocking requires a client to send a sequence of connection attempts to specific closed ports (e.g., TCP 1000, 2000, 3000) in a precise order to trigger a firewall rule change. This method suffers from several critical flaws: it is slow, vulnerable to replay attacks, and easily detectable via network packet sniffing.

Conversely, SPA condenses authentication into a single, highly encrypted, and non-replayable packet, typically sent over UDP. The packet contains an encrypted payload including a timestamp, cryptographic nonces, and the desired access parameters. The receiving server utilizes a packet capture library (such as libpcap) to passively monitor the network interface. Because the firewall drops all unsolicited packets, the server appears entirely offline ("stealth mode") to external scanners. Only when fwknopd intercepts a valid, cryptographically signed SPA packet does it dynamically manipulate netfilter/iptables rules to temporarily grant access to the specific source IP address.

---

Architectural Overview: SPA Powered by fwknop and YubiKey

Integrating a hardware security key (HSK) like the YubiKey into this workflow adds an immutable layer of identity assurance. Even if an engineer's laptop is compromised and their software-based SSH and SPA keys are exfiltrated, an attacker cannot generate a valid SPA packet without physically touching the YubiKey hardware token. This configuration utilizes a multi-layered defense strategy:

  • Layer 1: Default-Drop Firewall. The server drops all incoming TCP traffic on port 22. Network scans report the port as filtered or closed.
  • Layer 2: SPA Packet Generation (Client Side). The client-side fwknop utility constructs an authorization payload. To sign or encrypt this payload, it requires a cryptographic key securely locked inside the YubiKey via GnuPG (GPG) or OpenPGP smartcard protocols.
  • Layer 3: Passive Packet Inspection (Server Side). The fwknopd daemon detects the payload, decrypts it using its localized key store, verifies the timestamp to prevent replay attacks, and confirms the signature matches the public key associated with the user's YubiKey.
  • Layer 4: Dynamic Firewall Modification. The firewall temporarily opens port 22 exclusively for the client's public IP address for a brief window (e.g., 30 seconds).
  • Layer 5: Standard SSH Authentication. The user initiates the standard SSH session, authenticated via traditional SSH keys or separate FIDO2/U2F YubiKey resident credentials. Once the session establishes, the firewall closes the window for new connections, leaving the active session uninterrupted.
---

Step-by-Step Implementation Guide

1. Preparing the YubiKey and GPG Integration

To establish hardware-bound security, we leverage the OpenPGP application resident on the YubiKey. Ensure you have the gpg and ykman (YubiKey Manager) tools installed on your administrative workstation.

First, generate your master and subkeys directly on the YubiKey or import existing secure keys onto the token. Ensure that the Authentication (A) capability is enabled, as this key will handle the cryptographic signing of the SPA packet.

Export the public key from your workstation to transfer it to the target server later:

gpg --export --armor YOUR_KEY_ID > public_key.asc

2. Installing and Configuring fwknop on the Server

On your target Linux server (e.g., Ubuntu or Debian), install the server-side daemon:

sudo apt-get update
sudo apt-get install fwknop-server iptables

Next, we must import the client's GPG public key into the fwknopd GPG keyring. This allows the daemon to verify the authenticity of incoming payloads:

sudo fwknopd --gpg-home=/etc/fwknop/gpg --import-key public_key.asc

Modify the primary configuration file, /etc/fwknop/access.conf, to enforce strict GPG validation and tie access rights to the specific public key:

SOURCE                        ANY
REQUIRE_SOURCE_ADDRESS        Y
SOURCE_MATCH_STRICT           N
OPEN_PORTS                    tcp/22
FW_ACCESS_TIMEOUT             30
REQUIRE_GPG_SIG               Y
GPG_DECRYPT_ID                SERVER_KEY_ID
GPG_ALLOW_SIGNING_PUBKEY      CLIENT_KEY_ID
GPG_HOME_DIR                  /etc/fwknop/gpg

Configure network interface bindings and firewall type within /etc/fwknop/fwknopd.conf, ensuring PCAP_INTF points to your primary network interface (e.g., eth0 or enp0s3).

3. Configuring the Server Firewall

To lock down the environment, establish a default-drop policy for incoming SSH connections. Execute the following iptables commands to secure the state while ensuring you do not drop your current active administrative session:

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j DROP

Enable and start the daemon to actively listen for incoming SPA packets:

sudo systemctl enable fwknop-server
sudo systemctl start fwknop-server

4. Configuring the Client Workstation

Install the client utility on your local machine. If running macOS, use Homebrew; for Linux, use your native package manager:

sudo apt install fwknop-client  # Linux
brew install fwknop            # macOS

Define the target server parameters within your local configuration file (~/.fwknoprc):

[production-server]
    SPA_SERVER          192.0.2.1
    ACCESS              tcp/22
    GPG_RECIPIENT       SERVER_KEY_ID
    GPG_SIGNER          CLIENT_KEY_ID
    GPG_HOME_DIR        ~/.gnupg
    USE_GPG             Y
---

Testing the Stealth Connection Workflow

With configuration complete, execution requires triggering the SPA packet prior to invoking SSH. When the client executes the command below, the YubiKey will flash, prompting physical interaction (touch) to release the cryptographic signature:

fwknop -n production-server

Upon successful verification, fwknopd on the server dynamically creates an iptables entry allowing your IP address through port 22. You can immediately execute your standard connection command:

ssh [email protected]

After 30 seconds, the temporary firewall rule expires, closing the port to new connection requests. However, due to stateful packet inspection rules (ESTABLISHED,RELATED), your active SSH terminal remains perfectly stable and connected.

---

Enterprise Best Practices and Operational Considerations

Deploying Single Packet Authorization in production enterprise environments requires adhering to strict operational guidelines to prevent self-lockouts and ensure maximum resilience:

  1. Redundant Access Paths: Never rely exclusively on a single access control path. Maintain out-of-band management console access (such as cloud provider serial consoles or IPMI) in case of misconfigurations or local daemon failures.
  2. Automated IP Resolvers: Since mobile and remote workforces switch networks frequently, utilize the -R flag or configure automatic public IP detection on the client-side tool to avoid mismatched firewall authorization requests.
  3. Time Synchronization: SPA packets rely heavily on precise timestamps to invalidate replay attempts. Ensure both client machines and target servers sync accurately via Network Time Protocol (NTP/Chrony). A drift exceeding a few minutes will cause authorization payloads to be systematically rejected.
  4. Monitoring and Auditing: Centralize your fwknopd system logs via syslog or a security information and event management (SIEM) pipeline. Successfully validated SPA events, configuration changes, and rejected anomaly signatures should generate real-time operational alerts.
---

Conclusion

By abstracting access control from the application layer (SSH) down to the network layer (SPA via fwknop), and coupling it with hardware-enforced cryptography (YubiKey), organizations can achieve an exceptionally resilient Zero-Trust architecture. Your infrastructure is rendered completely invisible to unauthorized scans, drastically narrowing the attack surface and providing definitive defense-in-depth for critical infrastructure access.