Chapter 6 Configuring the N1 Service Provisioning System 4.1 to Use Secure Shell

This chapter contains instructions for configuring the N1 Service Provisioning System 4.1 to communicate using Secure Shell (SSH).

The N1 Service Provisioning System 4.1 supports OpenSSH 2.0 explicitly. OpenSSH 2.0 is a free version of SSH that has primarily been developed by the OpenBSD Project. For more details, see . The software can be configured to support other versions of SSH.

The commands and interface examples in this chapter apply to OpenSSH 2.0. If you are using a different version of SSH, refer to the documentation provided with that version of SSH to determine the commands and options that are equivalent to the commands used in OpenSSH 2.0. For details about the OpenSSH 2.0 commands and options used, refer to OpenSSH 2.0 Command Reference.

This chapter discusses the following topics:

• Overview of SSH and Requirements

• Task Map for Configuring SSH

• Preparing the Keys

• Setting Up and Testing the Connectivity on the Master Server

• Configuring SSH For the Applications

• The jexec Wrapper

• OpenSSH 2.0 Command Reference

Overview of SSH and Requirements

SSH is a UNIX-based command suite and protocol for securely accessing a remote computer. SSH secures network client/server communications by authenticating both endpoints with a digital certificate and by encrypting passwords. SSH uses RSA public key cryptography to manage connections and authentication. SSH is more secure than telnet and other shell based communication methods and is used to manage web servers and other remote systems.

Unlike the other connection types, when an SSH connection is set up between two N1 Service Provisioning System 4.1 applications, the downstream application does not need to be manually started. The upstream application automatically starts the downstream application when it is needed. The downstream application remains running for the duration necessary and shuts down automatically when it is not used for a configurable period of time.

Do not manually start the downstream application for an SSH connection. For example, if you set up an Local Distributor to connect to an Remote Agent using SSH, do not manually start the Remote Agent. The Local Distributor automatically stars the Remote Agent when necessary. The Remote Agent continues to run for as long as it is being used. The Local Distributor will automatically shutdown the Remote Agent when it has not been used for a configurable period of time.

Empty Password Keys or ssh-agent

You can configure SSH to use empty password keys or to use the ssh-agent. If you use empty password keys, the generated SSH private key is stored with an empty password. As a result, you do not need a password to access the key. When you use SSH to communicate with another machine that trusts its public key, you are not prompted for a password. When using the ssh-agent, the generated private key is stored with a secure password and saved on secure media. You communicate with another machine by starting the ssh-agent, uploading the private key from the secure media, and supplying the password. The private key is not stored on the file system, but is stored in the memory of the ssh-agent process.

When using empty passwords, the private key is stored on the file system of the machine without a password. Also, the private key must be present on all machines that initiate SSH communications. In the case of the N1 Service Provisioning System 4.1, all Master Servers and Local Distributors that are connecting to applications downstream using SSH are required to have a private key. This approach provides less security.

When using the ssh-agent, the private key is stored with the ssh-agent that is running only on the Master Server. The public key is distributed to other machines on the network. When an SSH application requires authentication, it communicates with the ssh-agent to authenticate. You must turn on agent forwarding when making intermediate SSH connections to enable Local Distributors to proxy to the ssh-agent that is running on the Master Server for authentication. Agent forwarding allows Local Distributors to authenticate to Local Distributors and Remote Agents that are downstream. This approach provides more security.

SSH Requirements

The N1 Service Provisioning System 4.1 requires the following SSH capabilities:

• Remote command invocation through ssh

• Public-private key authentication

• Support for BatchMode yes interaction, which is the ability to invoke the ssh command without interaction from an operator

If you are using the ssh-agent, the following SSH capabilities are required:

• Support for ssh-agent.

• Support for ssh-agent forwarding in SSH. Use the -A option in Open SSH.

The following capabilities are helpful when configuring machines for SSH connectivity, but are not requirements:

• Force allocate a tty when doing remote command invocation. Use the -t option in OpenSSH.

• Kill the ssh agent. Use the -k option for the ssh-agent command in OpenSSH.

• Generate an RSA key for higher security. Use the -t rsa in OpenSSH.

Review the following checklist to determine whether an implementation of SSH meets the requirements of the N1 Service Provisioning System 4.1.

