Services

A recipe service has only three canonical fields: name, enabled, and an open-ended config object. The shape validates structurally, but a configuration key has an effect only when the selected build worker or feature hook implements it. Validation is not proof that a daemon was installed or configured.


{
  "services": [
    {
      "name": "ssh",
      "enabled": true,
      "config": {
        "port": 2222,
        "allow_root": false,
        "disable_password_auth": true,
        "authorized_keys": ["ssh-ed25519 AAAA... operator@example"]
      }
    }
  ]
}

SSH configuration

The general Linux build path recognizes these SSH settings:

Recipe key	Effect
`port` or `listen_port`	OpenSSH port, 1–65,535
`allow_root`	Maps to `PermitRootLogin`
`disable_password_auth`	Inverts into `PasswordAuthentication`
`password_authentication`	Direct OpenSSH token value
`pubkey_authentication`	Direct OpenSSH token value
`client_alive_interval`	Bounded `ClientAliveInterval`
`client_alive_attempts`	Bounded `ClientAliveCountMax`
`authentication_retries`	Bounded `MaxAuthTries`
`timeout`	Bounded login grace time
`x11_forwarding`, `allow_agent_forwarding`, `allow_tcp_forwarding`	Direct OpenSSH token values
`authorized_keys`	Installs the supplied public keys where supported

Worker-specific paths can support a smaller set. In particular, hardware, Proxmox, and Raspberry Pi builders have their own adapters. Inspect the normalized recipe and build warnings for the selected target.

If password authentication is disabled, include and independently test at least one valid public key before deploying to hardware. Do not put private keys or passwords in recipe service configuration.

Other services

Names such as nginx, wireguard, DNS, DHCP, or firewall components are not a universal configuration API. Their packages and configuration come from the corresponding feature, hook, package list, or startup script for the selected base. An arbitrary object such as config.sites may be accepted by the schema and still be ignored.

Use this sequence:

Select a base image and enable the concrete feature or packages.
Add only configuration keys implemented for that capability.
Inspect the normalized recipe and generated warnings.
Add assertions for package presence, service enablement, listener ports, configuration files, and an application-level response.
Boot and test the artifact before hardware or production promotion.

See Features, Startup scripts, and Assertion types.