Forced SSH commands still need a complete key policy

Authorized_keys entries can restrict a public key to a single command, disable terminal allocation, and turn off forwarding features. However, these options alone are insufficient for comprehensive authorization. The command, key owner, inherited environment, and server configuration all influence the key's actual functionality.

The OpenSSH restrict option disables several interactive and forwarding features, providing a starting point. A hard-coded command= option then specifies the action to take upon key authentication. If the design requires processing an original client request, the forced command must receive it via SSH_ORIGINAL_COMMAND and validate it securely, avoiding the mistake of passing it to a shell.

Public keys serve as authentication factors, not job titles. The authorized key file should clearly indicate the expected principal and purpose, either through comments or account design. Each key should correspond to a unique Unix account or service identity, especially when consequences of command execution vary. Shared keys for integrations with different file paths or privilege levels are discouraged.

The shell and server-wide settings should be reviewed, as a forced command may be overridden by ForceCommand in sshd_config, and global forwarding or environment options can alter key assumptions. The effective behavior should be tested in accordance with the server's configuration, not just the recently added line. The fixed command should use an absolute, trusted binary with explicit arguments, avoiding attacker-controlled configuration from the working directory.

A controlled working directory, clearance of risky environment variables, and avoidance of reliance on the login shell's profile are recommended. If the command spawns another process, the same rules apply to that child. When integrations accept parameters, a narrow grammar should be parsed instead of splitting a shell string. Exact subcommands and validated values should be allowed, while newlines, shell metacharacters, path traversal, and unexpected options should be rejected unless required by the program's interface.

Clear errors without echoing secrets or full command lines should be returned. After establishing restrictions, connect with the key and verify if the command and options align with the documented policy. Subsequently, attempt actions that the policy aims to prevent, such as requesting an interactive shell, forwarding an agent or port, enabling X11 forwarding, requesting a pseudo-terminal, or sending a command string that the forced wrapper should reject.

Accessing a path outside the integration's intended directory should also be tested. Repeat these tests following an OpenSSH upgrade or a change to the account's groups, as the key options and server configuration constitute versioned policy. Each key should be associated with an owner, purpose, creation date, expiry or review date, and the systems it can access.

Removal of the key upon integration termination is crucial, along with rotation on a schedule matching the risk and immediately after a suspected compromise. Avoid adding a second key and leaving the old one active. Authentication logs, forced command execution, and authorization failures should be logged without recording private key material or secrets.

Alerts should be triggered for unexpected source addresses and repeated denied commands. Maintaining sufficient context to determine if the key was used for the intended operation, originating from the expected host, at the expected time is essential. The core value of an SSH key lies not in its text but in the accompanying account, command path, environment, and server policy that accept it.

A forced command is a valid control measure when it forms part of this comprehensive boundary. A line pasted into authorized_keys without testing and lifecycle ownership is merely a hopeful restriction.