Restrict executable SSH-commands via authorized keys

The OpenSSH secure shell server allows a secure and encrypted remote access on Linux and Unix systems. On the server side, the authorized_keys file in the .ssh folder is primarily used for configuring a SSH public key authentication under Ubuntu. Normally, a user is granted full access on the system, on which the authentication was set up. In some cases, such as automatized backup processes, it is useful that the access is restricted to just a few, or even just a single command. The successful configuration steps are explained in this article.

Purpose

The restriction of executable commands via SSH is mainly used for automatized backups. The dedicated backup users mostly have a private key without key phrase to execute automated backups. On the backup destination server, the public key of the user is added to the authorized_keys file so that this user can connect without entering a password.

Strictly speaking, from this point on, the user would actually have full access to the backup server, even though, for example, the "rsync" command is always used.

A command restriction for the user avoids that if the private key is compromised, the backup server is automatically compromised as well. As the user is restricted to a command in the authorized_keys file, it is not allowed to execute another command or to establish a terminal session via SSH.

Restrict to a single command in authorized_keys

The /~/.ssh/authorized_keys file contains the public key of the user that is allowed to connect. (see also SSH public key authentication under Ubuntu):

:~$ cat .ssh/authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCj98R[...]

To restrict the user to a single command, the parameter command= is entered before the key. After that, whenever an attempt is made to establish an SSH connection, only this command will be executed, even if, for example, a different command was provided. In the following example, the user dailybackup is restricted to the date command for demonstration purposes. For this, the command=date parameter is defined on the SSH-server:

:~$ cat .ssh/authorized_keys 
command="date" ssh-rsa AAAA[...]

From the client computer that connects to the server via SSH, the only command the user can then execute is date:

:~$ ssh dailybackup@192.168.56.105
Wed Apr 30 14:46:53 CEST 2014
Connection to 192.168.56.105 closed.
:~$ ssh dailybackup@192.168.56.105 "tail /etc/passwd"
Wed Apr 30 14:47:02 CEST 2014

Analyse executed command on SSH-server

The analysis, 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 issued from the client, the command executed on the server is then displayed for analysis purposes:

:~$ ssh dailybackup@192.168.56.105 tail /etc/passwd
You invoked: tail /etc/passwd

Some commands, for example rsync, lead to an error message when used with the above command. By taking a roundabout route using a script on the SSH server, the command, that was executed, can be also accessed:

:~$ 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 up rsync:

:~/tmp$ rsync -avz test.txt dailybackup@192.168.56.105:/home/dailybackup
sending incremental file list
[...]

The command executed via SSH appears in the log file on the SSH server. This command can be used again via command= for restrictions:

:~$ cat ssh-command-log 
Wed Apr 30 15:10:54 CEST 2014: rsync --server -vlogDtprze.iLsf . /home/dailybackup

Hint: For problems with output redirection, exec can be used instead of eval

Restrict multiple commands in authorized_keys

In general, it is possible via additional scripts to allow multiple commands for a key pair.

However, for maximum security, it is easier to generate a private key pair for every desired command and to safe the corresponding command.

References

---

Author: Georg Schönberger

Translator: Alina Ranzinger Alina has been working at Thomas-Krenn.AG since 2024. After her training as multilingual business assistant, she got her job as assistant of the Product Management and is responsible for the translation of texts and for the organisation of the department.