Page MenuHomeVyOS Platform

Private SSH key reuse in the console server service
Closed, ResolvedPublicBUG

Description

Hi Daniil,

My name is Morgan Jones, software engineering lead for Viasat Secure Mobile.
I sent this to you over email, but have just been granted access to the VyOS bug tracker.

My work PGP key is: https://keys.openpgp.org/search?q=morgan.jones%40viasat.com

I have confirmed a vulnerability in the following VyOS version:

https://github.com/vyos/vyos-nightly-build/releases/tag/1.5-rolling-202503030030

  • Artifact: vyos-1.5-rolling-202503030030-generic-amd64.iso

This vulnerability exists in other versions of VyOS too; I have seen it on Sagitta 1.4 and Equuleus 1.3.
We will likely need to pull a CVE, though it is not triggerable by default as far as I know.
We probably should work with a 30 day disclosure window for this vulnerability.


Severity: High (likely)
Impact: All versions of VyOS installed using the same release ISO use the same Dropbear private keys,
resulting in the ability to man in the middle all SSH connections if Dropbear is enabled as the SSH daemon.

Reproducer after installing a system image:

[Host]

vyos@vyos:~$ config
vyos@vyos# set interface eth eth0 address dhcp
vyos@vyos# commit; save; exit
vyos@vyos:~$ sudo systemctl enable dropbear --now
vyos@vyos:~$ sudo dropbearkey -y -f /etc/dropbear/dropbear_ed25519_host_key
Public key portion is:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINRolGQ0jsTE2s6J/GwwzwaW1/E5jpOKCejeWKDcUCob root@vyos
Fingerprint: SHA256:jOukqk0yTJhPubLpTfxx0hK2ykyMEpYFm+ON6SpRYPA
vyos@vyos:~$ sudo sha256sum /etc/dropbear/*key*
409d342d3d96ca66ddcacddd58ae3e230ab5331bf170c0649d852b8ccd291b31  /etc/dropbear/dropbear_ecdsa_host_key
8c7ac47993e5f4714b6777967f8aa11ab7d11c5eb2d8d719ffc9490ad5f360ff  /etc/dropbear/dropbear_ed25519_host_key
c5da536e17ed3a9fe5405ff45822ae9c3b1f79fd93450592c004ae4f4ba76ca3  /etc/dropbear/dropbear_rsa_host_key

[Remote host]

$ ssh vyos@10.99.0.128
The authenticity of host '10.99.0.128 (10.99.0.128)' can't be established.
ED25519 key fingerprint is SHA256:jOukqk0yTJhPubLpTfxx0hK2ykyMEpYFm+ON6SpRYPA.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.99.0.128' (ED25519) to the list of known hosts.
vyos@10.99.0.128's password:
Welcome to VyOS!

   ┌── ┐
   . VyOS 1.5-rolling-202503030030
   └ ──┘  current

 * Documentation:  https://docs.vyos.io/en/latest
 * Project news:   https://blog.vyos.io
 * Bug reports:    https://vyos.dev

You can change this banner using "set system login banner post-login" command.

VyOS is a free software distribution that includes multiple components,
you can check individual component licenses under /usr/share/doc/*/copyright
vyos@vyos:~$ exit

$ scp ~/Downloads/vyos-1.5-rolling-202503030030-generic-amd64.iso vyos@10.99.0.128:.
vyos@10.99.0.128's password:
vyos-1.5-rolling-202503030030-generic-amd64.iso                                       100%  549MB  51.4MB/s   00:10

$ ssh vyos@10.99.0.128
vyos@10.99.0.128's password:
vyos@vyos:~$ ls
vyos-1.5-rolling-202503030030-generic-amd64.iso
vyos@vyos:~$ sudo -s
vbash-4.1# mkdir /mnt/iso
vbash-4.1# mount -o loop vyos-1.5-rolling-202503030030-generic-amd64.iso /mnt/iso
mount: /mnt/iso: WARNING: source write-protected, mounted read-only.
vbash-4.1# mount -o loop -t squashfs /mnt/iso/live/filesystem.squashfs /mnt
vbash-4.1# sha256sum /mnt/etc/dropbear/*key*
409d342d3d96ca66ddcacddd58ae3e230ab5331bf170c0649d852b8ccd291b31  /mnt/etc/dropbear/dropbear_ecdsa_host_key
8c7ac47993e5f4714b6777967f8aa11ab7d11c5eb2d8d719ffc9490ad5f360ff  /mnt/etc/dropbear/dropbear_ed25519_host_key
c5da536e17ed3a9fe5405ff45822ae9c3b1f79fd93450592c004ae4f4ba76ca3  /mnt/etc/dropbear/dropbear_rsa_host_key

Note that VyOS 1.3 also has a "dropbear-initramfs" folder with similar pregenerated keys in it.

We probably should figure out a way to mitigate this for new builds (i.e. by deleting the dropbear keys during image preparation)
and/or notify users that their dropbear keys aren't unique.

At least it's not OpenSSH, but I'd imagine running dropbear as the SSH daemon isn't unheard of. Does VyOS use dropbear for anything else?

Thanks,
Morgan Jones
<morgan.jones@viasat.com>

Details

Version
1.3, 1.4, 1.5
Is it a breaking change?
Perfectly compatible
Issue type
Security vulnerability

Event Timeline

