[GH-ISSUE #2923] /api/setup-keys List all Setup Keys does not return Setup Keys anymore #6112

Closed
opened 2026-08-05 01:06:46 -04:00 by saavagebueno · 6 comments
Owner

Originally created by @NightHammer1000 on GitHub (Nov 21, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/2923

Describe the problem

We use the Netbird API in our Setup Routine for a custom Ubuntu Install to get a list of all the Setup Keys to choose which one to use for the Installation of the Netbird Client.

In the Past we got a list of the Full key like it is discribed here https://docs.netbird.io/api/resources/setup-keys

Now after Updating to 0.32.0 we do not get the whole API Key anymore. Just the Five first Digits. The Rest is masked out by Stars.

Are you using NetBird Cloud?

No This is a self hosted installation

Additional context

The Answer we get from the API Call:

[
...
  {
...
    "key": "0FE28****",
...
  }
]

Is this related to https://github.com/netbirdio/netbird/issues/2763 and https://github.com/netbirdio/netbird/pull/2775 ?
If yes, is there now an diffrent way to get the Setup Keys once they are already created?

Originally created by @NightHammer1000 on GitHub (Nov 21, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/2923 **Describe the problem** We use the Netbird API in our Setup Routine for a custom Ubuntu Install to get a list of all the Setup Keys to choose which one to use for the Installation of the Netbird Client. In the Past we got a list of the Full key like it is discribed here https://docs.netbird.io/api/resources/setup-keys Now after Updating to 0.32.0 we do not get the whole API Key anymore. Just the Five first Digits. The Rest is masked out by Stars. **Are you using NetBird Cloud?** No This is a self hosted installation **Additional context** The Answer we get from the API Call: ``` [ ... { ... "key": "0FE28****", ... } ] ``` Is this related to https://github.com/netbirdio/netbird/issues/2763 and https://github.com/netbirdio/netbird/pull/2775 ? If yes, is there now an diffrent way to get the Setup Keys once they are already created?
saavagebueno added the waiting-feedbacktriage-needed labels 2026-08-05 01:06:46 -04:00
Author
Owner

@NightHammer1000 commented on GitHub (Nov 21, 2024):

In addition to that, /api/setup-keys/{keyId} - Retrieve a Setup Key does also not work at all in our setup. No matter what ID i try to get we always get the Response

{"message":"setup key: cqaj8pd6m1gc7385f0a0 not found","code":404}

Its always the same. No matter what ID we throw at the API. I could input random Numbers and Letters and it will also return this exact response

<!-- gh-comment-id:2491485631 --> @NightHammer1000 commented on GitHub (Nov 21, 2024): In addition to that, /api/setup-keys/{keyId} - Retrieve a Setup Key does also not work at all in our setup. No matter what ID i try to get we always get the Response {"message":"setup key: cqaj8pd6m1gc7385f0a0 not found","code":404} Its always the same. No matter what ID we throw at the API. I could input random Numbers and Letters and it will also return this exact response
Author
Owner

@pascal-fischer commented on GitHub (Nov 21, 2024):

Hi @NightHammer1000,
the behaviour of the list setup-keys api is correct. From now on all setup-keys will be hashed in the database and only the 5 digit secret will be stored. As the keys are now hashed there is no way of retrieving existing keys after they have been created. This is done to improve security so even with access to the database no one will be able to get a hold of the key except the user creating it.

Regarding the /api/setup-keys/{keyId} always returning not found, for me it is the same. I will have a look into whats going wrong here. Thanks for reporting this!

<!-- gh-comment-id:2491894304 --> @pascal-fischer commented on GitHub (Nov 21, 2024): Hi @NightHammer1000, the behaviour of the list setup-keys api is correct. From now on all setup-keys will be hashed in the database and only the 5 digit secret will be stored. As the keys are now hashed there is no way of retrieving existing keys after they have been created. This is done to improve security so even with access to the database no one will be able to get a hold of the key except the user creating it. Regarding the /api/setup-keys/{keyId} always returning not found, for me it is the same. I will have a look into whats going wrong here. Thanks for reporting this!
Author
Owner

@NightHammer1000 commented on GitHub (Nov 22, 2024):

Okay. This is kinda bad for us. Thanks for the Info anyway!

As we Previously used the Setup Keys to place the Devices in their respective Groups Automatically to make use of the Policys.

I guess we can work around it in our Setup Script by first pulling a List of Groups from which our Install Engineer can choose the correct one from and then creating a one time use Key for that Group instead of pulling the Multi-Use Key from API.

Will Create Setup Key return the full key? Or also just the Hashed one?

Also. This change should definetly be reflected at https://docs.netbird.io/api/resources/setup-keys before more people waste their expensive time ^^

<!-- gh-comment-id:2493053030 --> @NightHammer1000 commented on GitHub (Nov 22, 2024): Okay. This is kinda bad for us. Thanks for the Info anyway! As we Previously used the Setup Keys to place the Devices in their respective Groups Automatically to make use of the Policys. I guess we can work around it in our Setup Script by first pulling a List of Groups from which our Install Engineer can choose the correct one from and then creating a one time use Key for that Group instead of pulling the Multi-Use Key from API. Will Create Setup Key return the full key? Or also just the Hashed one? Also. This change should definetly be reflected at https://docs.netbird.io/api/resources/setup-keys before more people waste their expensive time ^^
Author
Owner

@pascal-fischer commented on GitHub (Nov 22, 2024):

Yes when creating a new setup key it will still return the full key for you to copy. The hashed one is only used in the database itself and for other GET calls we will return only the first 5 digits of the key for you to compare with your copy.

Sorry that you lost time on this, we missed the API docs update. The PR I created also includes an update for the openAPI specs so that the docs generation will be updated once the PR is merged.

<!-- gh-comment-id:2493298598 --> @pascal-fischer commented on GitHub (Nov 22, 2024): Yes when creating a new setup key it will still return the full key for you to copy. The hashed one is only used in the database itself and for other GET calls we will return only the first 5 digits of the key for you to compare with your copy. Sorry that you lost time on this, we missed the API docs update. The PR I created also includes an update for the openAPI specs so that the docs generation will be updated once the PR is merged.
Author
Owner

@nazarewk commented on GitHub (Apr 28, 2025):

Hello @NightHammer1000,

We're currently reviewing our open issues and would like to verify if this problem still exists in the latest NetBird version.

Could you please confirm if the issue is still there?

We may close this issue temporarily if we don't hear back from you within 2 weeks, but feel free to reopen it with updated information.

Thanks for your contribution to improving the project!

<!-- gh-comment-id:2835668759 --> @nazarewk commented on GitHub (Apr 28, 2025): Hello @NightHammer1000, We're currently reviewing our open issues and would like to verify if this problem still exists in the [latest NetBird version](https://github.com/netbirdio/netbird/releases). Could you please confirm if the issue is still there? We may close this issue temporarily if we don't hear back from you within **2 weeks**, but feel free to reopen it with updated information. Thanks for your contribution to improving the project!
Author
Owner

@NightHammer1000 commented on GitHub (Apr 29, 2025):

Well calling it an Issue when this has become a feature is not quite right.
We worked around it with way more API work. The way we do it now works for us. So I guess we can close this.

<!-- gh-comment-id:2838301554 --> @NightHammer1000 commented on GitHub (Apr 29, 2025): Well calling it an Issue when this has become a feature is not quite right. We worked around it with way more API work. The way we do it now works for us. So I guess we can close this.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#6112