Bug 130693 - GSSAPI authentication crashes OpenSSH on x86_64
Summary: GSSAPI authentication crashes OpenSSH on x86_64
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: openssh
Version: 3.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-23 19:19 UTC by Evan Anderson
Modified: 2007-11-30 22:07 UTC (History)
0 users

Clone Of:
Last Closed: 2005-04-05 20:16:03 UTC

Attachments (Terms of Use)

Description Evan Anderson 2004-08-23 19:19:18 UTC
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__,

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:

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

Comment 1 Tomas Mraz 2005-04-05 20:16:03 UTC
As you have to compile the packages on your own you can apply the patch from the
bug 126521 to them anyway.

The GSSAPI patch is unsupported and is not compatible with the upstream GSSAPI
as of openssh-3.9p1 and higher anyway. It's even susceptible to a man in the
middle attack.

Note You need to log in before you can comment on or make changes to this bug.