Solaris 9 SSH "Resync" Patches May Cause ssh(1) or sshd(1M) to Fail

---

Impact

The Solaris Secure Shell in Solaris 9 was updated with the patches 114356-07 and (or) 113273-11 to synchronize with the various enhancements made in Solaris 10. These Solaris 9 patches may cause the ssh(1) (Secure Shell) program or the sshd(1M) (Secure Shell daemon) program to fail to start.

Note: The Solaris 10 Solaris Secure Shell was updated to use OpenSSH 3.5p1 as a baseline in addition to features and bug fixes from OpenSSH versions prior to 3.8p1. Further details of the enhancements made to the Solaris Secure Shell in Solaris 10 can be found in the Solaris 10 "What's New" documentation at:

http://docs.sun.com/app/docs/doc/816-4557/6maosrjj8?a=view

Contributing Factors

These issues can occur in the following release:

SPARC Platform

• Solaris 9 with patches 114356-07 and/or 113273-11 and without patch 114356-08 (BugID 6402708)
• Solaris 9 with patches 114356-07 and/or 113273-11 and without patch 112908-29 (BugID 5020096)
• Solaris 9 with patches 114356-07 and/or 113273-11 and without patches 113273-13 and 114356-09 (BugID 6410762)

Notes:

1. Solaris 9 on the x86 platform is not affected, as the patches delivering the new Solaris Secure Shell will not ship until these issues have been resolved.
2. Solaris 10 is not affected by these issues.
3. Solaris 8 does not ship with SSH and is not affected by these issues.

A) To determine if these patches can cause the sshd(1M) daemon program to fail, the following command can be run:

    $ ldd /usr/lib/ssh/sshd | grep xfn

If output similar to:

    libxfn.so.2 =>   (file not found)

is seen, then sshd(1M) will fail to start.

B) To determine if these patches can cause the ssh(1) client program to fail, the following three (3) commands can be run:

    $ egrep '___slave_kdcs___|___domain_mapping___' /etc/krb5/krb5.conf

If output is returned then this issue may occur.

Also:

    $ grep <remotehost> $HOME/.ssh/known_hosts

The remotehost argument to grep(1) in the example above is the hostname specified on the ssh(1) command line. If no output is returned then this issue may occur.

And for the following command:

    $ ldd /usr/bin/ssh | grep xfn

if output similar to:

    libxfn.so.2 =>  (file not found)

is seen, then ssh(1) will fail to start.

Symptoms

Should the described issues occur, the ssh(1) client program may fail to start and will return error messages as in the following examples:

    $ /usr/bin/ssh remotehost
    xmalloc: zero size

    $ /usr/sbin/ssh remotehost
    unable to initialize mechanism library [/usr/lib/gss/gl/mech_krb5.so]

    $ /usr/sbin/ssh remotehost
    ld.so.1: /usr/bin/ssh: fatal: libxfn.so.2: open failed: 
    No such file or directory
    Killed

The sshd(1M) daemon program may fail to start and will return an error message (possibly via the console during boot) as in the following example:

    # /usr/lib/ssh/sshd
    ld.so.1: /usr/lib/ssh/sshd: fatal: libxfn.so.2: open failed:
    No such file or directory
    Killed

Workaround

To work around the sshd(1M) daemon failing to start and the ssh(1) client failing with the error message "libxfn", the SUNWfns "Federated Naming Service (XFN) - core libraries and utilities" package can be installed from the Solaris 9 media.

To work around the issue of ssh(1) failing with the error message "xmalloc", the ssh_config(4) option 'StrictHostKeyChecking' can be set to 'no'. Please see the the ssh_config(4) man page for details of the impact of making this change.

To work around the issue of ssh(1) failing with the error message "mech_krb5.so", either modify the krb5.conf(4) file (/etc/krb5/krb5.conf) to remove the following entries (as "root"):

    slave_kdcs
    domain_mapping

or GSS-API support can be disabled by adding the following entries to sshd_config(4) (/etc/ssh/sshd_config):

    GSSAPIAuthentication no
    GSSAPIKeyExchange no
    GSSAPIStoreDelegatedCredentials no

in addition to adding the following entries to ssh_config(4) (/etc/ssh/ssh_config):

    GSSAPIAuthentication no
    GSSAPIKeyExchange no

and then restarting the SSH service by running the following command (as "root"):

    # /etc/init.d/sshd restart

Resolution

This issue is addressed in the following release:

SPARC Platform

• Solaris 9 with patch 114356-08 or later (BugID 6402708)
• Solaris 9 with patch 112908-29 or later (BugID 5020096)
• Solaris 9 with patch 113273-13 or later and 114356-09 or later (BugID 6410762)

Modification History


Date: 22-JUN-2006

22-Jun-2006:

• Updated Relief/Workaround section

Date: 27-JUN-2006

27-Jun-2006:

• Updated Contributing Factors and Resolution sections

Date: 10-OCT-2006

10-Oct-2006:

• Removed BugID 6392328

Date: 09-JAN-2007

09-Jan-2007:

• Updated Contributing Factors and Resolution sections
• State: Resolved

Attachments

This solution has no attachment