Quest Software (logo)

Quest OpenSSH

Quest OpenSSH 5.1p1_q1 - Release notes

Updated: 5 Sep 2007

OpenSSH is a secure (encrypting, authenticating), network connectivity tool. Quest OpenSSH is based on the work of the OpenSSH-portable project and has been tuned to integrate well with Quest's Vintela Authentication Services (VAS). Quest OpenSSH and VAS provide a convenient and secure shell access service, authenticating users against a Microsoft Active Directory infrastructure.

This document describes the general contents of the Quest OpenSSH release packages. Platform-specific sections are provided with detailed requirements, installation procedures and platform-specific troubleshooting.

1 Source

1.1 Software origin

The Quest OpenSSH 5.1p1_q1 release uses the following sources:

1.2 Quest changes

Along with the configuration parameters listed later, the following changes have been merged with the origin source packages to create the Quest OpenSSH distribution:

Please refer to §8.2 Change history (non-packaging) for a more detailed change history.

2 AIX

Quest OpenSSH is available for the following AIX platforms:

2.1 Installation

2.1.1 Uninstall other versions of AIX

You may need to remove other installations of OpenSSH before installing this package. Installations of OpenSSH that may have been installed include:

2.1.2 Pre-installation requirements

2.1.2.1 VAS

Quest OpenSSH requires Vintela Authentication services version 3 or later be installed. Please refer to the VAS Installation guide for information on installing VAS.

2.1.2.2 LAM

Quest OpenSSH extends OpenSSH to use LAM authentication where available. This is available when keyboard-interactive authentication is selected in SSH protocol 2.

2.1.2.3 PAM

Without PAM

If your AIX5 system does not have PAM, or you wish to use LAM authentication for keyboard-interactive authentication, you should add this line to /opt/etc/quest/rc/ssh/sshd_config after installation: 

UsePAM no
Does your system have PAM?

PAM was not available for AIX 4.3.3 and is optional in AIX 5.1. If you don't have the files /usr/lib/libpam.a and /usr/lib/security/pam_aix on your system, then you don't have PAM.

If UsePAM is left at its default setting of on in /etc/opt/quest/ssh/sshd_config file, and you do not have /usr/lib/libpam.a installed on your system, then logins will fail ("Connection closed by host"), and you will see this error message in the server logs. 

PAM: initialisation failed
With PAM

If you want to use PAM, follow these steps:

  1. If you are using AIX 5.1 or 5.2, make sure you have installed the /usr/lib/security/pam_aix module. PAM is available with AIX 5.1.0.1
  2. Ensure you have an /etc/pam.conf file. If not, obtain and install the example configuration file from the URL in step 1.
  3. Ensure that 'sshd' entries exist in /etc/pam.conf, e.g: 
    sshd    auth     required       /usr/lib/security/pam_aix
sshd    account  required       /usr/lib/security/pam_aix
sshd    password required       /usr/lib/security/pam_aix
sshd    session  required       /usr/lib/security/pam_aix
    If these entries are missing, you will see the server error 
    PAM: pam_open_session(): Can not make/remove entry for session
  4. Run the following to update VAS's hooks into /etc/pam.conf. 
    # /opt/quest/bin/vastool configure pam
    vastool will duplicate the new sshd entries, and insert entries that use the pam_vas.so module that is right for your system.

For installations of AIX (5.2 and later) with functional PAM and existing "sshd" entries, no modification is needed as the defaults are satisfactory. Please refer to your /etc/pam.conf file.

The service name for Quest OpenSSH's daemon is "sshd". Please remember to run vastool configure pam after you make substantial changes to /etc/pam.conf.

2.1.3 /etc/environment

The PATH variable in /etc/environment is automatically modified to include /opt/quest/bin when Quest OpenSSH is installed on AIX. This can be undone manually, but scp will complain; See §6.2.3 scp: scp not found? for details.

2.1.4 Installing a bff package

Install/upgrade the Quest OpenSSH package using the following command: 

# installp -aX -d quest-openssh-<version>.bff quest-openssh
Alternatively, you can use AIX's menu-driven SMIT tool: 
# smitty install_package

