**Summary**
[Describe the feature briefly.
Example: "Add support for 802.1q VLAN interfaces."]
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**
[Example: "802.1q VLAN interfaces are widely used for traffic separation in switched networks and for "router on a stick" scenarios. Most router vendors support them.]
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**
[Add anything you think is important for maintainers to understand your feature idea.]
**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 <vanity_public_key_string>`
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-----