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

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

The N1 Grid Service Provisioning System 5.0 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 http://www.openssh.com. The software can be configured to support other versions of SSH.

Using the same implementation of SSH on each server in your network ensures that the keys are compatible and that the servers communicate properly. You may choose to use different implementations of SSH on servers in your network, but you must test to verify that the various implementations are compatible and interoperable.

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

• Configuring SSH – Process Overview

• Preparing the Keys

• Setting Up and Testing the Connectivity on the Master Server

• Configuring SSH for the Applications

• SSH Advanced Parameters and 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 servers.

Unlike the other connection types, when an SSH connection is set up between two N1 Grid Service Provisioning System 5.0 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 a Local Distributor to connect to an Remote Agent using SSH, do not manually start the Remote Agent. The Local Distributor automatically starts the Remote Agent when necessary. The Remote Agent continues to run for as long as it is being used. The Local Distributor will automatically shut down the Remote Agent when it has not been used for a configurable period of time.

ssh-agent or Empty Password Keys

You can configure SSH to use the ssh-agent or to use empty password keys . 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 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 ssh-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. ssh-agent forwarding allows Local Distributors to authenticate to Local Distributors and Remote Agents that are downstream. This approach provides more security. Also, configuring the ssh-agent for use with the N1 Grid Service Provisioning System 5.0 is less complicated than configuring empty passwords.

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 Grid Service Provisioning System 5.0, 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.

SSH Requirements

The N1 Grid Service Provisioning System 5.0 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 Grid Service Provisioning System 5.0.

• The ssh-keygen command must generate a public-private key pair 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

• After hopping from the current host to host1 to host2 to host3, on 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.

Additional SSH Security

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 that has the setuid bit set. This file has the same group ID as the user that you used to install the Remote Agent and it gives execute permission to the group. Additionally, the file is stored in a directory that is called protect that is owned by the user you used to install the Remote Agent. The file gives execute permission only 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 Grid Service Provisioning System 5.0, ensure that all the files in N1SPS5.0-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 /N1SPS5.0-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 that contain RhostsRSAAuthentication, because 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 /N1SPS5.0-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.

Configuring SSH – Process Overview

The following process overview describes the tasks necessary to configure the N1 Grid Service Provisioning System 5.0 to use SSH.

1. Determine whether you want to use empty password keys or the ssh-agent.

   For more information about choosing an SSH security level, see ssh-agent or Empty Password Keys.

2. Generate the keys on the applications that initiate SSH connections.

   See How to Generate Key Pairs.

3. Copy the generated keys to the Local Distributors and the Remote Agents.

   From the following list, choose the appropriate task based on whether you are using empty password keys or the ssh-agent:

   • How to Set Up Keys for the ssh-agent

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

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

4. Set up the SSH connectivity. Then, test the connectivity before you start the Master Server.

   See Setting Up and Testing the Connectivity on the Master Server.

5. Configure the Local Distributors and Remote Agents to use SSH.

   See How to Configure SSH for Local Distributors and Remote Agents.

6. (Optional) If you have any CLI Clients, configure the clients to use SSH.

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

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. Then, copy the generated keys to the Local Distributors and Remote Agents. Choose the appropriate task to complete based on whether you are using the ssh-agent or empty password keys.

The following instructions describe how to create keys with the default key lengths. For maximum security, create keys with the longest possible key lengths.

How to Generate Key Pairs

If you are using the 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. Alternatively, 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.

Before You Begin

Ensure that the user ID and group ID that you are using for the N1 Grid Service Provisioning System 5.0 are the same on all of the servers in the network.

Steps

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

   % ssh-keygen –t rsa

   The server prompts you to save the keys.

2. 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.

   The server prompts you for a password.

3. 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.

How to Set Up Keys for the ssh-agent

If you are using the ssh-agent, complete this task to copy the keys to the Local Distributors and Remote Agents.

Steps

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

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

   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.

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. 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. Edit the following line in the config.properties files on the Master Server and the Local Distributors to enable ssh-agent forwarding.

   Current configuration:

   net.ssh.args=-o|BatchMode yes

   Edit the line to include the -A option:

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

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

If you are using empty password files and you generated only one key pair, complete this task to copy the keys to the Local Distributors and Remote Agents.

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. 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. User-home-downstream is the home directory on the Local Distributor or the Remote Agent machine to which the machine that 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

If you are using empty password files and you generated a key pair for each SSH connection, complete this task to copy the keys to the Local Distributors and Remote Agents.

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

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 Grid Service Provisioning System 5.0. 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

You must execute all the SSH setup commands in the following setup tasks, ssh, ssh-add, and cr_server start, in the same session as the session that 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.

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 that 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 session that 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 might 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 to 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.

   Use the same command that you used in Step 1 to test the connection paths again to ensure that the server does not prompt you for any information.

Repeating Set Up and Testing

If you change any of the keys, you might need to perform this task again. Depending upon your server setup, you also might 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 Grid Service Provisioning System 5.0 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 Grid Service Provisioning System 5.0 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 might 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 machine.

Steps

1. Use the Master Server browser 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=/N1SPS5.0-Home/application

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

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

   cprefix=/opt/SUNWn1sps/N1_Grid_Service_Provisioning_System_5.0/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 that 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, the .cshrc, or the .bash_profile 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 that 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. 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.

SSH Advanced Parameters and Command Reference

Advanced Parameters Reference

On the Host Details page in the Advanced Parameters field, you can specify additional SSH configuration information. The Advanced Parameters that are accepted are as follows. If you want to use more than one parameter, separate the parameters with a comma. Do not add any unnecessary spaces in the Advanced Parameters field.

cprefix

The cprefix parameter is required for all Local Distributors and Remote Agents. The syntax of the parameter in the Advanced Parameters field is as follows:

cprefix=/N1SPS5.0-Home/application

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

Example 6–1 cprefix Example

If the N1 Grid Service Provisioning System 5.0 is installed in /opt/SUNWn1sps/ and you are configuring a Remote Agent, the text you add to the Advanced Parameters field is:

cprefix=/opt/SUNWn1sps/N1_Grid_Service_Provisioning_System/agent

sshpath

If you have not added and do not want to add the path to the SSH executable to the PATH on the target server, you can specify the path to the SSH executable with this parameter. The syntax of the parameter in the Advanced Parameters field is as follows:

sshpath=/path-to-SSH

path-to-SSH is the directory in which the SSH executable is installed.

Example 6–2 sshpath Example

If the SSH executable is installed in the /usr/local/bin/ssh directory, the text that you add to the Advanced Parameters field is:

sshpath=/usr/local/bin/ssh

sshargs

If you want to supply additional command line arguments to the ssh command when it runs on a specific Host, you can supply those arguments in the Advanced Parameters field for that Host. The syntax of the parameter in the Advanced Parameters field is as follows:

sshargs=-option|-option

option is the command line option that you want supplied to the ssh command. Add more than one option by separating the options with a |.

Example 6–3 sshargs Example

If you want the ssh command to enable authentication agent forwarding, supply the -A option in the Advanced Parameters field:

sshargs=-o|BatchMode yes|-A

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 that are available in that version of SSH that are equivalent to the following commands. Then, use the equivalent commands when following the instructions to configure SSH.

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.