Summary

Ship a static, recognizable Ed25519 "vanity" SSH public key (e.g., with a suffix ...++VyOS++) pre-installed for the default vyos user in data/config.boot.default, mirroring the role of the existing default password vyos - but for key-based authentication.

Use case

VyOS already ships with a well-known default password (vyos) to bootstrap initial access. Modern provisioning workflows (Ansible, Terraform, Packer, cloud-init, PXE/ZTP pipelines) prefer key-based auth and frequently need to reach a fresh image over SSH before any human logs in.

Today this requires either:

• injecting a key via user-data/cloud-init (not always available, e.g. bare-metal first boot, lab/dev images, embedded targets), or
• scripting an sshpass-style password login purely to install a key, which is exactly the workflow that breaks when password auth is disabled by hardening defaults or by PasswordAuthentication no in stricter SSH policies.

A static, publicly-known default key solves the same bootstrap problem the default password solves, but for automation. The "vanity" suffix (a base64 tail engineered to read as ++VyOS++ or similar) makes the key instantly identifiable in ~/.ssh/authorized_keys, in sshd logs, and in audit/compliance scans — so its presence on a production box is a loud, grep-able signal that the device was never hardened, exactly the way password vyos is today.

This is consistent with how other vendors handle bootstrap: Cisco/Arista publish default credentials; cloud images bake in a known cloud-init flow; appliance vendors ship vanity-tagged defaults specifically so audit tooling can flag them.

Additional information

Configuration

Two lines added to data/config.boot.default in vyos-1x:
set system login user vyos authentication public-keys default-boot type ssh-ed25519
set system login user vyos authentication public-keys default-boot key AAAAC3NzaC1lZDI1NTE5AAAAIBTFXhL3cM7V4TqClTrl2AEI80Jcv6Fuyimm++VyOS++

The identifier default-boot is intentional: it matches the default- prefix convention already used elsewhere in the config tree and gives ops tooling a stable key name to detect and remove.

Vanity key publication

The corresponding private key is published alongside the release (same security posture as the default password).

Hardening guidance (documentation deliverable)

Docs should mandate one of three actions on first login, mirroring the existing "change the default password" guidance:

1. Replace with operator's own key:

delete system login user vyos authentication public-keys default-boot
set system login user vyos authentication public-keys personal-key type ssh-ed25519
set system login user vyos authentication public-keys personal-key key <operator_public_key>
commit ; save

2. Generate a new key (locally or on the device) and apply via the same delete + set flow.

3. Delete the default key entirely if password auth or other admin users are in use:

delete system login user vyos authentication public-keys default-boot

Audit / detection

The vanity suffix is the whole point of the design: a one-line check (grep VyOS++ ~vyos/.ssh/authorized_keys, or an equivalent op-mode command / config-check rule) flags any device still carrying the bootstrap key. Worth considering:

• a show system login warning when default-boot is still present, analogous to the existing default-password warning,
• a config-mode commit-time advisory (not a hard error — would break the bootstrap use case itself),
• inclusion in vyos-config-check / hardening-audit tooling.

Scope / non-goals

• Does not change default password behavior; the two mechanisms coexist and carry the same "rotate before production" expectation.
• Does not enable SSH on interfaces that aren't already enabled by default; this only populates authorized_keys for when SSH is brought up.
• No change to sshd defaults, ciphers, or PasswordAuthentication.

commit ; save

Suggested vanity VyOS key pair

fingerprint: SHA256:+8PobIf9Dm2l6mlBOy9LViwmwXa2ir/XWU7sng3CHEM

Public key: AAAAC3NzaC1lZDI1NTE5AAAAIBTFXhL3cM7V4TqClTrl2AEI80Jcv6Fuyimm++VyOS++

Private key:

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACAUxV4S93DO1eE6gpU65dgBCPNCXL+hbsoppvvlcjkvvgAAAJC7gMgMu4DI
DAAAAAtzc2gtZWQyNTUxOQAAACAUxV4S93DO1eE6gpU65dgBCPNCXL+hbsoppvvlcjkvvg
AAAEBMf+734op8SvJgkY7PInZe8G0I86j1g6qVwN1q5W/rUhTFXhL3cM7V4TqClTrl2AEI
80Jcv6Fuyimm++VyOS++AAAACXZhbml0eXNzaAECAwQ=
-----END OPENSSH PRIVATE KEY-----