SSH Command Restrictions

How SSH Command Restrictions Work

SSH command restrictions narrow what happens after authentication succeeds. Instead of granting a full shell, the server or key policy can force a single program, wrap the session in a restricted shell, or constrain what an ssh key may execute through authorized_keys options.

That design matters because SSH access is often treated as equivalent to trust. Command restriction breaks that assumption by separating “can log in” from “can run anything”, which is especially useful for automation, jump hosts, and delegated operational access.

Where They Are Enforced

Restrictions can be applied at several layers, and the layer matters. A forced command in authorized_keys is tied to a specific key, while a restricted shell applies to the account itself, and server-side policy can add another boundary after authentication. The same session may therefore be limited by more than one control.

Because these controls live at the session boundary, they are only as strong as the surrounding SSH configuration. If the account can still invoke an unrestricted shell through another path, or if the key is reused elsewhere, the restriction becomes partial rather than absolute. For that reason, SSH command restrictions are usually paired with careful SSH key management.

What They Protect Against

The main security value is containment. If an SSH key is stolen, copied, or mistakenly shared, the attacker should not automatically gain an interactive administrative foothold. Instead, the session can be limited to a backup job, file transfer action, build step, or other narrowly defined task.

They also reduce damage from legitimate-but-overpowered access. Many operational keys are issued for convenience and later become persistent privileges. Restricting commands limits lateral movement, prevents ad hoc exploration, and reduces the chance that a routine automation account becomes a general-purpose entry point.

Why They Need Careful Design

SSH command restrictions are security controls, not a complete trust model. If the forced command launches a script, the script becomes part of the attack surface. If the shell remains too flexible, the user may still escape into other programs, chain commands, or abuse environmental variables and file permissions.

The control is strongest when the allowed action is tightly scoped, the account owns no unnecessary privileges, and the surrounding host hardening supports the restriction. That is why the same pattern can be excellent for a single-purpose deployment key and weak for a broadly shared administrator account.

Risk and Threat Considerations

Command restrictions matter because a stolen SSH key often remains usable long after the original compromise. Without a forced-command boundary, that key can become an easy path to full shell access, privilege escalation, or automation abuse. With weak restriction design, the attacker may still pivot through the permitted command into broader execution.

Failure mechanism: The restriction fails when the allowed command is too powerful, the wrapper script is bypassable, or the key is reused in a context that permits broader execution than intended.

Impact: A compromise that should have been contained to one task can turn into unauthorized command execution, persistence, data access, or service disruption.

Practitioner Guidance

Why practitioners should care: Treat SSH command restrictions as a privilege boundary, not just a convenience feature. They are most effective when a key or account exists for one operational purpose and should never be allowed to drift into general login access.

Governance implication: Define ownership for every restricted key, review whether the allowed command still matches the business purpose, and remove orphaned or duplicated access paths when the use case changes.

Practitioner takeaway: If the session can do more than the intended task, the restriction is not strong enough to be relied on as a control.

Related resources from NHI Mgmt Group

• How should security teams harden SSH without relying on port changes alone?
• When does SSH forwarding create more risk than value?
• What is the difference between changing port 22 and real SSH hardening?
• Should organisations use SSH certificates instead of long-lived keys?