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 Sun N1 Service Provisioning System 5.2 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.
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.
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.
ssh-agent
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 Sun N1 Service Provisioning System 5.2 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 Sun N1 Service Provisioning System 5.2, 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.
The Sun N1 Service Provisioning System 5.2 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 Sun N1 Service Provisioning System 5.2.
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.
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 Sun N1 Service Provisioning System 5.2, ensure that all the files in N1SPS5.2-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.2-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.2-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.