The Quest OpenSSH server is NOT started on installation. It may be controlled as a subsystem using the Web-based System Manager (wsm), or by using the commands 

# stopsrc -s sshd-quest
# startsrc -s sshd-quest

2.1.5 Installation paths

The Quest OpenSSH package installs into /opt/quest, and /opt/quest/bin may need to be added to your PATH environment variable.

Configuration files for Quest OpenSSH are installed into /etc/opt/quest/ssh.

2.2 AIX Build Configuration

2.2.1 OpenSSL configuration

Quest OpenSSH is linked with selected sections of OpenSSL. Please note that OpenSSL will use the /dev/random device on AIX 5.2 and 5L, to provide cryptographic strength to Quest OpenSSH ciphers.

On AIX 5.1, if OpenSSL cannot find a source of randomness (from either /dev/random or an entropy gatherer daemon) then Quest OpenSSH will generate its own entropy using the ssh-rand-helper program, with significant performance loss.

2.3 Packaging and AIX-specific change history

quest-openssh-4.6p1
  • bug 110: /opt/quest/bin added to /etc/environment's PATH during install
vas3-openssh-4.4p1q89
  • service is now called "sshd-quest"
  • bug 31: home directory creation failed on aix
  • bug 74: keyboard-interactive for AIX LAM when PAM unavailable
vintela-openssh-4.1vrc1.8.0.1
  • Improved debugging around setpcred()
  • Create piddir on install if it isn't there (bug 5151)
  • Install init script/service as "sshd-vrc" instead of "ssh" (bug 5473)
vintela-openssh-4.1vrc1.7.2-3
  • Fix dynamic PAM bug under aix5.1 (bug 5148)
vintela-openssh-4.0vrc1.7.1
vintela-openssh-3.9p1vrc1.4-3
  • Unified package names; source addition
openssh-3.9p1vrc1.3pam-8
  • Correct installation scripts

3 HP-UX

3.1 Package files

This release consists of the following files:

The depot file contains

3.2 Prerequisites

Quest OpenSSH is known to work on the following platforms:

3.2.1 VAS

Quest OpenSSH requires VAS 3.0 or later. See the Vintela Authentication Services Install Guide for information on installing VAS.

3.3 Installation

3.3.1 Installing from a depot file

The software depot file can be installed using hp-UX's swinstall tool: 

# swinstall -s <path>/quest-openssh-<version>.depot quest-openssh
where quest-openssh-<version>.depot is the path to the depot file.

Note: There may be a long delay during installation as Quest OpenSSH generates fresh host keys (a CPU intensive operation).

3.3.2 Starting the SSH server

Note that the Quest OpenSSH server is not started on install, although it will be started on the next system boot. The server can be started manually with the command: 

# /sbin/init.d/sshd-quest start
or by using sam (SAM -> Quest-OpenSSH -> Enable OpenSSH server) which will also control if the server automatically starts after a system reboot.

3.3.3 Configuring OpenSSH

Further information on configuring Quest OpenSSH after it is installed can be found in the online documentation (add /opt/quest/man to your MANPATH environment variable) or from http://www.openssh.org/.

3.3.4 Uninstalling

Uninstall Quest OpenSSH with the following command: 

# swremove quest-openssh

3.4 Entropy and performance under hp-UX

During operation, Quest OpenSSH must locate a source of entropy (randomness) to provide a minimum level of cryptographic strength. Depending on the version and configuration of your hp-UX system, generating entropy may cause Quest OpenSSH to run very slowly or give poor operational performance.

The preferred way for Quest OpenSSH to initialise its cryptographic state is through the operating system's /dev/random pseudo-device. This is fast, and very secure. HP provides a /dev/random driver for hp-UX 11i (11.11), named 'KRNG11I'. It is available, for free, from the KRNG11I depot. You can check if this is already installed by running: 

$ swlist KRNG11I

For older versions (hp-UX 11.00), an open-source implementation of /dev/random is available from http://www.josvisser.nl/hpux11-random.

Also for hp-UX versions prior to 11.00, Quest OpenSSH will use its internal OpenSSL library to search for the entropy gathering daemon (EGD). The EGD is available from egd.sourceforge.net. The EGD places some load on the host while it initially gathers entropy, but once gathered, it can provide a strong source of randomness to Quest OpenSSH quickly.

