From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7) Gecko/20040628 Firefox/0.9.1

Description of problem:
We are attempting to compile OpenSSH with GSSAPI for kerberos5
passwordless authentication (this allows access to AFS space using
aklog and Kerberos 5 forwarding) for an MPI cluster.

We attempted patching the openssh.spec file to change the revision to
33.30.1.gss, and `rpbuild -ba SPECS/openssh.spec` created (seemingly)
appropriate RPMS.  During testing, however, we discovered that SSH
logins would work fine as long as GSSAPI (Kerberos 5) authentication
was not attempted.  On attempting GSSAPI login, the connection would
be unexpectedly closed by the server.

This configuration had been tested on i386 clients previously with
expected results (login from client to server without password dialog).

The log messages from running 'sshd -d -p 1022' as root (starting sshd
in debug mode on port 1022 for one connection) and connecting as an
appropriate client indicate that the crash is occurring around line
1780 of monitor.c, in the function mm_answer_gss_sign.  The fatal
error that occurs is from this section of code:

        data.value = buffer_get_string(m,&data.length);
        if (data.length != 20)
                fatal("%s: data length incorrect: %d", __func__,
data.length);

The value that is printed for data.length from this error is "20",
which seems to indicate a 32/64-bit problem.

Version-Release number of selected component (if applicable):
openssh-3.6.1p2-33.30.1.gss, and openssh-3.6.1p2-18.gss

How reproducible:
Always

Steps to Reproduce:
1. Install openssh src rpm, change "%define rel 33.30.1" to "%define
rel 33.30.1.gss" in openssh.spec

2. Build openssh-3.6.1p2-33.30.1.gss RPMS on x86_64, and install
openssh-server and openssh-client RPMS on a machine.  Add the line
"GSSAPIAuthentication yes" to /etc/ssh/ssh{,d}_config, or run ssh and
sshd with the -o GSSAPIAuthentication=yes flag for testing.

3. Install Kerberos 5 keytab for host/<fqdn-of-machine>@REALM

4. Acquire Kerberos 5 credentials through login or kinit.

5. ssh <fqdn-of-machine>

Actual Results:  Output of 'ssh -v <fqdn-of-machine>'

debug1: Mechanism encoded as A/vxljAEU54gt9a48EiANQ==
debug1: An unsupported mechanism was requested
No error

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: Calling gss_init_sec_context
debug1: Delegating credentials
Connection closed by <ip-addr>
debug1: Calling cleanup 0x41b3a0(0x0)


Output of 'sshd -d':
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: using GSSAPI mechanism Kerberos
(gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==)
debug1: Wait SSH2_MSG_GSSAPI_INIT
debug1: Received some client credentials
debug1: gss_complete
mm_answer_gss_sign: data length incorrect: 20
debug1: Calling cleanup 0x428e20(0x0)


Expected Results:  Logged in to target machine (which can be same
machine) with preserved Kerberos credentials, without needing to enter
a password.

Additional info:

This seems to be related to bug 126521, which is listed as applying to
FC1.  I have added a short note to that bug, as well.  The patch
listed in that bug does seems to apply cleanly to the RHEL 3 packages,
and I am using that as a temporary work-around until official RHEL 3
srpm packages are released.