---
gitea: none
include_toc: true
---

# 1. CISS.debian.live.builder

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

# 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`` <key> MUST succeed.
    * ``ssh-keygen -yf`` <key> 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:
````bash
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:
````bash
/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](https://coresecret.eu/)**
<!-- vim: set number et ts=2 sw=2 sts=2 ai tw=128 ft=markdown -->