Quest OpenSSH determines which source of entropy to use by following these steps:

  1. Quest OpenSSH asks OpenSSL for an entropy source. OpenSSL looks for entropy, in the following places, in order:
    • /dev/urandom (device)
    • /dev/random (device)
    • /dev/srandom (device)
    • /var/run/egd-pool (socket)
    • /dev/egd-pool (socket)
    • /etc/egd-pool (socket)
    • /etc/entropy (socket)
  2. If OpenSSL cannot find a source of entropy, the Quest OpenSSH server (sshd) invokes a helper program (ssh-rand-helper) which executes commands in the configuration file /etc/opt/quest/ssh/ssh_prng_cmds and hashes their output to provide entropy.

The fallback, ssh-rand-helper, can have a significant performance penalty on Quest OpenSSH's operation. Please see the installed file /opt/quest/share/ssh/WARNING.RNG.

3.5 HP-UX package change history

4 Linux

4.1 Distributions files

This release consists of the following files:

quest-openssh-<version>.rpm SSH client and server
quest-openssh-doc-<version>.rpm Documentation for SSH client, server

4.2 System compatibility

Quest OpenSSH is known to work on the following platforms:

4.3 Prerequisites

4.3.1 VAS

Quest OpenSSH requires Vintela Authentication Services 3.0 or later. Please refer to the Vintela Authentication Services Installation guide.

4.3.2 Stop other instances of sshd

You may need to shut down other SSH daemons running on your system if you wish to use the server component of Quest OpenSSH. This is often possible with a command like this: 

# /etc/init.d/sshd stop

4.3.3 Remove older Vintela OpenSSH packages

Previous installations of Quest OpenSSH may need to be removed before installing quest-openssh. Earlier packages were named vintela-openssh and vas3-openssh.

4.4 Installation

Install/upgrade the Quest OpenSSH package using the following command: 

# rpm -Uvh quest-openssh-<version>.rpm
This will install the package, or upgrade an already installed quest-openssh package.

4.5 Post-installation

4.5.1 Paths and configuration

Configuration files can be found in /etc/opt/quest/ssh. Please see the manual pages for ssh_config(8) and sshd_config(8) for details on the contents of these files.

4.5.2 Automatic server startup

The Quest OpenSSH server can be started automatically or manually. You can perform manual start up with the following command: 

# /etc/init.d/sshd-quest start

Automatic start-up is described for different platforms in the next sections.

4.5.2.1 SuSE Linux

The quest-openssh service appears in the runlevel table as the entry "sshd-quest". Follow these steps to enable it: 

  1. # yast2 runlevel
  2. Stop/disable "sshd": as it may conflict on port 22
  3. Enable/start the "sshd-quest" service.
4.5.2.2 Red Hat Linux
  1. # system-config-services
  2. Stop/disable "sshd": as it may conflict on port 22
  3. Enable/start the "sshd-quest" service.

Alternatively, use the chkconfig command-line tool.

4.5.3 PAM configuration

Examine /etc/pam.d or /etc/pam.conf to ensure that there is an entry for the "sshd" service, or that the default (usually named "other") will be suitable for Quest OpenSSH.

If there isn't, you should copy the entry for "login" or a similar service, and name it "sshd". Be sure to run the following command so that the VAS hooks into PAM are retained: 

# /opt/quest/bin/vastool configure pam

PAM configurations should be fixed in a future release of Quest OpenSSH.

4.6 Troubleshooting

4.6.1 The server fails to start on installation

Use the ps command to see if there are any remnant sshd processes remaining that may be occupying port 22. This can happen even if you have just uninstalled another instance of Red Hat's openssh or openssh-server package.

4.7 Linux package change history

5 Solaris

5.1 Distributions files

This release consists of the following files:

5.2 Pre-installation

Quest OpenSSH is known to work on the following platforms:

Note that only 32-bit versions of Quest OpenSSH applications are provided for Solaris. The packages supplied will function on sparc64 and x86_64 systems.

5.2.1 Prerequisites

