The OpenSSH Secure Shell Server provides secure, encrypted remote access to Linux and Unix systems. The server side is the file authozired_keys in .ssh a user’s primary folder to configure a public-key authentication . Normally, a user gets full access to the system where the authentication was set up. However, in some cases, such as automated backup operations, it makes sense to restrict access to a few or even a single command . The required configuration steps are explained in this article.
The restriction of SSH-executable commands is mainly used for automated backup operations or backups. In most cases, dedicated backup users have a private key with no key phrase or key phrase to perform automated backups. At the backup destination server, this user’s public key is placed in the authorized_keys file so that it can connect without entering a password. Actually, from this point on, the user would have full access to the backup server, even though he always calls only the command rsync .
A command restriction for the user prevents the backup server from being automatically compromised if the private key is compromised. Since the user is restricted to a command in the authorized_keys file, he must not execute any other command or set up a terminal session via SSH.
The file /~/.ssh/authorized_keys contains the public key of the user who is allowed to connect (sa public-key authentication ):
: ~ $ cat .ssh / authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAAAABABAAABAQCj98R [ ... ]
In order to limit the user to a single command, the parameter command = is entered before the key. Thereafter, when attempting to set up an SSH connection, only this command is always executed, even if, for example, another command was transferred. In the following example the user dailybackup is restrictedto the command date for demonstration purposes. For this purpose, the parameter command = date is defined on the SSH server :
: ~ $ cat .ssh / authorized_keys command = "date" ssh-rsa AAAA [ ... ]
From the client computer, which connects to the server via SSH, then only the command date is executable for the user:
: ~ $ ssh firstname.lastname@example.org Wed Apr 30 14:46:53 CEST 2014 Connection to 192.168.56.105 closed. : ~ $ ssh email@example.com "tail / etc / passwd" Wed Apr 30 14:47:02 CEST 2014
Analyze the executed command on the SSH server
The analysis of which command must be entered in authorized_keys is made easier by the environment variable $ SSH_ORIGINAL_COMMAND :
command = "/ bin / echo You invoked: $ SSH_ORIGINAL_COMMAND" ssh-rsa AAAAB [ .. ]
When a command is called from the client, the command executed on the server is output for analysis purposes:
: ~ $ ssh firstname.lastname@example.org tail / etc / passwd You invoked: tail / etc / passwd
However, some commands, such as rsync, cause an error message in the above command . However, in a roundabout way with the help of a script on the SSH server, it also comes to the command executed: 
: ~ $ vi logssh.sh #! / bin / sh if [ -n " $ SSH_ORIGINAL_COMMAND" ] then echo "` / bin / date ": $ SSH_ORIGINAL_COMMAND" >> $ HOME / ssh-command-log exec $ SSH_ORIGINAL_COMMAND fi : ~ $ vi .ssh / authorized_keys command = "/home/dailybackup/logssh.sh" ssh-rsa AAAAB3N [ ... ]
The client then calls rsync:
: ~ / tmp $ rsync -avz test.txt email@example.com: /home/dailybackup sending incremental file list [ ... ]
On the SSH server, the command executed via SSH appears in the log file. This command can then be used again via command = for restriction:
: ~ $ cat ssh-command-log Wed Apr 30 15:10:54 CEST 2014: rsync --server -vlogDtprze.iLsf. / home / daily backup
Note: Problems with output redirects can be used instead
Basically, additional scripts allow you to allow multiple commands for a key pair.
However, for the greatest possible security, it is easier to generate a separate key pair for each desired command and to store the corresponding command.