SSH User Command Restriction: Practical Security Configuration via authorized_keys

Core Mechanism of SSH Command Restriction

In Linux server security management, restricting commands that users can execute via SSH is a common requirement. Traditional permission control methods often involve complex configurations and potential security risks, while the SSH protocol itself provides a concise and effective solution. By using the command parameter in the authorized_keys file, administrators can precisely control the range of commands allowed for each SSH key.

Detailed authorized_keys Configuration

The authorized_keys file is the core configuration file for SSH public key authentication, with each line representing an authorized public key. Beyond basic public key information, this file supports various option parameters to enhance security. The command parameter specifies the command that must be executed when using that key for connection, regardless of what operation the user attempts to perform.

The basic configuration format is as follows:

command="/bin/restricted_script.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD... user@host

In this configuration, the command parameter forces all connections using this key to execute the /bin/restricted_script.sh script. Other parameters like no-port-forwarding further restrict connection capabilities, preventing users from bypassing command restrictions.

Implementing Custom Command Restriction Scripts

Creating effective restriction scripts is key to achieving fine-grained control. Below is a complete example script that allows users to execute specific predefined commands:

#!/bin/bash

# Parse parameters passed by SSH
if [ "$SSH_ORIGINAL_COMMAND" ]; then
    # Check allowed command list
    case "$SSH_ORIGINAL_COMMAND" in
        "less /var/log/app.log")
            /usr/bin/less /var/log/app.log
            ;;
        "/home/johndoe/shutdown.sh")
            /bin/bash /home/johndoe/shutdown.sh
            ;;
        "/home/johndoe/run.sh")
            /bin/bash /home/johndoe/run.sh
            ;;
        *)
            echo "Error: Command not allowed"
            exit 1
            ;;
    esac
else
    echo "Interactive login prohibited"
    exit 1
fi

This script utilizes the SSH environment variable SSH_ORIGINAL_COMMAND, which contains the original command the user attempted to execute. The script performs exact matching through a case statement, allowing only predefined operations.

Multi-User Differential Configuration

In actual deployments, it's often necessary to set different command permissions for different users. This can be achieved by creating separate public key entries for each user or user group:

# Employee1 can only view logs
command="/bin/employee1_script.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD... employee1@company

# Employee2 can view logs and restart applications
command="/bin/employee2_script.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD... employee2@company

Each script can implement different command sets as needed, enabling fine-grained permission management.

Security Considerations and Best Practices

Multiple security factors must be considered when implementing SSH command restrictions. First, the restriction scripts themselves must be secure, avoiding command injection vulnerabilities. All user input should undergo strict validation and escaping. Second, all unnecessary SSH features such as port forwarding and X11 forwarding should be disabled, as these could be used to bypass restrictions.

Another important consideration is script permission settings. Restriction scripts should belong to the root user, with only root having write permissions to prevent users from modifying script content. Additionally, commands called within scripts should have appropriate permission controls.

It's also important to note that this method primarily applies to non-interactive command execution. If users require interactive access, other solutions such as modifying the user's default shell may need consideration. However, the shell modification approach carries certain risks, as some programs might bypass restrictions through special parameters.

Comparison with Other Methods

Beyond the authorized_keys method, several other common SSH command restriction approaches exist. Modifying the user's default shell is an alternative method, achieved by setting the user's shell to a restrictive script. This method is configured in /etc/passwd:

johndoe:x:1001:1001:John Doe:/home/johndoe:/bin/restricted_shell.sh

However, this approach has some limitations. First, it affects all types of logins, not just SSH. Second, some programs might invoke the shell in special ways that could bypass restrictions. Additionally, root users can typically override such restrictions.

Another method involves using SSH's ForceCommand configuration option, set globally in sshd_config. But this approach lacks key-based granular control and is more suitable for global policies rather than user-level control.

In comparison, the authorized_keys method provides precise key-based control, allowing different command restrictions for each public key while maintaining configuration simplicity and maintainability.

Practical Deployment Recommendations

When deploying an SSH command restriction system in practice, it's recommended to follow these steps: First, clearly list the commands needed by each user or user group. Second, create corresponding restriction scripts for each permission level. Then, generate dedicated SSH key pairs for users and configure appropriate restrictions in authorized_keys.

The testing phase should comprehensively verify various usage scenarios, including correct command execution, rejection of unauthorized commands, and handling of edge cases. Script security should also be tested to ensure no command injection or other security vulnerabilities exist.

For maintenance, clear documentation is recommended, recording each key's permissions and corresponding users. Regular audits of the authorized_keys file should be conducted to remove unused keys and update permission changes.

Finally, while SSH command restrictions provide effective access control, they should be part of an overall security strategy. Other security measures such as firewall configuration, system updates, and log monitoring are equally important, collectively building a comprehensive security protection system.