Quest OpenSSH requires Vintela Authentication Services 3.1.2 or later. Please refer to the Vintela Authentication Services Installation guide.

5.2.2 Stop other OpenSSH servers

This release may conflict with other installed versions of OpenSSH, including the releases from sunfreeware.com, and from the Solaris 'Software Companion' CD.

Look for other packages using the following command, and consider removing or disabling their server. 

$ pkginfo | grep -i ssh

Alternatively, Quest OpenSSH server may be configured to listen on a non-default port. (See the Port option in sshd_config(8).)

5.2.3 /dev/random option

Quest OpenSSH requires an entropy (random number) source. If Quest OpenSSH cannot find or create entropy itself, you will see the following error message at package install time (as the host keys are being generated) and after installation when the ssh client is run: 

PRNG is not seeded
Entropy is generally obtained from /dev/random which is an interface to a kernel random source. On Solaris 2.8, the /dev/random driver is provided in the following patches from http://sunsolve.sun.com/:

If /dev/random is not available for the OpenSSL library used by Quest OpenSSH it will look for an entropy gatherer daemon. If this is not found, Quest OpenSSH will attempt to generate entropy using a fallback, low-performance technique.

Instructions for obtaining and installing an entropy source (prngd) for Solaris 2.6 can be found at http://www.sunfreeware.com/openssh26-7.html#ent

5.3 Installation

Install the Quest OpenSSH package using the following commands: 

# pkgadd -d quest-openssh-<version>.pkg QSFTossh

where quest-openssh-<version>.pkg is the path to the package.

5.4 Post-installation

5.4.1 Configure PAM

You may need to edit the file /etc/pam.conf and insert special rules for the Quest OpenSSH service. If you do not, Quest OpenSSH will use the default rules (named "other") and this may be sufficient for your purposes. Otherwise, the PAM service name for the Quest OpenSSH daemon is "sshd".

If you do make changes to /etc/pam.conf, be sure to run the following command so that the VAS hooks into PAM are retained: 

# /opt/quest/bin/vastool configure pam

5.4.2 Configure Paths

You may want to add /opt/quest/bin to your PATH environment variable.

Configuration files can be found in /etc/opt/quest/ssh. Please see the manual pages for ssh_config(8) and sshd_config(8) for details on the contents of these files.

5.4.3 Transfer existing host keys

Quest OpenSSH for Solaris attempts to copy existing host keys from /etc/ssh and /usr/local/etc/ssh unless keys already exist in /etc/opt/quest/ssh If you wish to preserve host keys from another, version-compatible installation of OpenSSH, you will have to copy the keys (possibly overwriting the ones created during installation). See also §6.2.2 Why have my host keys changed?.

5.4.4 Manually starting the server

The server can be initially, manually started with: 
# /etc/init.d/sshd-quest start
Otherwise, the server will be automatically started on the next reboot.

5.5 Platform support

This release has been tested for basic functionality on the following platforms:

5.6 Uninstalling

To uninstall this package, use this command: 

# pkgrm QSFTossh

5.7 Developer notes

If you are compiling Quest OpenSSH yourself, please note that for linking against some versions of OpenSSL on Solaris/i386 with GNU gcc, a compiler environment patch may be required.

5.8 Build change history for Solaris

4.6p1_q1
  • bug 280: NIS+/pam_dhkeys credentials were not established (upstream 1339)
4.5p1_q1
  • Changed package name to QSFTossh
  • service is now called "sshd-quest"
vintela-openssh-4.1p1vrc1.8.0-1
  • Changed package name from VTLAopenssh to QSFTopenssh
  • Init script name is now sshd-vrc in line with other packages (bugs 4619, 5100)
  • Existing host keys are copied if needed at install time (bug 4394)
vintela-openssh-3.9p1vrc1.4-12
  • Compiled against Solaris2.6 libraries
  • Renamed package from OpenSSH to vintela-openssh
  • Added source bundling
  • Changed sysconfdir from /etc/opt/vintela/rc to /etc/opt/vintela/rc/ssh

6 Troubleshooting

This section describes common operational problems with Quest OpenSSH and their solutions.

6.1 Tracing OpenSSH operations

