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.

Usage

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@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

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@192.168.56.105 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 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 dailybackup@192.168.56.105: /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.

Categories: Tutorials

1 Comment

raf · April 24, 2019 at 7:08 AM

[Disclosure: I wrote sshdo which is described below]

Allowing multiple commands (but nothing else) for a single ssh keypair can be done securely and easily.

There’s a program called sshdo for doing this. It controls which commands may be executed via incoming ssh connections. It’s available for download at:

http://raf.org/sshdo/ (read manual pages here)
https://github.com/raforg/sshdo/

It has a training mode to allow all commands that are attempted, and a –learn option to produce the configuration needed to allow learned commands permanently. Then training mode can be turned off and any other commands will not be executed.

It also has an –unlearn option to stop allowing commands that are no longer in use so as to maintain strict least privilege as requirements change over time.

It is very fussy about what it allows. It won’t allow a command with any arguments. Only complete shell commands can be allowed.

But it does support simple patterns to represent similar commands that vary only in the digits that appear on the command line (e.g. sequence numbers or date/time stamps).

It’s like a firewall or whitelisting control for ssh commands.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: