Guide Securing SSH access

Palo Alto Networks SSH Manager · vSSH CLI

Securing SSH access with certificates

This guide is for security teams. It explains the model vSSH uses, the controls you can put on a certificate, and how to reason about the trust boundary. Command details are in the Command reference.

Why certificates instead of keys

Static SSH keys have two problems: they do not expire, and every server needs its own copy of every authorized public key. Over time an authorized_keys file becomes a list nobody trusts, and a leaked key stays valid until someone finds and removes it everywhere.

SSH certificates change the model:

• A server trusts one certificate authority (CA), not a list of individual keys.
• The CA signs a certificate that carries an identity, an expiry, and a policy.
• When the certificate expires, access ends. There is nothing to clean up on the host.

vSSH is the client that requests these certificates from SSH Manager and puts them where SSH can use them.

The trust boundary

Trust flows one direction. A host is configured once to trust the CA public key (its TrustedUserCAKeys). After that, the host accepts any user certificate the CA signs, subject to the certificate's own restrictions and the host's AuthorizedPrincipals rules.

This has a clear consequence: the policy that matters lives in the issuance template and in the certificate fields, because the host will honor whatever the CA signed. Review templates the way you would review a firewall rule.

Short-lived credentials

The strongest control is a short lifetime. A certificate that lives for hours cannot be a long-term liability.

• Interactive logins request a session length with --session-time (default 12h). See login.
• Machine certificates set validity with --validity, bounded by the template policy. See certificate enroll.

Keep lifetimes as short as the workflow allows, and renew rather than extend. See Renewing an SSH certificate.

Least privilege on a certificate

Several certificate fields narrow what a credential can do. Set them at enrollment.

Control	Flag	Effect
Identity	--principal	The usernames the certificate is valid for. Grant only what is needed.
Source restriction	--source-address	Restrict the addresses the certificate can be used from (CIDR).
Forced command	--force-command	Run a fixed command on connect and ignore what the client asks for.
Extensions	--extension	Enable specific capabilities, for example permit-pty. Omit what you do not need, such as port forwarding.

Example: a contractor credential that can only run one tool, only from the office network, for a short time.

vssh certificate enroll contractor \
  --template "Contractors - Read Only" \
  --source-address 203.0.113.0/24 \
  --force-command "/usr/local/bin/report-viewer" \
  --validity 4h

Policy enforcement is server-side

The client flags above are conveniences, not the source of truth. Most — if not all — of these certificate attributes can be enforced by SSH Manager through the issuing template, so the client does not have to supply them. When a template defines a policy for an attribute, that policy is authoritative: the server applies it regardless of what the client sends, and any client-supplied value that conflicts is overridden or rejected at issuance. A value the client provides is only honored when the template leaves that attribute open.

The practical consequences for a security team:

• You do not have to trust clients to request the right restrictions. Encode principals, source addresses, forced commands, extensions, and validity bounds in the template, and every certificate issued from it carries them whether or not the client asked.
• A client that omits a flag still gets the policy-enforced value. A client that passes a stronger-than-policy value may keep it; a client that passes a weaker or disallowed value gets the policy value instead, or the request fails.
• This is why the template is the control plane. As noted in The trust boundary, the host honors whatever the CA signed, and what the CA signs is governed by the template — not by the client's command line.

Set client flags for the workflows that need per-request variation within policy, and rely on the template for the guarantees that must always hold.

Key strength

For locally generated keys, choose a modern algorithm.

vssh certificate enroll svc-web --key-algorithm ed25519

--key-algorithm accepts rsa, ecdsa, or ed25519. --key-size-curve sets the size or curve (2048, 3072, 4096, P-256, P-384, P-521). Protect a stored private key with --passphrase. For interactive logins, prefer keys held in the OpenSSH agent so the private key never touches disk.

Token scoping and revocation

vSSH authenticates with an access token. For people, prefer browser SSO so the identity provider enforces MFA. For machines, prefer JWT federation so there is no stored secret. See Authentication methods.

Key points for review:

• The default scope is ssh:manage. Request the narrowest scope the task needs.
• Tokens vSSH mints for a single command are revoked when the command ends.
• Tokens obtained with vssh service token obtain persist until you revoke them with vssh service token revoke. Track and revoke them.

Auditing

Certificates carry identity and are issued centrally, so SSH Manager records who requested what and when. On the host side, sshd logs the certificate identity used for each session. Together these give you an access trail without scraping authorized_keys files.

A checklist

• Templates enforce short validity and the right principals.
• --source-address and --force-command are used where access should be narrow.
• Only required --extension capabilities are enabled.
• Machines authenticate with JWT federation, people with browser SSO.
• Persisted tokens are inventoried and revoked on a schedule.
• Hosts trust only the intended CA. Confirm with vssh openssh server show.

Related pages

• Authentication methods
• SSH server administration
• Machine identity for apps and hosts
• certificate