Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
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)

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

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:

  • Strong authentication for both client and the remote host.

  • Strong encryption and public key cryptography for communication between a client and the remote host.

  • A secure channel for the client to use to execute commands on the remote host.

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

Key Security Features of HP-UX Secure Shell

The key security features of HP-UX Secure Shell include the following:

  • Strong encryption

    All communication between the client and the remote host is encrypted using patent-free encryption algorithms, such as Blowfish, 3DES, AES, and arcfour. Authentication information, such as passwords, is never sent in clear text across the network. Encryption in conjunction with strong public key-based cryptography also provides protection against potential security attacks.

  • Strong authentication

    HP-UX Secure Shell supports a strong set of authentication methods between client and server. The authentication can be two-way: the server authenticates the client, and the client authenticates the server. This protects the session against a variety of security issues. The supported authentication methods are described Section .

  • Port forwarding

    The redirection of TCP/IP connections between a client and a remote host (and back) is referred to as port forwarding or SSH tunneling. HP-UX Secure Shell supports port forwarding. For example, ftp traffic between a client and a server (or email traffic between an email client and a POP/IMAP server) can be redirected using port forwarding. Instead of the client directly communicating with its server, the traffic can be redirected to an sshd server over a secure channel, and the sshd server can then forward the traffic to a designated port on the real server machine.

  • Integration with underlying HP-UX security features.

    The HP-UX Secure Shell product is integrated with important HP-UX security features. For more information, see Section .

Software Components of HP-UX Secure Shell

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

ComponentDescriptionLocationEquivalent non-secure component(s)
sshSecure Shell client is a secure replacement for telnet and remsh; it is most similar to remsh with security featuresClientremsh, telnet, rlogin
sloginSymbolic link to sshClientremsh, telnet, rlogin
scpSecure copy client and secure copy serverClient and serverrcp
sftpSecure ftp clientClientftp
sshdSecure shell daemon Serverremshd, telnetd, rlogind
sftp-serverSecure ftp daemon Serverftpd
ssh-rand-helperRandom number generator, which is used when sshd is not able to find /dev/random or /dev/urandom on the server. HP-UX is shipped with a kernel-resident random number generator, rng. If rng is deconfigured, sshd uses prngd. ServerNot applicable
ssh-agentTool for "automatic" key-based login from client to serverClient and serverrhosts file mechanism
ssh-addTool for making key pairs of the client known to ssh-agentClientNot applicable
ssh-keygenTool for generating key pairs for public key authenticationClientNot applicable
ssh-keyscanTool for a client to gather the public keys for a set of hosts running the Secure Shell daemon (sshd)ClientNot applicable
ssh-keysign

Tools to generate the digital signature required during host based authentication is and it is used by ssh() to access the local host keys host based authentication

Client

Not applicable

 

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

Running the ssh Client

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:

  • On every client system connected to the sshd server, there is one ssh client process for each ssh connection currently established from that client system.

  • On the server system, there is one parent sshd process and as many child sshd processes as there are concurrent ssh clients connected to the server. The number of child sshd processes running on the server doubles if privilege separation is enabled on the server. See Section .

  • On the server system, for each command execution request from a ssh client, the corresponding child sshd process spawns a shell process, and uses a UNIX pipe to communicate the command request to this shell process. This shell process returns the command execution results to the child sshd process using the UNIX pipe and terminates when the command execution is complete.

Running the sftp Client

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:

  • The sftp client and the ssh client, on the client system, using a UNIX pipe.

  • The ssh client and the child sshd process, over the established connection socket.

  • The child sshd process and the sftp server process, using a UNIX pipe.

Running the scp Client

The scp client case is almost identical with the sftp client execution. The difference is that instead of spawning the sftp-server process, the child sshd process spawns the scp process. All subsequent communication during the scp session occurs among the following processes:

  • The scp client and the ssh client, on the client system using a UNIX pipe.

  • The ssh client and the child sshd process, over the established connection socket.

  • The child sshd process and the scp server process, using a UNIX pipe.

HP-UX Secure Shell Privilege Separation

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.

NOTE: Privilege separation is the default configuration for HP-UX Secure Shell. You can turn off privilege separation by setting UsePrivilegeSeparation NO in the sshd_config file. Because of the potential security risk, turn off privilege separation only after careful consideration.

HP-UX Secure Shell Authentication

HP-UX Secure Shell supports the following authentication methods:

  • GSS-API (Kerberos-based client authentication)

  • Public key authentication

  • Host-based authentication

  • Password authentication

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.

GSS-API

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.

Public Key Authentication

For public key authentication, the Secure Shell environment must have the following setup:

  • Both the client and server must have a key pair. Every ssh client and every sshd server must generate a key pair for themselves using the ssh-keygen utility.

  • The client must make its public key known to all sshd servers it needs to communicate with. Do this by copying every client's public key into a predetermined directory on every relevant server.

  • The client must acquire the public key for every server it needs to communicate with. The client acquires the public keys using the ssh-keyscan utility.

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

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.

Password Authentication

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.

Communication Protocols

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 and the HP-UX System

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:

  • Logging of login attempts

    Like telnet or remsh, HP-UX Secure Shell logs successful and unsuccessful sessions in the /var/adm/wtmp and /var/adm/btmp files, respectively. For more information, see utmp(4).

  • PAM modules

    As described in Section , HP-UX Secure Shell can use PAM authentication for client sessions. When PAM authentication is selected, HP-UX Secure Shell uses the /etc/pam.conf file and invokes the appropriate PAM module for authentication. See pam.conf(4) for more information about the /etc/pam.conf file.

  • Use of /etc/default/security file

    This is a systemwide configuration file that contains attributes defining the behavior of login, passwords, and other security configurations. HP-UX Secure Shell allows use of these attributes with some restrictions, which are explained in the /opt/ssh/README.hp file for HP-UX Secure Shell.

    More information on the /etc/default/security file is in security(4).

  • Shadow passwords

    HP-UX Secure Shell is integrated with the HP-UX shadow password feature. For more information, see shadow(4).

  • Control system log (syslog)

    HP-UX Secure Shell uses syslog to write important messages. For more information, see syslog(3C) and syslogd(1M).

  • Audit logging

    HP-UX Secure Shell has implemented audit logging (in trusted mode) in its own code. For more information, see audit(5).

Associated Technologies

HP-UX Secure Shell has been tested with the following technologies:

  • Kerberos 5 and GSS-API

  • OpenSSL

  • IPv6

  • TCP Wrappers

  • PAM (PAM_UNIX, PAM_Kerberos, PAM_LDAP)

  • HP-UX Strong Random Number Generator

Strong Random Number Generator Requirement

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

TCP Wrappers Support

The HP-UX Secure Shell daemon, sshd, is linked with the archive library, libwrap.a, to support TCP Wrappers. See also Section .

chroot Directory Jail

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
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2008 Hewlett-Packard Development Company, L.P.