If you are experiencing problems, such as rejected authentication, it may help you to run the OpenSSH client and server in a 'verbose' mode so that you can narrow down the problem's cause.

The OpenSSH client (ssh) will emit useful debugging information when invoked with the -v flag.

The server (sshd) is substantially different. To view debug/trace information from the server, it is perhaps easiest to run the server manually, on a different port and as root, with the command: 

# /opt/quest/sbin/sshd -p 2222 -ddde

Test the server by running the client with the options -p 2222. This uses TCP port 2222 instead of the standard port, 22. 

$ /opt/quest/bin/ssh -p 2222 -v myhost

Instructions for enabling verbose information from the VAS and PAM modules can be found in appendix A.5 of the VAS Installation Guide, and in the manual pages for pam_vas(5) and vastool(1).

6.2 Specific problems

6.2.1 Credential forwarding isn't working

Credential forwarding (also known as delegation) is only reliable with VAS releases AFTER 2.6.24. Run the following command to ensure your version of VAS is later than 2.6.24: 

$ vastool -v

The main cause of credential delegation failure is that the user has logged in with credentials that are flagged non-forwardable. You should ensure that, on your client side, in the file /etc/opt/quest/vas/vas.conf, the "[libdefaults]" section contains this setting: 

forwardable = true

This can be done with an editor, or by running this command: 

# vastool configure vas libdefaults forwardable true

You can verify that your TGT (login ticket) is forwardable by running these commands on your client host (i.e. before invoking ssh): 

$ vastool klist -v

You should see a ticket named krbtgt/DOMAIN@DOMAIN with 'forwardable' amongst its flags. If your TGT is not forwardable, and you have only just changed the vas.conf file to make them so, you may have to delete them and re-acquire them: 

$ vastool kdestroy
$ vastool kinit

Once you are sure that your tickets are forwardable, and that Active Directory trusts the remote computer for delegation, invoke ssh to login using GSSAPI. When logged in to the remote host, check your TGT has been correctly forwarded by running vastool klist -v remotely.

If you are connecting to a Quest OpenSSH server from a Microsoft Windows SSH client, you will also need to enable the ok-as-delegate flag on the target computer account. This flag is currently ignored by the OpenSSH unix client, but honoured on the Windows platform. The flag, described in Active Directory as trust host for delegation, is disabled by default on computer objects and must be explicitly enabled by a directory administrator. Without the ok-as-delegate flag, even though the Windows SSH client may request delegation, the underlying service will silently ignore it, and TGT delegation will not occur.

6.2.2 Why have my host keys changed?

If migrating from a different distribution of OpenSSH, some users may find that the server's host key has changed. This is because on some platforms there is no standard place for host key files. Quest OpenSSH will create new host keys rather than possibly revive stale ones on such platforms.

If you want to avoid this, and know where your host keys are, either modify Quest OpenSSH's sshd_config file to point at the right HostKey location, or copy the right host key files from the other installation into /etc/opt/quest/ssh directory, and restart the sshd server.

Host keys can be avoided by using GSS-KEX. See documentation on the HostKeys option of sshd_config(5).

6.2.3 scp: scp not found?

When using scp to transfer files, the remote end may complain that scp cannot be found. This is probably because the remote ssh server process for your login does not have /opt/quest/bin in its PATH. You can fix this by editing a platform-specific system file such as /etc/environment, or by placing a symbolic link to scp in /usr/bin. Please see the manual page sshd_config(5) for more mays to manipulate the default user environment.

6.2.4 SSO works just once ?

"I can login once with gssapi-with-mic, but after that I am prompted for a password?"

You probably have a shared home directory, or have multiple sessions using a cred cache with the same name (usually stored in /tmp). A feature of the VAS PAM module is that it can manage your shared credential cache when you logout.

A workaround is to use credential delegation. When credentials are delegated, they are stored by VAS in a temporary credentials cache file with a unique name. This file is safely deleted when the SSH session closes, and contains a copy of your login ticket.

Another workaround is to add this to sshd_config: 

GSSAPICleanupCredentials no

6.2.5 Address family not supported, on AIX

