Password vaulting SSO: stored accounts and rotation in Remote Access

This page is for the administrator who manages the accounts SSOGEN uses to sign people in to remote hosts. Adding the resource itself is in Remote Access to SSH, RDP and VNC hosts.

Who can do this. A Super admin stores, replaces and removes a stored account. Administrators with the Application admin, Security audit reader or Read-only admin role can see that an account is stored, for which user name, by whom and when, but cannot change it. Nobody, in any role, can read a stored password or private key back.

What is needed first. A saved resource whose host is trusted (pinned): see Host keys and certificates. On the host: the account itself, and for a key either its private key file or the ability to add a line to the account’s authorized_keys file.

The result. People open the resource and land in a session without typing an account. The account’s password or key stays in SSOGEN, is handed to the Gateway for one session at a time, and only when the host has proved its identity.

The examples use the fictional company Acme Corp, the server Acme Build Server (SSH) and the host account deploy.

What a stored account is

One account per resource. Everyone who opens the resource is signed in as that account. There are no per-person stored accounts; if people must sign in as themselves, choose User types it and each person enters their own account when the session opens.
Write-only. It is entered once and never shown again, in the console or anywhere else.
Three kinds. A Password; an uploaded Private key (SSH only); or a key SSOGEN generates for you (SSH only, recommended), of which it keeps the private half and shows you one line for the host’s authorized_keys.
Released only to a verified host. The console’s own words: “A stored account is released only to a host that proves who it is. Pin the host’s key (SSH), or its certificate with Network Level Authentication (RDP), or use an encrypted VNC method with a pinned certificate. Plain VNC passwords cannot be stored.”
Tied to the host as you stored it. A stored password belongs to one host, port, connection path and trusted host identity. If any of these changes, SSOGEN clears the password rather than send it somewhere else. A stored key is kept.

Store an account

In the Admin Console, choose Secure access > Remote Access and open the resource.
On the Overview tab, under Who signs in to the host, choose Stored account (“SSOGEN keeps one account for this resource and signs people in without a prompt. It is never shown again.”). On an SSH resource whose host is not yet pinned, the page lists what must happen first:
1. “Save the resource, with User types it unless you entered the host key fingerprint.”
2. “Pair the host and trust its key, in Pair and test the host.”
3. “Save the resource with Stored account selected.” Each step shows “Done.” once it is, and “Next:” points to the one to do.
Fill in the account:

Field	What to enter
How SSOGEN signs in (SSH only)	Generate a key (recommended), Upload a private key or Password. RDP and VNC take a password.
Account name	The account on the host, for example `deploy`.
Domain (optional) (RDP only)	The Windows domain of the account, if it has one.
Password	For the Password method.
Private key file	For Upload a private key: “OpenSSH or PKCS#8: Ed25519, ECDSA P-256 or P-384, or RSA of at least 2048 bits.”
Passphrase (only if the key is encrypted)	“The passphrase decrypts the key once, here. Neither is shown again.”

Select Store password, Store key or Generate key.
- For a generated key, the page shows an authorized_keys line field with a copy button: “Add this one line to the account’s authorized_keys file on the host. It is shown only now.” Add it to the deploy account’s authorized_keys on build01.acme.example before you leave the page.
The section now reads “A password is set” or “A key is set”, followed by “for deploy on 2026-11-09 by Pat Chen.” and, for a key, “Key SHA256:…” (the fingerprint of its public half).
If you changed Who signs in to the host, select Save resource.

Replace a password or key (rotation)

SSOGEN does not rotate a stored account on a schedule and does not change the account on the host. Rotation is two steps that you do: change the credential on the host, and store the new one in SSOGEN. Until both are done, sessions on the resource fail with “The host did not accept the account your administrator stored for it. Ask your administrator.”, and the console shows “The host refused the stored account. Replace the password or key, or fix the account on the host.”

Replace a password

Change the account’s password on the host.
Open the resource, and in the Stored account section select Replace.
Enter the Account name and the new Password (and Domain (optional) on RDP), then select Store password.
The line now shows the new date and your name.

Rotate a generated key without an outage

Open the resource and select Replace, keep Generate a key (recommended), enter the Account name and select Generate key.
Copy the new authorized_keys line and add it to the account’s authorized_keys on the host. From the next session SSOGEN signs in with the new key.
Remove the old key’s line from authorized_keys on the host.

The old private key is gone from SSOGEN the moment the new one is stored; sessions that are already open are not affected.

Replace with an uploaded key

Select Replace, choose Upload a private key, pick the Private key file (and its Passphrase if encrypted), and select Store key. The host must already accept that key’s public half.

Remove a stored account

In the Stored account section, select Remove.
The dialog Remove the stored account? says: “People can no longer open this resource without typing an account until you store another.” Select Remove account.
Either store another account or change Who signs in to the host to User types it and save the resource.

Removing the resource removes its stored account with it.

When SSOGEN clears a password by itself

If you save the resource with a different Host, Port, Gateway group or Reach through, or trust a different host identity (a pin added, replaced or removed, or verification turned off), a stored password is cleared. The save dialog warns first: “Saving this removes the stored password, because it was stored for the host identity or address this save changes. Store it again after trusting the host.” with the button Save and remove. Afterwards the resource shows “The stored password was cleared because the host, port, connection path or trusted host identity changed. Enter it again; until then people cannot open this resource.” A stored key survives such a change.

What is recorded

Every change is in the resource’s Timeline and in Monitoring > Audit, with the administrator’s name, never with the password or key:

Event	When
Stored account set	An account was stored or replaced
Key generated	SSOGEN generated a key; the record holds the public key’s fingerprint only
Stored account removed	Remove account was confirmed
Stored password cleared because the destination or the trusted host changed	A save changed what the password was stored for (“Cause: the host, port or connection path changed”, “Cause: the trusted host identity changed”, or “Cause: the resource no longer matched what the password was stored for”)
Stored account released to the Gateway for one session	A session used the account; the row names the session, not the secret
Sign-in to the host failed	The host refused the account

See Remote Access session audit.

Check it worked

The Stored account section reads “A password is set” or “A key is set” “for deploy on … by …”.
Open the resource from My Apps as a person who may use it. The status goes Connecting, Signing in to the host, Active, with no account prompt.
The session’s Timeline shows Stored account released to the Gateway for one session and then Signed in to the host.

Troubleshooting

What you see	What it means	What to do
“An account is stored only for a resource saved with Stored account selected and the host’s key pinned. Pair and trust the host, save the resource with Stored account selected, then store the account.”	The resource is not ready for a stored account.	Follow the three numbered steps on the page.
“This resource does not yet allow that way of signing in. Save the resource with Stored account selected, then store the account again.”	Stored account was chosen but not saved.	Select Save resource, then store the account.
“Stored account: a stored account is given only to a verified host. Choose Verify the host.”	The resource is set to not verify the host.	Under Host identity, choose Verify the host (recommended) and pin the host.
“That key is encrypted. Enter its passphrase; it is used once to decrypt the key and is not kept.” / “That passphrase does not open the key.”	The uploaded key needs its passphrase, or the passphrase is wrong.	Enter the passphrase.
“That key is too weak. Use Ed25519, ECDSA P-256 or P-384, or RSA of at least 2048 bits.” / “That file is not a private key SSOGEN can use. …”	The file is not accepted.	Use a supported key, or Generate a key.
“Enter the account name.”	The Account name is empty.	Enter it.
“The host refused the stored account. Replace the password or key, or fix the account on the host.”	The host rejected the sign-in.	Check the account on the host (password, `authorized_keys`, whether it is locked), then Replace.
“The stored password was cleared because the host, port, connection path or trusted host identity changed. Enter it again; until then people cannot open this resource.”	A save changed what the password was stored for.	Store the password again.
A person sees “The stored account could not be used right now. Try again in a moment; if it keeps happening, ask your administrator.”	The account could not be handed to the Gateway for that session.	Check that the host’s identity is pinned and that it presented the pinned key; see the session’s Timeline.
“This server has no secrets key set up, so it cannot store an account.”	SSOGEN has no secrets store configured.	Finish the installation’s secrets setup before storing accounts.
“Only a Super Admin can change this.”	Your role cannot change stored accounts.	Ask a Super admin.