• The ssh-keygen command must generate a public-private keypair that can be used for authenticating SSH invocations.

• On the specified host without prompting for any extra information to exchange host keys, obtain a password, etc., when the private key used for authentication was created without a password or with an empty password, the ssh command must be able to execute the following:

  % ssh –o `BatchMode yes' hostname

• On host3 after hopping from the current host to host1 to host2 to host3 with the ssh-agent running on the current host, uploaded with a private key created with a non-empty password, without prompting for any extra information to exchange host keys, obtain a password, etc., the ssh command must be able to execute the following:

  % ssh –o `BatchMode yes' –A host1 ssh –o `BatchMode yes' –A host2 ssh –o `BatchMode yes' host3

• The ssh command must be able to correctly pipe its own standard input, output, and error streams to the command being executed on the remote machine.

• The ssh-add command must be able to upload private keys with non-empty passwords into the ssh-agent so that the private keys can be used for authentication.

Task Map for Configuring SSH

The following table describes the tasks necessary to configure the N1 Service Provisioning System 4.1 to use SSH.

Preparing the Keys

Generate the public-private key pair that will be used to authenticate communication from the Master Server to the Local Distributors and the Remote Agents.

If you are using ssh-agent, you only need to generate one key pair. If you are using empty passwords, you may generate a key pair for each SSH connection that the software makes between two machines. Or, you may generate one single key pair for use by all the connections. Complete this task for each key pair that you want to generate.

How to Generate Key Pairs

Steps

1. On the Master Server, or, if you are using empty passwords and generating key pairs for each connection, on the machine that is upstream, generate the keys.

   % ssh-keygen –t rsa

   The system prompts you for a password.

2. Determine whether you need to supply a password.

   • If you are using empty password keys, do not supply a password. Press Return to continue.

   • If you are using the ssh-agent, supply a password for the keys.

   The system prompts you to save the keys.

3. Save the keys in the default locations by pressing Return.

   The private key is saved in /User-home/.ssh/id_rsa. The public key is saved in /HOME/.ssh/id_rsa.pub.

   User-home is the home directory of the currently logged in user on the Master Server machine.

How to Set Up Keys for Empty Password Files When Using One Key Pair

Steps

1. From the Master Server, copy the private key to each machine that is upstream. Save the key in the home directory.

   % cp /User-home/.ssh/id_rsa /User-home-upstream/.ssh/id_rsa

   User-home is the home directory of the currently logged in user on the Master Server machine and User-home-upstream is the home directory on the machine that is upstream. The upstream machine is the machine that initiates the SSH connection with the machine that is downstream.

   Each Local Distributor can have a unique private key, or you can use the same private key for all Local Distributors.

2. Copy the public key to each machine that is downstream. Save the key in the /.ssh/authorized_keys2 file.

   % cp /HOME-MS/.ssh/id_rsa.pub /HOME-downstream/.ssh/authorized_keys2

   User-home is the home directory on the Master Server machine and User-home-downstream is the home directory on the Local Distributor or the Remote Agent machine to which the machine you set up in the previous step will connect. Copy the public key to all Local Distributors and Remote Agents that connect using SSH.

3. Ensure that the .ssh/ directory and any parent directories are not world writable.

4. Ensure that the private key file, .ssh/id_rsa, is not accessible by other users or groups.

5. Change the permissions for the .ssh/authorized_keys2 file to 600.

How to Set Up Keys for Empty Password Files When Using Multiple Key Pairs

Before You Begin

Complete this task for every SSH connection, therefore every key pair, that is made on the network.

Steps

1. From the machine that is upstream, copy the public key to each machine that is downstream. Save the key in the User-home/.ssh/authorized_keys2 file.

   % cp /User-home-upstream/.ssh/id_rsa.pub /User-home-downstream/.ssh/authorized_keys2

   User-home-upstream is the home directory on the machine that is upstream and Use-home-downstream is the home directory on the Local Distributor or the Remote Agent machine to which the upstream machine will connect.

2. Ensure that the .ssh/ directory and any parent directories are not world writable.

3. Ensure that the private key file, .ssh/id_rsa, is not accessible by other users or groups.

4. Change the permissions for the .ssh/authorized_keys2 file to 600.

How to Set Up Keys for the ssh-agent

Steps

1. On the Master Server, copy the private key file, ~/.ssh/id_rsa, to a secure media.

   % cp /User-hone/.ssh/id_rsa path_to_file/

   User-home is the home directory of the currently logged in user on the Master Server machine and path_to_file/ is the path to the secure media where you want to save the private key file.

2. Delete the private key file from the local file system.

   % rm /User-home/.ssh/id_rsa

3. Copy the public key to each Local Distributor and Remote Agent that you want to set up to use SSH. Save the key in the ~/.ssh/authorized_keys2 file.

   % cp /User-home.ssh/id_rsa.pub /User-home-APP/.ssh/authorized_keys2

   User-home is the home directory on the Master Server machine and User-home-APP is the home directory of the currently logged in user on the Local Distributor or the Remote Agent machine.

4. Ensure that the .ssh/ directory and any parent directories are not world writable.

5. Change the permissions for the .ssh/authorized_keys2 file to 600.

6. Add the following line to the config.properties files on the Master Server and the Local Distributors to enable ssh-agent forwarding.

   net.ssh.args=-o|BatchMode yes|-A

Setting Up and Testing the Connectivity on the Master Server

This section describes the initial setup and testing of SSH that must be done before you use SSH with the N1 Service Provisioning System 4.1. If you are using the ssh-agent, you will need to start the ssh-agent before you begin the setup and testing task.

How to Start the ssh-agent on the Master Server

Complete this task only if you are using the ssh-agent. Complete this task before you start the Master Server.

Steps

1. Start the ssh-agent.

   % eval `ssh-agent`

   The ssh-agent starts and sets two environment variables. SSH_AUTH_SOCK and SSH_AGENT_PID are used by ssh, and ssh-add to connect to the ssh-agent.

2. Upload the private key that you generated.

   % ssh-add path-to-file/

   path-to-file/ is the path to the secure media where you saved the private key file.

   You are prompted to provide a password.

3. Provide the password you created when you generated the keys.

Shutting Down the ssh-agent

You can shut down the ssh-agent by running the command eval `ssh-agent –k`.

This command uses the SSH_AGENT_PID variable to send a signal to the ssh-agent process to shut it down. The command also unsets the environment variables that were set when you started the ssh-agent.

How to Set Up and Test the Connectivity on the Master Server

Before You Begin

If you are using the ssh-agent, be sure to start the ssh-agent by following the instructions in How to Start the ssh-agent on the Master Server. The setup is session sensitive, so you must execute all the SSH commands, ssh, ssh-add, and cr_server start, in the same session as the one you used to start the ssh-agent. If this session is terminated, you must kill the ssh-agent program that is running and start a new ssh-agent program. You will also need to upload the private key.

Steps

1. Test the SSH connection paths.

   % ssh target-host-IP set % ssh -A -t target-host-IP ls -l

   Use the -A option only if you are using the ssh-agent. target-host-IP is the IP address for the machine to which this machine will connect.

   For example, you may have a network setup with the following Master Server (MS), Local Distributors (LD1, LD2, and LD3) and Remote Agents (RA1, RA2, RA3, and RA4).

   MS | \ | \ | \ LD1 LD2 | \ \ | \ LD3 | \ |\ | | | \ | | | \ | | | \ RA1 RA2 RA3 RA4

   For this example network, executing the following commands on the Master Server, substituting the IP addresses of the Local Distributors and Remote Agents on the network for LD1, LD2, RA1, RA2, RA3, and RA4, would test the SSH connection paths.

   % ssh -A -t LD1 ssh -t RA1 set % ssh -A -t LD1 ssh -t RA2 set % ssh -A -t LD2 ssh -A -t LD3 ssh -t RA3 set % ssh -A -t LD2 ssh -A -t LD3 ssh -t RA4 set

   These commands follow the paths that the Master Server uses when using SSH to connect to the machines that are downstream. Each command enables SSH to exchange the host keys required for communicating to the machines specified as arguments.

   SSH prompts you to allow the host key exchange.

2. Answer yes to each of the prompts.

3. Verify the output of all of the commands to ensure that the environment variables are correctly set up.

   The PATH variable should have /bin, /usr/bin, and any other directories that are part of your environments.

4. Test the SSH connection paths again.

   Using the same command that you used in Step 1, test the connection paths again to be sure that the system does not prompt you for any information.

Repeating Set Up and Testing

If you change any of the keys, you may need to perform this task again. Depending upon your system setup, you also may need to complete this task again whenever you reboot any of the machines.

Configuring SSH For the Applications

After you set up and test SSH on the Master Server, configure the other machines in the N1 Service Provisioning System 4.1 so that the Master Server can connect to them using SSH.

How to Configure SSH for Local Distributors and Remote Agents

The SSH configuration has must be completed by following the N1 Service Provisioning System 4.1 network from the Master Server to the Remote Agents and configuring the intermediate Local Distributors in the order in which you encounter them. Essentially, this is a preorder traversal of the tree network.

For example, you may have a network setup with the following Master Server (MS), Local Distributors (LD1, LD2, and LD3) and Remote Agents (RA1, RA2, RA3, and RA4).

MS
 | \
 |  \
 |   \
 LD1  LD2
 | \     \
 |  \     LD3
 |   \    |\
 |   |    | \ 
 |   |    |  \ 
 |   |    |   \
 RA1 RA2  RA3  RA4

Configure your network in the following order: LD1, RA1, RA2, LD2, LD3, RA3, RA4. Follow this order strictly and complete the configuration of one machine before moving on to the next one.

Steps

1. Use the Web Interface to view the Host Details page for the machine you want to configure.

2. Add the connection details in the Local Distributor or the Remote Agent section depending on what application you are configuring on that machine.

3. Specify the connection type as ssh.

4. Add the following text in the Advanced Parameters field.

   cprefix=/N1SPS4.1-Home/application

   N1SPS4.1–Home is the home directory of the application and application is agent if you are configuring a Remote Agent or ld if you are configuring a Local Distributor.

   For example, if the N1 Service Provisioning System 4.1 is installed in /opt/SUNWn1sps/N1_Service_Provisioning_System_4.1/ and you are configuring a Remote Agent, the text you add to the Advanced Parameters field is:

   cprefix=/opt/SUNWn1sps/N1_Service_Provisioning_System_4.1/agent

5. Save the Host Details.

6. Ensure that you do not have a Remote Agent or Local Distributor instance running on this machine.

7. Click Test Connection on the Host Details page for this application instance.

8. Repeat this task for each machine in your network.

How to Configure SSH for the CLI Client With the ssh-agent

Complete this task if you want to use SSH connectivity for the CLI Client with the ssh-agent.

Steps

1. Create a new operating system user account on the Master Server and the machine on which the CLI Client is installed.

   This account should be different from the account that you specified during the installation of the Master Server, Local Distributor, or Remote Agent.

2. Log in to the Master Server as the new user that you created in the previous step.

3. Generate public and private keys for the new user by following the instructions in How to Generate Key Pairs.

   Do not reuse the keys you generated for communication between the Master Server, Local Distributors, and Remote Agents.

4. On the Master Server, copy the private key file to a secure media.

   % cp /User-home/.ssh/id_rsa path-to-file/.ssh/id_rsa

   User-home is the home directory of the currently logged in user on the Master Server machine. path-to-file/ is the path to the secure media where you want to save the private key file.

5. Delete the private key file from the local file system.

   % rm /User-home/.ssh/id_rsa

6. On the Master Server, concatenate the public key to the /.ssh/authorized_keys2 file for that user.

   % cat /User-home/.ssh/id_rsa.pub >> /HOME-MS/.ssh/authorized_keys2

   User-home is the home directory on the Master Server machine.

7. Log in to the CLI Client machine as the new user that you created.

8. Start the ssh-agent.

   % ssh-agent > /User-home/.ssh/agent_vars

   User-home is the home directory of the currently logged in user on the CLI Client machine.

9. Add the following line to the .profile or the .cshrc file.

   . /User-home/.ssh/agent_vars

   User-home is the home directory on the CLI Client machine.

10. Log out of the Master Server and log back in.

11. Upload the private key that you generated.

    % ssh-add path-to-file/

    path-to-file/ is the path to the secure media where you saved the private key file.

    The CLI Client now uses SSH and the ssh-agent for authentication when connecting to the Master Server.

12. Configure the Master Server to accept only connections from localhost. For instructions, see Configuring the JVM Security Policy.

Stopping the ssh-agent

If you want to stop the ssh-agent, on the CLI Client, use the following command.

% eval `ssh-agent –k >User-home/.ssh/agent_vars`

User-home is the home directory of the currently logged in user on the CLI Client machine.

How to Configure SSH for the CLI Client With Empty Passwords

Complete this task if you want to use SSH connectivity for the CLI Client with empty passwords.

Steps

1. Create a new operating system user account on the Master Server and the machine on which the CLI Client is installed.

   This account should be different from the account that you specified during the installation of the Master Server, Local Distributor, or Remote Agent.

2. Log in to the CLI Client machine as the new user that you created in the previous Step.

3. Generate public and private keys for the new user by following the instructions in How to Generate Key Pairs.

   Do not reuse the keys you generated for communication between the Master Server, Local Distributors, and Remote Agents.

4. On the CLI Client, copy the public key file to the new user's authorized_keys2 file on the Master Server machine.

   % cp User-home-CLI/.ssh/id_rsa.pub User-home-MS/.ssh/id_rsa.pub

   User-home-CLI is the home directory on the CLI Client machine and User-home-MS is the home directory on the Master Server machine.

5. On the Master Server, concatenate the public key to the /.ssh/authorized_keys2 file for that user.

   % cat /User-home/.ssh/id_rsa.pub >> /User-home/.ssh/authorized_keys2

   User-home is the home directory of the currently logged in user on the Master Server machine.

6. Log in to the CLI Client machine as the new user that you created.

7. Test the SSH connection.

   % ssh IP-Address-MS set

   IP-Address-MS is the IP address of the Master Server machine.

   You might be prompted to exchange keys.

8. If you are prompted to exchange keys, answer yes.

9. Verify that the PATH variable is set correctly.

   The PATH variable must contain /bin, /usr/bin, and any other directories that are part of your environment.

10. Configure the Master Server to accept only connections from localhost. For instructions, see Configuring the JVM Security Policy.

The jexec Wrapper

When you invoke the Remote Agent through SSH, the Remote Agent uses the jexec wrapper to invoke the Java Virtual Machine. This wrapper is a native executable that is owned by root and has the setuid bit set. This file has the same groupid as the user you used to install the Remote Agent and it gives execute permission to the group. Additionally, the file is stored in a directory called protect that is owned by the user you used to install the Remote Agent. The file only gives execute permission to the user that owns the Remote Agent. This prevents any other user from being able to execute the jexec wrapper.

You must ensure that the file permissions on jexec and protect are not accidentally changed at any point.

To further tighten security for jexec, make any or all of the following changes:

• The JVM executables, usually shell scripts, must be owned by root or the user that owns the application and do not give write permissions to any other users or groups. If you install the JRE with the N1 Service Provisioning System 4.1, ensure that all the files in N1SPS4.1-home/common/jre are owned by the user that owns the application and do not give write access to any other users or groups.

• The user ID of the user that owns the application must only be allowed to log in using SSH. When logging in using SSH, only public-key authentication should be allowed. The /N1SPS4.1-home/.ssh directory should not give any permissions to any other users or groups.

• The SSH server can be configured to allow only public key authentication by ensuring that the etc/sshd_config file contains the following line to disable password authentication.

  PasswordAuthentication no

• Ensure that the etc/sshd_config file does not have lines containing RhostsRSAAuthentication, as this is not allowed by default. Also ensure that RSAAuthentication, if present, is set to yes, the default.

• You can further tighten security on the Remote Agent by editing the /N1SPS4.1-home/.ssh/authorized_keys2 file and prefixing the following text to the line that contains the public key of the Master Server.

  no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

The sshd(1M) man page offers additional details.

OpenSSH 2.0 Command Reference

This section describes the OpenSSH 2.0 commands and options that are used in the instructions in this chapter. If you are using a different version of SSH, determine the commands and options available in that version of SSH that are equivalent to the following commands.

The following options can be used with the ssh command.

-A

Enables authentication agent forwarding

-o `BatchMode yes'

Disables passphrase querying

-t

Allocates a tty even if a command is given

The following option can be used with the ssh-keygen command.

-t rsa

Specifies RSA as the type of key to generate.

The following option can be used with the ssh-agent command.

-k

Kills the agent using the pid set in the environment variable SSH_AGENT_PID. Other implementations might use a different environment variable.