Manage Device Credentials in rConfig V8 Core

Credential sets in rConfig V8 Core let you store one username, password, and enable password centrally, then reuse them across many devices instead of repeating the same login details on every device record. After reading this page you will understand how a device resolves the credentials it connects with, how those secrets are stored, and how they are exposed through the interface and the REST API.

Credential sets live under Settings → Credentials.

What a credential set is

A credential set is a named bundle of connection details that rConfig uses when it logs into a device to retrieve a configuration. Each set holds:

• Name: a unique label you choose, for example core-switches-rw or lab-readonly.
• Description: optional free text to record what the set is for.
• Username: the login account used for SSH or Telnet.
• Password: the password for that account.
• Enable password: the secondary password used to reach privileged mode on platforms that need one. Leave it blank when the platform does not use one.

The value of a set is maintenance. When a shared service account password changes, you update one credential set rather than editing every device that uses it.

How a device decides which credentials to use

Every device record has both its own inline credential fields and an optional link to a credential set. rConfig resolves this at connection time, once per download, and the rule is simple.

• If the device has no credential set assigned, rConfig uses the username, password, and enable password stored directly on the device record.
• If the device has a credential set assigned, the set’s values are used instead for that connection. The values on the device record are ignored for the duration of the run.

The set overrides, it does not copy

Assigning a credential set does not rewrite the credential fields on the device record. The set is read fresh each time rConfig connects, so the device record may still show older inline values. Those stale values only come back into play if you later unassign the set.

This resolution happens on every download, which is what makes central rotation work: change the password on the set, and the next scheduled or manual backup for every device using that set picks up the new value with no per-device edits.

When to use credential sets

Use a credential set whenever more than one device shares a login. Typical cases:

• A TACACS or RADIUS service account used across an entire estate.
• A per-site or per-tenant account shared by the devices in that location.
• A read-only account for backups, kept separate from an interactive admin account.

Keep credentials inline on the device record when a device genuinely has a unique local login that nothing else shares.

Prerequisites

• An rConfig V8 Core login.
• The device login details you intend to store, ideally an account provisioned specifically for configuration backups rather than a personal admin account.

Viewing credential sets

Open Settings → Credentials to see every set defined in your instance. The listing shows each set’s ID, name, description, the devices currently attached to it, and when it was created. You can sort and filter the list by name.

Secrets are not shown in the listing. The username, password, and enable password are only revealed when you open a set with the Edit action, which prefills the form with the current values.

Adding a credential set

1. Open Settings → Credentials and click Add.
2. Enter a unique name. Names must be at least 3 characters and cannot repeat an existing set.
3. Optionally add a description to record the purpose of the set.
4. Enter the username (at least 3 characters), the password, and the enable password if the platform requires one.
5. Click Save.

The set becomes immediately available in the credential dropdown on the device add and edit forms.

Use a dedicated backup account

Give rConfig its own service account rather than a shared personal login. It keeps device-side audit logs meaningful, it survives staff changes, and it lets you grant only the privileges the backup commands actually need.

Editing a credential set

1. Locate the set in the credentials listing.
2. Click the Edit action.
3. Update any field, then click Save.

Edits apply to every attached device on the next run

A credential set is read at connection time, so a change takes effect for every attached device on its next backup. If you save an incorrect password, every device using that set will start failing to connect. Verify the change with a single on-demand download before the next scheduled task window.

Deleting a credential set

1. Locate the set in the credentials listing.
2. Click the Delete action and confirm.

A set that still has devices attached cannot be deleted. rConfig blocks the delete and reports that related devices exist. Reassign those devices to another set, or move them back to inline credentials, then retry.

Deletion is permanent. The stored secrets are not recoverable afterwards.

Assigning a credential set to a device

1. Open the device create or edit form.
2. Select the set from the credentials dropdown.
3. Save the device record.

To move a device back to its own inline credentials, clear the credential set selection and populate the username, password, and enable password fields on the device itself.

How credentials are stored

Credential secrets are encrypted before they are written to the database. The password and enable password columns hold ciphertext, not readable text, and are decrypted only when rConfig needs them: to connect to a device, or to display them back to you in the interface.

Encryption uses your installation’s APP_KEY.

Never change or lose APP_KEY

Every stored credential is encrypted with APP_KEY. If that key is changed or lost, existing credential secrets cannot be decrypted and every affected set must be re-entered by hand. Back the key up with your database, and keep it out of version control.

Encryption at rest protects your database backups and any copy of the data that leaves the server. It does not restrict who can read credentials through the application itself, which is covered next.

Who can read credentials

rConfig V8 Core has a single access level: every authenticated user has the same rights across the application. There is no per-user or per-role restriction on the credentials screen, so any user who can sign in can open a credential set with the Edit action and read the stored username, password, and enable password in full.

Treat an rConfig login as equivalent to your device passwords

Because any signed-in user can read stored device credentials, an rConfig account is as sensitive as the network passwords it holds. Create accounts only for people who are already trusted with device access, remove accounts promptly when someone leaves, and keep the instance off any untrusted network. Role-based restriction of credential visibility is a Pro edition capability, documented at docs.rconfig.com.

REST API restriction

Device credential secrets are never returned in readable form by the REST API. The /api/v1/device-credentials endpoints mask the password and enable password on both the list and single-record responses, returning the first two characters followed by asterisks:

{
  "id": 1,
  "cred_name": "core-switches-rw",
  "cred_username": "netbackup",
  "cred_password": "Su*************",
  "cred_enable_password": "en**********"
}

What this means in practice:

• You can use the API to inventory credential sets: list them, see their names, usernames, and descriptions, and see which devices are attached.
• You cannot use the API to read a stored password back out. There is no endpoint, parameter, or header that returns the cleartext value.
• You can still create and update credential sets through the API. Writes accept cleartext values, and the response confirms the change without echoing the secret back.
• Masking is unconditional. It is not controlled by the MASK_DEVICE_CREDENTIALS setting, which governs the device endpoints only and cannot re-enable cleartext secrets on the credential endpoints.
• A blank enable password stays blank in the response rather than being replaced by asterisks, so you can still tell which sets have no enable password configured.

Why the API is stricter than the interface

An API token is a long-lived, portable secret that often lives in a script, a scheduler, or a CI pipeline. Masking means a leaked token cannot be turned into a list of working device passwords, even though the interface shows those same values to a signed-in user.

If you need to move credentials between rConfig instances, re-enter them through the interface or the API write endpoints rather than trying to export them.

Common gotchas

Watch for these credential pitfalls

• Backups start failing across many devices at once after a credential edit. This is the expected blast radius of a shared set. Check the set’s password first, before investigating individual devices.
• A device still fails to connect after you fix its inline credentials. Confirm no credential set is assigned to it, because an assigned set overrides the inline fields at connection time.
• A delete that fails with a related devices error means devices are still attached. Filter the device list, reassign them, then retry the delete.
• Duplicate sets holding the same account fragment your rotation. When the password changes you have to remember to update every copy. Consolidate onto one set and reassign the devices.
• An API response showing asterisks is not a fault. The API masks secrets by design, as described above.
• A device that needs no enable password should have the enable password left blank rather than filled with a placeholder, so failures are easier to read.

What’s next

• Add and manage devices to assign credential sets to your inventory.
• Set up connection templates to control how rConfig connects once it has authenticated.
• Troubleshoot device connectivity when a device fails to authenticate.
• REST API guide for token creation and the wider API surface.