syslog: The user option is different from the address family passed into
the API.
sshd[32160]: error: getnameinfo failed: Address family not supported
sshd[32160]: fatal: Cannot bind any address.

On some maintennance levels of AIX, the system's getaddrinfo() function returns incorrect data that will result in "Address faily not supported" errors. ([1]).

This problem is resolved by APARs IY54776(5.1 ML7) or IY46023(5.2 ML2).

6.2.6 "Error: cannot open display: "

On some Linux systems, attempting to run X applications with Quest OpenSSH's X11 forwarding may result in the error message 

Error: cannot open display:
This may be because our package was configured with xauth in a different location: the full path to xauth is hard-coded into the sshd executable at build time.

A workaround is to determine the location of xauth on your system (let's say it's /usr/bin/xauth) and then add this line to /etc/opt/quest/ssh/sshd_config: 

XAuthLocation /usr/bin/xauth

You will need to restart your sshd server for the change to take effect.

6.2.7 Cannot delegate tickets from Solaris VAS 3.3 client

There is a known issue where TGTs will not be delegated by the Quest-OpenSSH client (ssh) when it is installed with VAS 3.3 on Solaris. Please upgrade to the latest VAS version, or downgrade to an earlier version of VAS (say 3.2.0.108).

6.2.8 Addresses in hosts.allow not working

In Quest-OpenSSH releases prior to 5.0, an IP address specified in /etc/hosts.allow may be ineffective when sshd is listening on an IPv6 wildcard interface, because incoming connections will be mapped to v4-in-v6 addresses. This is fixed in Quest-OpenSSH 5.0.

The symptom that SSH users see is the following message as tcp_wrappers denies their connection: 

ssh_exchange_identification: Connection closed by remote host

To workaround, try disabling IPv6 by uncommenting the following line in /etc/opt/quest/ssh/sshd_config: 

Listen 0.0.0.0

An alternative is to ensure sshd is invoked with the -4 option (which forces IPv4 addresses only).

Note that attempting to listen on both wildcard addresses may fail. That is: 

Listen ::
Listen 0.0.0.0
will fail on systems that use a shared port space for IPv6 and IPv4 with the following message: 
Server listening on :: port 22.
Bind to port 22 on 0.0.0.0 failed: Address already in use.

However, the system may be tuned to allow this. On Linux, see the file /proc/sys/net/ipv6/bindv6only.

6.3 Problems with VAS

Please see the troubleshooting appendix of the VAS Installation Guide, available as a PDF download from http://www.vintela.com/products/vas. Common problems include:

6.4 Reporting bugs

We're always interested to hear about bugs in the latest version of Quest OpenSSH that cannot be solved by reading the documentation or troubleshooting sections.

You can help us by sending a detailed bug report: collect as much logged information demonstrating the problem as you can (especially see §6.1 Tracing OpenSSH operations), including operating system details and version numbers, so that the recipient is able to reproduce your problem. Then, send the report to the right authority:

7 Building from source

Quest OpenSSH is also available in source form from the download section for users who need support on platforms we haven't provided binary packages for. This section provides some notes for building Quest OpenSSH from source.

8 Licensing

Please see http://rc.quest.com/topics/openssh/license.php.

9 Miscellaneous

9.1 Interoperability

The Quest OpenSSH server's single sign-on feature is known to work with the following SSH clients:

10 Change History

This section outlines the change history of the non-packaging component of Quest OpenSSH.

10.1 Change history (non-packaging)

The full change summary has been moved out of this file. A log of changes due to Resource Central is available at Changelog file. Platform-specific sections above summarise the platform-relevant changes made to packaging.

A summary of changes due to the upstream OpenSSH project can be found in their Release announcement, and a detailed change log from the OpenSSH Portability project can be found in the adjacent Changelog file.

10.2 About Quest OpenSSH version numbers

Resource Central package names consist of the following information:

  1. Quest prefix: quest- (QSFT for Solaris)
  2. The project name: openssh (ossh for Solaris)
  3. Upstream version number: 4.5p1
  4. Separator: _q
  5. Resource Central release number: 1
  6. Dot: .
  7. Subversion revision/build number: 112

Previous releases maintained a separate version hierarchy for Resource Central indicated by the number following the vrc.