|
|
United States-English | |
|
|
 |
|
HP-UX System Administrator's Guide: Security Management: HP-UX 11i Version 3 > Chapter 5 Remote Access Security Administration
Securing Remote Sessions Using HP-UX Secure Shell (SSH) |
|
|
HP-UX Secure Shell is based on the OpenSSH product, an open source SSH product (http://www.openssh.org). It enables a secure connection between a client and a remote host over an otherwise insecure network. Following are the key attributes of this secure connection:
HP-UX Secure Shell offers a secure replacement for such commonly used functions and commands as telnet, remsh, rlogin, ftp, and rcp. For HP-UX Secure Shell documentation see the ssh(1) manpage for the ssh client and to the sshd(8) manpage for the sshd server. Both manpages include references to the other HP-UX Secure Shell manpages that come with the product. Also see the HP-UX Secure Shell Release Notes at: http://www.docs.hp.com/en/internet.html#Secure%20Shell The key security features of HP-UX Secure Shell include the following:
HP-UX Secure Shell software consists of a set of client and server components. See Table 5-2. Table 5-2 Software Components of HP-UX Secure Shell
Before running any of the Secure Shell clients listed in Table 5-2, first start the Secure Shell server daemon, sshd. The sshd daemon obtains its initial configuration values from the sshd_config file, located in the /opt/ssh/etc directory on the server system. One of the most important configuration directives in sshd_config is the set of authentication methods supported by the sshd daemon. See Section for more information. The ssh client application establishes a socket connection with the sshd server. The sshd server spawns a child sshd process. This child inherits the connection socket and authenticates the client based on the selected authentication method. A successful secure client session is established only upon successful authentication. After a session is created, all subsequent communication occurs directly between the client and this child sshd process. The client can now execute remote commands on the server. Each command request from the ssh client causes the child sshd process to spawn a shell process to execute that command. In summary, a running ssh client-server session consists of the following processes:
The sftp client application causes the sftp client process to spawn the ssh client, and then communicates with it using a UNIX pipe. The ssh client then establishes a socket connection with the sshd server. The rest of the server interaction is similar to the ssh client case described in Section . The difference is that instead of spawning a shell to execute the remote command, the child sshd process spawns the sftp-server process. All subsequent communication during this sftp session occurs among the following processes: HP-UX Secure Shell offers a more enhanced level of security through the privileged separation feature. As described in Section , both the parent sshd and the child sshd processes run as privileged users. When privilege separation is enabled, one extra process is spawned per user connection. When an ssh client connects to an sshd server which is configured for privilege separation, the parent sshd process spawns a privileged child sshd process. When privilege separation is enabled, the child sshd process spawns an additional nonprivileged child sshd process. This nonprivileged child sshd process then inherits the connection socket. All subsequent communication between client and server occurs with this nonprivileged child sshd process. Most remote command execution requests from the client are nonprivileged, and are handled by a shell spawned under this nonprivileged child sshd process. When the nonprivileged child sshd process needs a privileged function to be executed, it communicates with its privileged parent sshd process using a UNIX pipe. Privilege separation helps contain potential damage from an intruder. For example, if a buffer overflow attack occurs during a shell command execution, control is within the nonprivileged process, thereby containing the potential security risk. HP-UX Secure Shell supports the following authentication methods:
When a client connects with a remote sshd daemon, it selects the desired authentication method (one of the methods listed previously), and either presents the appropriate credentials as part of the connection request or responds to a prompt sent back by the server. All authentication methods work in this way. The server requires the appropriate key, pass phrase, password, or credentials from the client to establish a successful connection. You can choose to have the sshd instance support only a subset of the supported authentication methods based on security requirements. Although HP-UX Secure Shell supports the authentication methods listed previously, system administrators can limit the authentication methods offered by an sshd instance, based on the specific security requirements of their environment. For example, an HP-UX Secure Shell environment can dictate that all clients must authenticate using the public key or Kerberos methods. As a result, may disable the remaining methods. The enabling and disabling of supported authentication methods is through configuration directives specified in the sshd_config file. When an ssh client connection request is made, the server first responds with its list of supported authentication methods. This list represents the authentication methods supported by the sshd server and the sequence in which these methods will be tried. The client can omit one or more of those authentication methods. The client can also change the sequence in which the methods are attempted. You achieve this with a configuration directive in the client configuration file, /opt/ssh/etc/ssh_config. The authentication methods supported by HP-UX Secure Shell are summarized in the following sections. With the Generic Security Service application Programming Interface (GSS-API), a Kerberos-based client authentication, the client must obtain Kerberos credentials in advance, and also have a Kerberos configuration file present in the appropriate client directory. When a client connects with an sshd daemon, it presents its credentials at connection time. The server matches these credentials with its copy of credentials for this specific user. Also, the server can optionally establish the legitimacy of the client's host environment. For more information, see gssapi(5), kerberos(9) and Kerberos administrator documentation at: http://www.docs.hp.com/en/internet.html#Kerberos. For public key authentication, the Secure Shell environment must have the following setup:
After this setup is completed, ssh clients connecting to sshd servers are authenticated using public and private keys. For more information on public key cryptography, see public key cryptography. HP-UX Secure Shell offers an additional feature for streamlining public key authentication. For some environments, you might want the convenience of not having to respond to password prompts all the time. You can eliminate the need to respond to password prompts by using a combination of the ssh-agent and ssh-add processes, both running on the client machine. The client registers all its key information with the ssh-agent process through the ssh-add utility. Then, public key authentication between client and server is facilitated by ssh-agent without the sshd daemon having to interact with the client. Host-based and public key authentication is a more secure extension of the public key authentication method. In addition to having key pairs for both client and server, this method enables client environments to restrict the servers that they will communicate with. Implement this restriction by creating a .rhosts file in the client's home directory. The password authentication method relies on the existence of a single user ID and password-based login. This login could be based on the user's login specified in /etc/passwd, or it could be PAM-based. HP-UX Secure Shell is fully integrated with PAM modules available on the server system. For this purpose, the /opt/ssh/etc/sshd_config file carries a UsePAM configuration directive. If set to YES, any password authentication request from the client causes sshd to look at the PAM configuration file (/etc/pam.conf). Password authentication is then done through the configured PAM modules, in sequence, until successful. For more information on PAM authentication, see pam.conf(4). Set the UsePAM directive to NO to ignore PAM authentication. Then any password authentication request from the client causes sshd to ignore PAM configuration settings on the server. Instead, sshd obtains user password information by directly calling the getpwnam() library call HP-UX Secure Shell has been tested with PAM_UNIX, PAM_LDAP and PAM_KERBEROS. It is also expected to work with other PAM modules, such as PAM_DCE and PAM_NTLM. HP-UX Secure Shell users can connect with a remote sshd daemon using the SSH-1 or SSH-2 protocol. SSH-2 is more secure, and is strongly recommended instead of SSH-1. HP-UX Secure Shell is actually not a true shell. It is a mechanism for creating a secure connection between a client and a remote host to execute remote shell sessions securely on the host. To achieve the secure connection, HP-UX Secure Shell does most of the authentication and session creation itself. Following is a partial list of features that HP-UX Secure Shell uses:
As with all cryptographic key-based products, HP-UX Secure Shell requires a random number generator. It looks for the HP-UX Strong Random Number Generator special device files, /dev/urandom and /dev/random, and uses the first special device file it locates. If these two files do not exist on the system, HP-UX Secure Shell uses its own internal random number generator, ssh-rand-helper. The HP-UX Strong Random Number Generator improves the performance and entropy (a measure of the randomness and therefore the security of generated keys) of HP-UX Secure Shell. It generates nonreproducible, true random numbers. The use of the HP-UX Strong Random Number Generator is highly recommended with HP-UX Secure Shell. The HP-UX Strong Random Number Generator is available by default. For more information, see random(7). The HP-UX Secure Shell daemon, sshd, is linked with the archive library, libwrap.a, to support TCP Wrappers. See also Section . chroot is a directory jail. It starts up an application in a specified directory and restricts users to accessing that directory and the directories below it. It prevents users from changing directories above that specified directory. It is intended to restrict file and directory access to users of that application while they are using the application. You must enable chroot for an application. You must create new directories and copy the relevant set of files into those newly created directories. You can optionally set up ssh, scp, and sftp with a chroot directory. The HP-UX Secure Shell README file in /opt/ssh/README.hp explains the chroot feature, the chroot setup script, and the specific files that this script copies to enable ssh, sftp, and scp for a chroot environment. Refer also to chroot(1M). The chroot setup script is in the /opt/ssh/utils/ssh_chroot_setup.sh file, which is part of the HP-UX Secure Shell software product (Secure Shell 4.30.004/005). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
