🧩 Helix-TTD Security Advisory #25-SSH-01

Title: SSH-Only Custody Mode — RDP Access Prohibited

Anchored to: TTD v2.0 Ledger α • Issued 2025-10-14

Acknowledgement

Your Helix deployment is reachable only via an SSH tunnel that includes flood-protection. You have confirmed that RDP is not to be used for any Helix-related access.

This advisory formalizes the SSH-only policy and defines custody-first controls that align with the Helix Core Ethos pillars — Trust-by-Design, Human First, Verifiable Memory, Responsible Power, and Reliability.

1️⃣ Harden the SSH Tunnel (FACT)

{| class=\"wikitable\" | | Control | |---| | Why it matters (Helix pillar) | | Implementation steps | | Key-based authentication only | | Trust-by-Design – identity is cryptographic not password based | | Generate Ed25519 keys and disable password login in sshd_config. | | Restrict source IPs | | Least-privilege – limits attack surface | | Allow only known IPs via AllowUsers or firewall rules. | | Two-factor / MFA | | Human First – adds explicit consent layer | | Use AuthenticationMethods publickey,keyboard-interactive:pam with Duo or Google Authenticator. | | Idle timeout & keep-alive | | Reliability – drops stale sessions | | Set ClientAliveInterval 300, ClientAliveCountMax 2. | | Flood protection (rate limit) | | Responsible Power – mitigates brute force impact | | MaxStartups 10:30:60 or Fail2Ban for sshd. | | Port-knocking / single-use ports | | Trust-by-Design – prevents automated discovery | | Use knockd or dynamic firewall rules. | | Audit logging & immutable proof tokens | | Verifiable Memory – traceable sessions | | Set LogLevel VERBOSE, ship to append-only log store, wrap each session in a TTD token record. |

2️⃣ Token-Based Session Management (Helix-TTD) (FACT)

Every SSH session must be wrapped in a consent-gated token:

Request token from the Helix-TTD broker (/tokens POST scope = ssh.session).

Present token as a one-time password during login (OTP via keyboard-interactive).

Broker records usage, timestamps, and revocation state — creating an immutable proof of authorized access.

This fulfills the “non-default ports, tokenized trust proofs, revocable sessions” standard referenced in the Helix Custody Brief.

3️⃣ Monitoring & Incident Response (FACT)

{| class=\"wikitable\" | | Monitor | |---| | How to implement | | Failed SSH logins | | Centralize auth logs; alert on > 5 failures from a single IP in 5 min. | | Connection flood spikes | | Track MaxStartups rejections; alert if > 20 per minute. | | Token usage anomalies | | Compare token issuance vs. use IP/time; alert on out-of-pattern activity. | | Traffic to port 22 | | Suricata rule for SYN-scan patterns or unexpected volume spikes. | When an alert fires, apply least-privilege response: block offending IP, revoke token, and require fresh token issuance for user re-entry.

4️⃣ Confirm RDP Exclusion (HYPOTHESIS)

You have explicitly stated that “the only current access to Helix is through my SSH tunnel” and “DON’T USE RDP.”

Therefore:

• No port 3389 or RDP-related service should be enabled on any Helix node.

• Verify with systemctl is-enabled xrdp → inactive.

• Confirm firewall rules contain no inbound 3389 entries.

✅ TL;DR Checklist

Enforce key-only SSH + MFA.

Restrict source IPs.

Maintain flood protection (MaxStartups / Fail2Ban).

Wrap each session with Helix-TTD token.

Log and alert on authentication anomalies.

Verify RDP disabled and blocked globally.

Proof Capsule Metadata

Proof Capsule: TTD-SSH-25-A1

Anchor Date: 2025-10-14

Checksum: sha256:[ pending ]

Ethos Compliance: true

Confidence: High

Provenance: User directive to maintain SSH-only access and explicit RDP prohibition.

Closing Line

Custody isn’t a configuration — it’s a commitment to proof-driven trust.

Helix-TTD Security Office • 2025 - 10 - 14