Skip to content

Credential sets

A credential set is a named credential (e.g. "Switches main site") stored per tenant and selectable wherever Vesana needs credentials for a device. Instead of typing the same community or SSH password for every device, you pick the set.

Types

Type Fields Note
SNMP v2c Community also used for SNMP v1 devices
SNMP v3 Username, auth password, priv password, auth protocol (optional), privacy protocol (optional) Protocols may stay empty — Vesana detects them on the device. To apply the set directly when creating a host they must be filled in. A priv password without an auth password is not possible. A security level is never stored; it follows from the passwords — see Setting up SNMPv3.
SSH User, password or private key, port (optional) password or key must be set
API token Token ID + secret covers any API access of a device, not just Proxmox: for Proxmox VE, token ID user@realm!token-name plus the secret shown once when creating it; for a device account with a username and password (e.g. an ESXi read-only account), enter the username in the token ID field and the password in the secret field

Passwords, communities, keys and tokens are stored encrypted and never shown again — the UI shows ***. When editing, leave a secret field empty to keep the stored value ("stored — leave empty to keep"); "Remove stored value" deletes it specifically.

Where you manage them

Tenants → expand the customer → section "Credentials" (collapsible; Vesana remembers what you keep open). There: the "Credentials" button to add one (type, name, fields), per set edit and delete.

Deleting removes the set permanently; hosts that already took the credentials keep them. Adding, editing and deleting requires the permission Credentials → Manage; viewing hosts is enough to select one.

Where they are used

Place Behaviour
Creating a host (wizard and expert form) For SNMP, SSH and API token: dropdown "Saved credentials" instead of typing. The server applies the values when creating — the selection only sends the reference, never the secret. For an SNMP v3 set without protocols, Vesana tells you they are missing instead of silently storing a wrong combination.
Manage host → Connection Pick saved credentials on an existing host as well. Only the accesses (SNMP, SSH, API access) that the host's checks actually need — or that are already set — are shown open; the rest sits behind "Show more credentials", never out of reach: otherwise you could no longer remove an access once it was set.
Every credential input Whenever you enter credentials anew — when creating or editing a host — a checkbox "Save under a name and reuse" offers to turn them into a set right away.
Scheduled scans and network search SNMP v2c sets are tried after the communities learned on the collector, before public — SNMP devices are identified even without a manual scan. See Discovery → SNMP settings.

Two places for SNMP communities

Collector communities (Discovery → Settings) belong to a collector and serve network search and classification. Credential sets belong to the tenant and end up on hosts. Both are tried when scanning; for new credentials the set is the better place because it is selectable everywhere.

Credentials stay with the device

Credentials stored on the host (SNMP community or SNMPv3 user, SSH password or key, API access) are only sent to the device's own addresses — IP address, DNS name, host name. If a check targets a different target (e.g. "SSH target (override)" or another URL), they are not sent; the check then reports UNKNOWN with the error code CREDENTIAL_TARGET_WITHHELD. For such a target, enter dedicated credentials directly on the check (e.g. its own community). An API token also never follows a redirect to another server.

See also