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 — and Automatic setup tries the sets against new devices on its own.
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, plus usage: "N× succeeded · N× failed" or "not used yet" — the counters are filled by Automatic setup when probing devices.
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 → Credentials | 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 a host, editing a host or in Automatic setup — a checkbox "Save under a name and reuse" offers to turn them into a set right away. |
| Automatic setup | The start window shows the tenant's sets and creates new ones. The run tries stored SNMP v2c communities and SNMP v3 sets against every SNMP device. SSH sets are not tried in sequence — SSH is tested exactly once with the input in the task. Credentials you enter in a task that work on the device are saved as a set (without duplicates) and apply to all further devices. |
| 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.
See also¶
- Setting up SNMPv3 — fields, auto-detection, "Test connection"
- Automatic setup — trying sets against devices
- Adding hosts — credentials when creating