Credential separation
How Portivo separates personal, monitoring, automation and webhook secrets.
Personal SSH session
User-supplied SSH credentials exist for the active personal session. They are not stored as general shared switch credentials.
Monitoring Credentials
Reusable encrypted SSH or SNMPv3 profiles support unattended read-only health collection. They are separate from personal SSH and Automation credentials.
SNMPv3
The UI configures SNMPv3 authPriv. New profiles prefer SHA-256 authentication. SHA is labeled Legacy. Privacy offers AES/AES-128 and DES (Legacy).
Automation credential
Scheduled actions use a dedicated SSH service account encrypted at rest with the application secret.
Webhook endpoints
Webhook destination URLs are treated as secrets, encrypted with APP_SECRET_KEY, masked after save and not returned in clear text through normal API/Audit paths.
APP_SECRET_KEY when restoring a Portivo database. Replacing the application secret prevents stored encrypted endpoints/credentials from being decrypted.Credential classes and permitted use
Personal SSH credentials authenticate an interactive user and are encrypted only in server-process memory for the active session. They are not converted into shared inventory credentials. Monitoring profiles are encrypted reusable credentials for configured read-only SSH or SNMPv3 checks. Automation credentials are separately encrypted service identities used only when scheduled work executes.
Verification targets are explicit. SSH profiles can be checked against managed switches; SNMPv3 authPriv profiles can be checked against switches or UPS assets with a read-only system-description request. Verification proves reachability and authentication for that target, not universal authorization across the fleet.
Operational rule
Never rely on fallback between credential classes. A failed schedule must not borrow a user's personal session, and interactive work must not silently use the unattended service identity.