SUSE Support

Here When You Need Us

How to configure sshd to allow root to run a command on a remote server without logging in

This document (7007565) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 10

/etc/ssh/sshd_config contains:
PermitRootLogin forced-command-only


Situation

Configuration to allow root to execute a command on a remote server without needing to allow root login on the remote server.

EXAMPLE:   From ServerA run date command as root on ServerB

ServerA:/ # ssh root@SERVERB date
Thu Jan 13 06:31:41  MST 2011

Resolution

Configuration requires PubkeyAuthentication be configured:

From sshd_config man pages:

 PermitRootLogin
             Specifies whether root can log in using ssh(1).  The argument
             must be “yes”, “without-password”, “forced-commands-only” or
             “no”.  The default is “yes”.

             If this option is set to “without-password” password authentica‐
             tion is disabled for root.

             If this option is set to “forced-commands-only” root login with
             public key authentication will be allowed, but only if the
             command option has been specified (which may be useful for taking
             remote backups even if root login is normally not allowed).  All
             other authentication methods are disabled for root.

             If this option is set to “no” root is not allowed to log in.



Setup the public key authentication required to set the PermitRootLogin to forced-command-long.

1.  Change to the .ssh directory located in the home directory of the user.  In this case, we want it to be /root for the root user.

EX:  # cd ~/.ssh

2. If the .ssh directory doesn't already exist, it will need to be created first with permissions of RWX--------- or 700

EX:  # cd ~
        # mkdir .ssh
        # chmod 700 .ssh

3.  Generate a key.

EX:  # ssh-keygen -t dsa
          Generating public/private dsa key pair.
          Enter file in which to save the key (/root/.ssh/id_dsa): date
          (note the default is to use id_dsa which will create a id_dsa and an id_dsa.pub.  If you would like to be able to configure multiple commands, modify the name of the file to reflect the command to be executed for ease of recognition)
          Enter passphrase (empty for no passphrase):
          Enter same passphrase again:
          Your identification has been saved to date
          Your public key has been saved to date.pub

          (note a key fingerprint and image can also be returned)

4.  Add the public key to root's authorized_keys file located in root's home directory under .ssh -  /root/.ssh/authorized_keys.  If may be necessary to create the authorized_keys file if it doesn't exist.  Permissions on the authorized_keys file should be rw------- or 600

EX:  Copy the public key file to SERVERB
        #  scp /root/.ssh/date.pub root@SERVERB:/root
  
        Login to SERVERB
        #   ssh root@SERVERB

        Change directories to root's .ssh directory on SERVERB, if it doesn't exist, create it as in step 2 above.
        #cd /root/.ssh
      
        Append the contents of the date.pub file to the authorized_keys file on SERVERB.  This command will create the authorized_keys if it doesn't already exist.
        #cat /root/date.pub >> authorized_keys

       Verify the permissions are correct on the authorized_keys file
        #chmod 600 authorized_keys

5.  Modify the /root/.ssh/authorized_keys entry for date.pub to execute the date command when the identification associated with the public key from date.pub is provided.

EX:  #  vi /root/.ssh/authorized_keys

Add command="/bin/date" to the beginning to the public key.

Original text:
ssh-dss AAAAB3NzaC1kc3MAAACBANP9jBkfIJpjuqB62xjCZ8HTAfUK9oXiwtGJALJwQEhHcb8qN48Ap3psQ/8xzl6es8OzaQJeRK5/QeXt915ObYc6UnYYqvRMhNvkp61xaezrVtkgggTCB/As6xzU0VXeAvJWAaxk9nBrloZAsOhlYkDtxhmBm2V/Ez/v0xX3pCzFAAAAFQDyZVUN9U01FoPBg8RTA0UU+zZmYQAAAIA25halDX7f6GzuyEF+ICcRZ27ybJiwiBSJO/GGsYqApWC77TsPI4wjE8YdC57kxWdXRP/KrnDw0lxXtbzJ3Mf4qWwWYy25ajvldYEFJKKhfS9NdJplOTciuRNYNsHhzAyD+oj5xzpdkaqIy2PaUoZKMP1rmANh6pS09EADNJLOSAAAAIEAhHKw4mLheoPAiVeyAO20KOk5mBlZAskh38S/RdCo2+TOs+fFNuoc5CMsRo+o0sylNcfmGx6DlBP6TOo13CJD9ULr8emqWG/UiXidk84D9jbmqyvbIWr+RF6ZXmmP9kUscisc7zCINtmsZzzngc1NdFiAIIUnkKARjfCCg/UV8h4= root@SERVERA

Modified text:
command="/bin/date" ssh-dss AAAAB3NzaC1kc3MAAACBANP9jBkfIJpjuqB62xjCZ8HTAfUK9oXiwtGJALJwQEhHcb8qN48Ap3psQ/8xzl6es8OzaQJeRK5/QeXt915ObYc6UnYYqvRMhNvkp61xaezrVtkgggTCB/As6xzU0VXeAvJWAaxk9nBrloZAsOhlYkDtxhmBm2V/Ez/v0xX3pCzFAAAAFQDyZVUN9U01FoPBg8RTA0UU+zZmYQAAAIA25halDX7f6GzuyEF+ICcRZ27ybJiwiBSJO/GGsYqApWC77TsPI4wjE8YdC57kxWdXRP/KrnDw0lxXtbzJ3Mf4qWwWYy25ajvldYEFJKKhfS9NdJplOTciuRNYNsHhzAyD+oj5xzpdkaqIy2PaUoZKMP1rmANh6pS09EADNJLOSAAAAIEAhHKw4mLheoPAiVeyAO20KOk5mBlZAskh38S/RdCo2+TOs+fFNuoc5CMsRo+o0sylNcfmGx6DlBP6TOo13CJD9ULr8emqWG/UiXidk84D9jbmqyvbIWr+RF6ZXmmP9kUscisc7zCINtmsZzzngc1NdFiAIIUnkKARjfCCg/UV8h4= root@SERVERA

6.  Modify the /etc/ssh/sshd_config file on SERVERB to allow root to execute configured commands but not login.

EX:  vi /etc/ssh/sshd_config

Uncomment the option PermitRootLogin, if it is currently commented.

Change PermitRootLogin so that it is set to forced-command-only

EX:  PermitRootLogin forced-command-only

7.  Restart sshd on SERVERB

EX:  rcsshd restart

8.  From SERVERA  ssh as root to SERVERB which will run the configured command.

EX:  ssh root@SERVERB

You will be prompted for the passphrase used in the generation of the key.  Then the configured command will be executed on SERVERB

If multiple commands are configured in SERVERB's /root/.ssh/authorized_keys each command will have it's own generated key and the -i option needs to be used to provide the identification file which should be used for the ssh session to be paired with the correct command/key combination.

EX:  SERVERA:/ #ssh root@SERVERB -i /root/.ssh/date
         Thu Jan 13 06:31:41  MST 2011

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:7007565
  • Creation Date: 13-Jan-2011
  • Modified Date:03-Mar-2020
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.