Authentication methods
Palo Alto Networks SSH Manager · vSSH CLI
Every vSSH command that talks to SSH Manager needs an access token. vSSH obtains one for you based on the --auth flag, uses it for the command, and then revokes it. This page explains each method and when to use it.
| Method |
--auth value |
Best for |
|---|---|---|
| Automatic |
auto (default) |
Everyday use. vSSH asks the server which methods are enabled and picks one. |
| Username and password | userpass |
Interactive use when SSO is not configured. |
| Browser (SSO) | browser |
Interactive use with single sign-on and MFA. |
| JWT federation | jwt |
CI/CD and other automation, with no static secret. |
| Access token | (any, with --token) |
Scripts and short-lived automation that reuse a token. |
Two settings apply to all of them:
-
--client-id(defaultvssh-cli) is the OAuth client that SSH Manager recognizes. -
--scope(defaultssh:manage) is the permission the token is granted. Request the smallest scope that the task needs.
auto is the default. vSSH queries SSH Manager for the enabled authentication methods and uses one, preferring password authentication when it is available and falling back to browser SSO. Use it unless you have a reason to force a specific method.
vssh loginAuthenticate with a username and password.
vssh login --auth userpass --user alice
? Enter password for user alice: ************The username comes from --user, then the profile, then the current OS user. If you do not pass a password, vSSH prompts for it. Do not put a password on the command line.
Authenticate through your identity provider in a browser, using the OAuth 2.0 device-code flow. vSSH opens the browser and shows a one-time code, and you complete sign-in (including MFA) there. This keeps credentials with the identity provider and out of the terminal.
vssh login --auth browserUse --browser to control which browser opens.
Exchange a JWT issued by an external identity provider for an SSH Manager access token. This is the recommended method for pipelines, because the pipeline already has a short-lived, verifiable identity token and there is no long-lived secret to store.
vSSH reads the JWT from, in order:
-
VSSH_JWTenvironment variable (preferred). -
--jwt-file(a file containing the JWT).
# GitLab CI exposes a job token as CI_JOB_JWT
VSSH_JWT=$CI_JOB_JWT vssh certificate enroll svc-account1 \
--auth jwt \
--url https://tpp.example.comvSSH checks the JWT format and claims locally, logs only non-sensitive metadata, and sends it to SSH Manager, which remains the authority that validates and accepts it. See CI/CD automation for full pipeline examples.
If you already have an access token, pass it directly. vSSH uses it as-is and does not revoke it, because you own its lifecycle.
export VSSH_TOKEN=$(vssh service token obtain --no-prompt)
vssh certificate enroll svc-account1Get a token with vssh service token obtain, store it in a profile with --store-to-profile, and revoke it with vssh service token revoke.
Understanding when a token is revoked matters for both security and automation.
- When vSSH mints a token to run a command (
auto,userpass,browser, orjwt), it revokes that token when the command finishes. Nothing long-lived is left behind. - When you supply a token yourself with
--tokenorVSSH_TOKEN, vSSH does not revoke it. You control it. -
vssh service token obtaindeliberately keeps its token so you can reuse or store it. Revoke it yourself withvssh service token revoke.
Security note: Prefer
browserfor people andjwtfor machines. Both avoid storing a reusable secret. When you must use a token, scope it narrowly, store it in a protected profile or secret store, and revoke it as soon as it is no longer needed.