Forced Command is an SSH configuration that restricts a key or account to run only a specified command after login. It is used for tightly scoped automation and can stop interactive shell access even if the key is stolen. Administrators should pair it with least privilege, auditing and command validation.
What Forced Command actually changes in an SSH login
Forced Command changes the post-authentication behavior of an SSH session. The key or account still authenticates, but the server ignores a user-chosen shell and runs only the command attached to that key or account. That makes it useful for tightly scoped automation, but it also means the command itself becomes part of the security boundary.
Because the login no longer opens an interactive shell, the main question shifts from “can this identity log in?” to “what can this identity make the server do?” In practice, the restricted command is often a wrapper script or fixed operational task, so its argument handling, environment assumptions and exit behavior matter as much as the SSH key itself.
A useful way to think about it is as an authorization constraint at the session layer. The SSH authentication step proves possession of the key, then the server constrains the resulting session to a single action. That can reduce blast radius for automation accounts, but only if the command path is not a back door to broader shell access, file writes or privilege escalation.
Why it is used for automation, not general login
Forced Command is best suited to repeatable jobs such as backup pulls, deployment hooks, certificate renewal tasks or one-way data collection. In those cases the operator wants a credential that can execute one known action, and nothing else. It is a narrow control, not a full access model, so it works best when the task is already well defined and the input space is small.
The control is especially valuable when the automation target is reachable over SSH but does not need a human operator’s interactive privileges. If the same key were allowed to open a shell, anyone who obtained it could usually explore the server, chain commands, and use the account for purposes far beyond the original job. Forced Command narrows that exposure by removing the shell as the default outcome.
This is why the control is often paired with constrained sudo rules, read-only filesystems, restricted directories or a dedicated service account. The value comes from the combination, not from the SSH directive alone. A forced command that can spawn a shell, call an unrestricted interpreter or invoke broad system utilities is still too permissive for most automation use cases.
Where the control fails in practice
Forced Command is only as strong as the command it launches and the identity material that triggers it. If the script accepts unsafe arguments, shells out unsafely, or exposes environment variables, an attacker with the key may still reach unintended functionality. The control also does not help if the account already has local privilege, broad filesystem rights or access to sensitive downstream systems.
When the key is stolen, the attacker gains whatever the forced command can do, even if interactive shell access is blocked. That means the real security question is the task’s effective privilege, not whether a shell prompt appears. In environments that use shared automation hosts or reusable keys, that privilege can be larger than teams expect because the command often has been tuned for convenience over containment.
It also matters how the command is validated and logged. A fixed command with no telemetry can hide abuse, while a logged wrapper that records invocation parameters, source host and outcome gives responders a much better chance of spotting misuse. If the command performs writes, publishes artifacts or reaches other systems, those downstream actions should be treated as part of the trust boundary.
Risk and Threat Considerations
Forced Command reduces one obvious risk, but it does not eliminate compromise if the underlying key is exposed or the command path is unsafe. The main threat is abuse of a trusted automation credential to run a bounded but still harmful action, especially where the command can read secrets, alter files or trigger operational workflows.
Failure mechanism: An attacker who steals the key, or who can influence the forced command wrapper, may exploit argument handling, environment inheritance, writable paths or helper utilities to expand a narrow command into broader execution or data access.
Impact: The likely outcome is unauthorized automation activity, data exposure, integrity loss or a pivot into other systems that trust the command’s output or side effects. The control shrinks blast radius only when the command cannot be repurposed into a general-purpose execution path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH forced-command use depends on tightly managed key lifecycle and revocation. |
| AC-6 — Least Privilege | Forced Command is only safe when the resulting session has minimal effective privilege. | |
| Recommendation — Rotate, revoke and scope SSH authenticators so a stolen key cannot outlive its intended command. Limit the account and command path to the smallest set of actions needed for the automation task. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | An SSH automation key is a non-human credential that becomes risky when its command can do too much. |
| NHI-07 — Long-Lived Secrets | SSH keys used with forced commands are still secrets whose lifetime affects exposure if stolen. | |
| Recommendation — Reduce the automation identity’s reachable actions until a stolen key cannot perform broader work. Shorten credential lifetime and replace long-lived SSH keys where possible. | ||
| NIST CSF 2.0 | PR.AA-05 — Managed Access Control | The topic centers on constraining what an authenticated session is allowed to do. |
| Recommendation — Enforce role- and task-specific access so authenticated SSH sessions can only execute the intended command. | ||
Practitioner Guidance
What to verify: Confirm that the forced command is genuinely non-interactive, cannot launch a shell, and cannot be redirected into alternate code paths through arguments, environment variables or command substitution. If the wrapper script is configurable, treat that configurability as part of the attack surface.
Decision rule: If the command can authenticate to anything beyond the immediate task, rotate the design toward a narrower account, shorter-lived credentials, tighter filesystem permissions and explicit output validation. If you cannot describe the command’s maximum effect in one sentence, it is probably too broad for a forced-command pattern.
Practitioner takeaway: Forced Command is a containment control, not a trust substitute. It is effective when the command is tightly bounded, observable and hard to repurpose, and weak when the wrapped action itself carries broad privilege.