Restrict executable SSH commands with authorized keys

Published by Daniel Draga on November 9, 2017

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.

Restrict to single command in authorized_keys

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 dailybackup@
Wed Apr 30 14:46:53 CEST 2014
Connection to closed.
: ~ $ ssh dailybackup@ "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 dailybackup@ 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: [1]

: ~ $ vi
 #! / bin / sh 
if  [ -n " $ SSH_ORIGINAL_COMMAND"  ] 
  echo  "` / bin / date ": $ SSH_ORIGINAL_COMMAND" >> $ HOME / ssh-command-log
: ~ $ vi .ssh / authorized_keys
command = "/home/dailybackup/" ssh-rsa AAAAB3N [ ... ]

The client then calls rsync:

: ~ / tmp $ rsync -avz test.txt dailybackup@ /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 exec eval.

Restrict to multiple commands in authorized_keys

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


Leave a Reply