An authorized_keys entry can restrict a public key to a fixed command, disable terminal allocation, and turn off forwarding features. These options are useful for backup agents, deployment hooks, and narrow administrative paths. They are not a complete authorization system by themselves. The command, the key's owner, the environment it inherits, and the server configuration all affect what the key can actually do.
The OpenSSH restrict option is a convenient starting point because it disables several interactive and forwarding features. A hard-coded command= option then supplies the command to run when the key authenticates. If the intended design needs to accept an original client request, the forced command receives it via SSH_ORIGINAL_COMMAND and must validate it with the same care as any untrusted input. Passing that value to a shell is usually a mistake.
Treat the key as an identity
A public key is an authentication factor, not a job title. The authorized key file should make the expected principal and purpose clear in comments and in the account design. Use a separate Unix account or service identity where the consequences of command execution differ. If two integrations need different file paths or different privilege levels, do not let them share one key because their command strings happen to look similar.
Review the account's shell and server-wide settings. A forced command may be superseded by a ForceCommand in sshd_config, and global forwarding or environment options can change the assumptions made by a key entry. Test the effective behavior from the server's configuration rather than reading only the line that was recently added.
Validate the command path
The fixed command should use an absolute, trusted binary and explicit arguments. The binary should not read attacker-controlled configuration from the working directory. Set a controlled working directory, clear or replace risky environment variables, and avoid relying on the login shell's profile. If the command launches another process, the same rules apply to that child.
For an integration that accepts parameters, parse a narrow grammar instead of splitting a shell string. Allow exact subcommands and validated values. Reject newlines, shell metacharacters, path traversal, and unexpected options unless the program's interface requires them. Return a clear error without echoing secrets or full command lines.
Test the restrictions
Connect with the key and inspect whether the command and options behave as documented. Then try the things the policy is supposed to prevent:
requesting an interactive shell
forwarding an agent or port
requesting X11 forwarding
asking for a pseudo-terminal
sending a command string that the forced wrapper should reject
accessing a path outside the integration's intended directory
Repeat the test after an OpenSSH upgrade or a change to the account's groups. The key options and server configuration are versioned policy. A restriction that worked in a test container may behave differently on the production host.
Keep lifecycle and evidence together
Associate each key with an owner, purpose, creation date, expiry or review date, and the systems it can reach. Remove the key when the integration ends. Rotate it on a schedule that matches the risk, and immediately after a suspected compromise. Do not simply add a second key and leave the old one active.
Log authentication, forced command execution, and authorization failures without recording private key material or secrets. Alert on unexpected source addresses and repeated denied commands. Keep enough context to answer whether the key was used for the intended operation, from the expected host, at the expected time.
The powerful part of an SSH key is not its text. It is the account, command path, environment, and server policy that accept it. A forced command is a sound control when it is part of that complete boundary. A line copied into authorized_keys without tests and lifecycle ownership is only a hopeful restriction.