[GH-ISSUE #1798] Don't create PrivateKey on install #3396

Open
opened 2026-08-05 00:52:11 -04:00 by saavagebueno · 7 comments
Owner

Originally created by @euh2 on GitHub (Apr 4, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/1798

Problem

I struggled with a weird issue. I deployed several machines from one base image. In the base image I have Netbird preinstalled. From all machines only one would connect to the Netbird Network. When checking the machines, all of them would have the same /etc/netbird/config.json, i.e. the same PrivateKey.

Since Netbird is installed at Image build time, the keys are the same for all deployed instances. That does of course not work.

To Reproduce

See above

Expected behavior

Create the PrivateKey when first running netbird up.

Are you using NetBird Cloud?
No

NetBird version

0.27.0

Originally created by @euh2 on GitHub (Apr 4, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/1798 **Problem** I struggled with a weird issue. I deployed several machines from one base image. In the base image I have Netbird preinstalled. From all machines _only one_ would connect to the Netbird Network. When checking the machines, all of them would have the same `/etc/netbird/config.json`, i.e. the same **PrivateKey**. Since Netbird is installed at Image build time, the keys are the same for all deployed instances. That does of course not work. **To Reproduce** See above **Expected behavior** Create the **PrivateKey** when first running `netbird up`. **Are you using NetBird Cloud?** No **NetBird version** 0.27.0
saavagebueno added the feature-request label 2026-08-05 00:52:11 -04:00
Author
Owner

@sbrw commented on GitHub (Jan 21, 2025):

Is there a workaround for this?
What is used for creation of the private key? Machine ID, SSH key...?

<!-- gh-comment-id:2604187313 --> @sbrw commented on GitHub (Jan 21, 2025): Is there a workaround for this? What is used for creation of the private key? Machine ID, SSH key...?
Author
Owner

@0xSeb commented on GitHub (Jun 4, 2025):

We face the exact same issue running multiple EC2 instances from our base AMI where we baked the install of netbird. Anything planned for this or a workaround ?

<!-- gh-comment-id:2940442530 --> @0xSeb commented on GitHub (Jun 4, 2025): We face the exact same issue running multiple EC2 instances from our base AMI where we baked the install of netbird. Anything planned for this or a workaround ?
Author
Owner

@0xSeb commented on GitHub (Jun 4, 2025):

We just found a workaround in our base AMI

  • install netbird
  • rm /etc/netbird/config.json

When we start netbird with a setup key, this file gets generated with a new private key and all.

<!-- gh-comment-id:2940453561 --> @0xSeb commented on GitHub (Jun 4, 2025): We just found a workaround in our base AMI - install netbird - rm /etc/netbird/config.json When we start netbird with a setup key, this file gets generated with a new private key and all.
Author
Owner

@nazarewk commented on GitHub (Jun 4, 2025):

How did you guys end up with NetBird client started while building the images?

Generally, those should be cleared (like A LOT of other dynamic data) before dumping the system image for reuse.


What is used for creation of the private key? Machine ID, SSH key...?

It's a random key depending on nothing specific.


We just found a workaround in our base AMI

* install netbird

* rm /etc/netbird/config.json

When we start netbird with a setup key, this file gets generated with a new private key and all.

You have the right idea. This should be in a post-baking/wrapup step for any kind of AMI/base image before storing it anywhere for reuse.


It's probably not easy in the current codebase, but a feature that would generate the keys upon first connection attempt would make some sense in the future.

<!-- gh-comment-id:2940632536 --> @nazarewk commented on GitHub (Jun 4, 2025): How did you guys end up with NetBird client started while building the images? Generally, those should be cleared (like A LOT of other dynamic data) before dumping the system image for reuse. --- > What is used for creation of the private key? Machine ID, SSH key...? It's a random key depending on nothing specific. --- > We just found a workaround in our base AMI > > * install netbird > > * rm /etc/netbird/config.json > > > When we start netbird with a setup key, this file gets generated with a new private key and all. You have the right idea. This should be in a post-baking/wrapup step for any kind of AMI/base image before storing it anywhere for reuse. --- It's probably not easy in the current codebase, but a feature that would generate the keys upon first connection attempt would make some sense in the future.
Author
Owner

@everhardt commented on GitHub (Jun 11, 2026):

@nazarewk in recent Netbird client versions the workaround of removing /etc/netbird/config.json doesn't work anymore. In the base image in which Netbird is installed there is a /var/lib/netbird/ directory, but the only file in there (service.json) doesn't contain a private key:

{
    "log_level": "info",
    "daemon_addr": "unix:///var/run/netbird.sock",
    "log_files": [
        "/var/log/netbird/client.log"
    ]
}

still, every VM that uses the base image gets the same private key (and hostname). Do you maybe have a hint on how to resolve this?

<!-- gh-comment-id:4677937399 --> @everhardt commented on GitHub (Jun 11, 2026): @nazarewk in recent Netbird client versions the workaround of removing `/etc/netbird/config.json` doesn't work anymore. In the base image in which Netbird is installed there is a `/var/lib/netbird/` directory, but the only file in there (service.json) doesn't contain a private key: ```json { "log_level": "info", "daemon_addr": "unix:///var/run/netbird.sock", "log_files": [ "/var/log/netbird/client.log" ] } ``` still, every VM that uses the base image gets the same private key (and hostname). Do you maybe have a hint on how to resolve this?
Author
Owner

@nazarewk commented on GitHub (Jun 11, 2026):

@nazarewk in recent Netbird client versions the workaround of removing /etc/netbird/config.json doesn't work anymore. In the base image in which Netbird is installed there is a /var/lib/netbird/ directory, but the only file in there (service.json) doesn't contain a private key:

{
"log_level": "info",
"daemon_addr": "unix:///var/run/netbird.sock",
"log_files": [
"/var/log/netbird/client.log"
]
}

still, every VM that uses the base image gets the same private key (and hostname). Do you maybe have a hint on how to resolve this?

I'm out of the loop since ~December, but that could be caused by introduction of profiles last yeae. Those use different config files at different locations. Would appreciate feedback once you get it working.

<!-- gh-comment-id:4678721307 --> @nazarewk commented on GitHub (Jun 11, 2026): > [@nazarewk](https://github.com/nazarewk) in recent Netbird client versions the workaround of removing `/etc/netbird/config.json` doesn't work anymore. In the base image in which Netbird is installed there is a `/var/lib/netbird/` directory, but the only file in there (service.json) doesn't contain a private key: > > { > "log_level": "info", > "daemon_addr": "unix:///var/run/netbird.sock", > "log_files": [ > "/var/log/netbird/client.log" > ] > } > > still, every VM that uses the base image gets the same private key (and hostname). Do you maybe have a hint on how to resolve this? I'm out of the loop since ~December, but that could be caused by introduction of profiles last yeae. Those use different config files at different locations. Would appreciate feedback once you get it working.
Author
Owner

@everhardt commented on GitHub (Jun 17, 2026):

Removing /var/lib/netbird/active_profile.json and /var/lib/netbird/default.json when building the image seems to do the trick!

<!-- gh-comment-id:4727400137 --> @everhardt commented on GitHub (Jun 17, 2026): Removing `/var/lib/netbird/active_profile.json` and `/var/lib/netbird/default.json` when building the image seems to do the trick!
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#3396