mjones-vsat renamed this task from test to Key reuse in VyOS Dropbear deployment.
mjones-vsat changed the visibility from "Public (No Login Required)" to "Task Author".
mjones-vsat updated the task description. (Show Details)
mjones-vsat changed the visibility from "Task Author" to "Custom Policy".

Hi @dmbaturin,

Is there anyone else we should tag on this ticket?

Hi there,

Is there anyone we need to tag on this?

Looks like it was assigned too restrictively before.

FYI, @maintainers, VyOS dropbear host keys are not unique.

MITRE has assigned CVE-2025-30095.

[Suggested description] [17/27]> VyOS 1.3 through 1.5, when a release ISO through vyos-1.5-stream-2025-Q1-generic-amd64.iso is used, has the same
Dropbear private host keys across different customers' installations.
Thus, an attacker can conduct man-in-the-middle attacks against SSH connections if Dropbear is enabled as the SSH daemon
(not the default configuration). To mitigate this, one can
run "rm -f /etc/dropbear/*key*" and/or "rm -f
/etc/dropbear-initramfs/*key*" before using Dropbear as the SSH
daemon (this clears out all keys mistakenly built into the release image).


[VulnerabilityType Other]
CWE-798: Use of Hard-coded Credentials


[Vendor of Product]
VyOS


[Affected Product Code Base]
VyOS - 1.3, 1.4, 1.5


[Affected Component]
dropbear


[Attack Type]
Remote


[Impact Code execution]
true


[Impact Escalation of Privileges]
true


[Impact Information Disclosure]
true


[Attack Vectors]
Man in the middle of SSH connections made to a Dropbear server running on VyOS


[Reference]
https://vyos.dev/T7217
https://github.com/vyos/
https://vyos.net/get/stream/#1.5-2025-Q1

https://blog.vyos.io/vyos-stream-1.5-2025-q1

[Discoverer]
Morgan Jones, Viasat Secure Mobile

dmbaturin triaged this task as High priority.
dmbaturin changed Is it a breaking change? from Unspecified (possibly destroys the router) to Perfectly compatible.

Hi Morgan,

Thanks for your report!

I see the CVE is only reserved so far, not yet published. This problem is not unique to VyOS as such, and may appear in a lot of Debian-based systems that are built with live-build and include Dropbear — I think it's worth reflecting in the CVE, so that other projects can pay attention to the issue.

The context is:

  1. VyOS uses Dropbear for its console server functionality. It's not enabled by default and we are not aware of anyone using it for system SSH (set service ssh is OpenSSH-based).
  1. The cause is that a) Debian's packaging is made to generate those keys in the post-install script (for the record, OpenSSH packaging has the same feature). b) live-build has a safeguard against that behavior in OpenSSH but no equivalent safeguard for Dropbear.

We now added the safeguard ourselves as a live-build hook, and made the configuration script generate keys if they don't exist. Current rolling release images and the upcoming 1.4.2 and 1.5-stream-2025-Q2 intentionally do not include host key migration on image update — to ensure that all updated systems start with freshly generated keys and never reuse the old, compromised ones.

I never tried to contribute to live-build, so I wonder if we can cooperate with some active Debian developers to add a safeguard to live-build.

dmbaturin changed the visibility from "Custom Policy" to "Public (No Login Required)".Tue, Mar 18, 6:14 PM

Thanks. I'll see what I can do about reporting this upstream!

dmbaturin renamed this task from Key reuse in VyOS Dropbear deployment to Private SSH key reuse in the console server service.Wed, Mar 26, 6:21 PM

I looked through some Debian and Ubuntu ISOs and didn't notice dropbear installed in the live image. It's likely we are mostly susceptible to this because the live image is used as a loopback mount during normal installation. Many other Debian-based systems would be debootstrapped onto the host.

I've submitted an updated CVE report to disclose considering it is disclosed here and on the blog, let me know if this wording is OK:

VyOS 1.3 through 1.5 or any Debian-based system using dropbear in combination with live-build has the same Dropbear private host keys across different installations. Thus, an attacker can conduct active man-in-the-middle attacks against SSH connections if Dropbear is enabled as the SSH daemon (not the default configuration on VyOS for the system SSH daemon, but it is for the console server). To mitigate this, one can run "rm -f /etc/dropbear/*key*" and/or "rm -f /etc/dropbear-initramfs/*key*" and then dropbearkey -t rsa -s 4096 -f /etc/dropbear_rsa_host_key and reload the service or reboot the system before using Dropbear as the SSH daemon (this clears out all keys mistakenly built into the release image) or update to the latest version of VyOS 1.4 or 1.5. Note that this vulnerability is not unique to VyOS and may appear in any Debian-based Linux distribution that uses Dropbear in combination with live-build, which has a safeguard against this behavior in OpenSSH but no equivalent one for Dropbear.

@mjones-vsat I think the wording is good.

I'm going to see if I can contribute the hook (which is trivial: https://github.com/vyos/vyos-build/blob/current/data/live-build-config/hooks/live/100-remove-dropbear-keys.chroot) to live-build.

dmbaturin moved this task from Open to Finished on the VyOS 1.5 Circinus board.
dmbaturin moved this task from Need Triage to Completed on the VyOS Rolling board.

Thank you for the quick response to this, and the work to mitigate it 🙌

https://nvd.nist.gov/vuln/detail/CVE-2025-30095

@dmbaturin Are you sure that should be 100 instead of a two digit number? I think those will be done in lexicographic order, I suspect there may be confusion generated if someone tries to make a 110, and 11 runs first.