Marc S. Weidner
9d11a1bf16
Some checks failed
💙 Generating a PUBLIC Live ISO. / 💙 Generating a PUBLIC Live ISO. (push) Has been cancelled
🔐 Generating a Private Live ISO TRIXIE. / 🔐 Generating a Private Live ISO TRIXIE. (push) Has been cancelled
🛡️ Shell Script Linting / 🛡️ Shell Script Linting (push) Successful in 1m37s
🛡️ Retrieve DNSSEC status of coresecret.dev. / 🛡️ Retrieve DNSSEC status of coresecret.dev. (push) Successful in 53s
Signed-off-by: Marc S. Weidner <msw@coresecret.dev>
151 lines
6.6 KiB
Markdown
151 lines
6.6 KiB
Markdown
---
|
||
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.520.2025.12.02<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 -->
|