CISS.debian.live.builder/docs/MAN_SSH_Host_Key_Policy.md

Table of Contents

• 1. CISS.debian.live.builder
• 2. SSH Host Key Policy – CISS.debian.live.builder / CISS.debian.installer
• 2.1. Scope & Objectives
• 2.2. Goals
• 2.3. Key Classes
• 2.4. Generation & Format Requirements
• 2.5. Deterministic Host Keys (Internal Use Only)
• 2.6. Ephemeral Host Keys (Public / Customer Images)
• 2.7. Integrity & Sanitization Pipeline
• 2.8. sshd Configuration Requirements
• 2.9. Security Considerations

1. CISS.debian.live.builder

Centurion Intelligence Consulting Agency Information Security Standard
Debian Live Build Generator for hardened live environment and CISS Debian Installer
Master Version: 8.13
Build: V8.13.768.2025.12.06

2. SSH Host Key Policy – CISS.debian.live.builder / CISS.debian.installer

2.1. Scope & Objectives

This policy defines how SSH host keys are generated, stored, injected, and validated within the CISS.debian.live.builder and related CISS Debian images.

2.2. Goals

• Ensure cryptographic integrity and correctness of all SSH host keys.
• Avoid accidental corruption (CRLF, re-encoding, line wrapping, tooling side effects).
• Clearly separate deterministic (internal) host keys from non-deterministic (public) host keys.
• Provide predictable behavior for automated deployments while maintaining security guarantees.

2.3. Key Classes

We distinguish three key classes:

• Root identity keys (/root/.ssh/id_*):
  • Used for controlled bootstrap, orchestration, or internal automation.
  • Maybe deterministic in tightly controlled environments.
• Deterministic SSH host keys (CISS internal):
  • Pre-generated and injected via the build system.
  • Used only for internal / trusted / non-public images.
  • Allow infrastructure and automation to reliably identify CISS systems.
• Ephemeral SSH host keys (public or customer-facing images):
  • Generated on the first boot or during installation.
  • Never shared across distinct deployments.
  • Mandatory for any image that is publicly distributed or outside a strictly controlled trust domain.

2.4. Generation & Format Requirements

All SSH host keys used with CISS images MUST meet the following requirements:

• Key generation
  • Keys MUST be generated using ssh-keygen on a trusted system.
  • Recommended minimums:
    • Ed25519 for the primary host key.
    • RSA 4096 (optional legacy compatibility).
  • Keys MUST be in OpenSSH native format:
    • -----BEGIN OPENSSH PRIVATE KEY-----
    • No experimental or tool-specific formats for host keys.
• Encoding & line discipline
  • Files MUST be 7-bit clean ASCII.
  • Line endings MUST be LF only.
  • No BOM, no trailing spaces, no hidden control characters.
  • Keys MUST NOT be edited or re-wrapped manually.
  • Transfer via SCP/rsync/Git MUST use binary mode (no text mode / CRLF conversion).
• Permissions
  • Private host keys: 0600, owned by root:root.
  • Public keys: 0644, owned by root:root.
  • Directories containing keys (e.g., /etc/ssh, /root/.ssh): at most 0700 or 0755 as appropriate.

2.5. Deterministic Host Keys (Internal Use Only)

Deterministic host keys MAY be used under the following strict conditions:

• Scope
  • Only for:
    • CISS internal infrastructure.
    • Private test images.
    • Environments where distribution, copying, and lifecycle are fully controlled.
• Distribution
  • Deterministic keys are treated as sensitive secrets, not as generic assets.
  • Storage:
    • Encrypted at rest (e.g., SOPS/age, GnuPG, offline vault).
    • Access controlled and audited.
  • Injection:
    • Keys are copied verbatim into config/includes.chroot using install or cp.
    • No templating, no inline heredocs with shell expansion, no sed/awk rewriting.
• Build-time validation
  • After injection, each private key MUST be validated in the build pipeline:
    • ssh-keygen -lf MUST succeed.
    • ssh-keygen -yf MUST succeed (proves private key is parseable by libcrypto/OpenSSH).
    • Any failure aborts the build.
• Runtime expectations
  • For deterministic/internal images, SSH clients MAY:
    • Pre-configure known_hosts with the expected host key fingerprint(s).
    • Enforce StrictHostKeyChecking=yes.
    • Any mismatch is treated as a potential security incident.
• Prohibition
  • Deterministic host keys MUST NOT be embedded into:
    • Public ISOs.
    • Customer-distributed generic images.
    • Documentation examples.
  • Reuse of the same deterministic key material across unrelated security domains is forbidden.

2.6. Ephemeral Host Keys (Public / Customer Images)

For all public, customer-facing, or uncontrolled distributions:

• No deterministic host keys
  • The image MUST NOT contain shared, static host keys.
  • Any host keys present at build time MUST be removed or regenerated on the first boot.
• On-first-boot generation
  • Use the system’s ssh-keygen/OpenSSH integration (e.g., systemd-ssh-keygen@.service or equivalent).
  • Ensure:
    • Sufficient entropy.
    • Logging of creation time and key types.
• Client-side handling
  • Documentation MUST instruct users to:
    • Verify host keys on the first connection via an out-of-band channel where feasible.
    • Use StrictHostKeyChecking=ask or yes in sensitive environments.

2.7. Integrity & Sanitization Pipeline

To protect against subtle corruption and tooling side effects, the build system MUST:

• Sanitize
  • For each key file:
    • Strip \r characters if present.
    • Reject or correct inconsistent formatting.
  • This applies to both private and public key files.
• Validate
  • Public or private:
    • ssh-keygen -lf MUST succeed.
  • Private only:
    • ssh-keygen -yf MUST succeed.
• On failure
  • Mark as ERR_SANITIZING.
  • Abort the build.
• Immutable checksums (optional, RECOMMENDED)
  • For internal debugging and forensics:
    • Write *.sha256sum.txt alongside keys during build.
    • Use read-only permissions (0444).
    • Never expose these checksum files in public images alongside deterministic keys.

2.8. sshd Configuration Requirements

• sshd_config MUST reference only valid private host keys:

HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

• .pub files MUST NOT be used as HostKey targets.
• Any additional HostKey entries MUST be kept in sync with actual keys shipped in the image.
• As part of the build or provisioning pipeline:

/usr/sbin/sshd -t

MUST succeed; otherwise the image is considered invalid.

2.9. Security Considerations

• Deterministic host keys are a trust shortcut, not a default.
• Their use is acceptable only where:
  • Image origin, distribution, and runtime context are fully controlled.
  • Key fingerprints are known and verified out-of-band.
  • For all other scenarios, unique per-system host keys are mandatory to preserve the integrity of SSH’s trust model.

---

no tracking | no logging | no advertising | no profiling | no bullshit