[8771] in Info-AFS_Redistribution
Re: Openssh on solaris 2.5.1
daemon@ATHENA.MIT.EDU (Marcus Watts)
Wed Dec 12 23:21:37 2001
Message-Id: <200112130415.XAA12566@quince.ifs.umich.edu>
To: info-afs@transarc.com
In-reply-to: Your message of "Wed, 12 Dec 2001 11:48:18 PST."
<4.3.2.7.2.20011211153031.00aa9e60@mail2a.jpl.nasa.gov>
Date: Wed, 12 Dec 2001 23:15:42 -0500
From: Marcus Watts <mdw@umich.edu>
Peter Scott <Peter.J.Scott@jpl.nasa.gov> writes:
> I've been beating myself senseless trying to build OpenSsh 3.0.1 on Solaris
> 2.5.1 and there are AFS problems that no-one here has been able to solve.
...
> Client machine 'grimble' sends packet that includes the kerberos realm and
> "rcmd.grimble' (all else is binary).
> Server sends response that includes username, part of realm (last component
> is missing), and text "code = 8: Exec format er"
>
> Snooping the network when the old (SSH1) server runs reveals *no
> connection* to 'kerberos' over port 750 during successful login... only
> some stuff on 7002/7004.
8 == ENOEXEC (Exec format error), so something thought that was a Unix
error number. 8 is also used by Kerberos 4 to mean KDC_PR_UNKNOWN (Principal
unknown).
You say you're seeing traffic over 7002/7004. 7002 is prot (ptserver),
7004 is ka (kaserver). You're evidently running stock transarc kaserver
code, and the "old" code that you found is using RX to talk with kaserver
via port 7004 to authenticate, not something that's using UDP to talk via
750.
The error message you saw, "code = 8:", is coming from kaserver in
the routine "err_packet", in AFS source in the file kauth/krb_udp.c.
kaserver does support the MIT udp protocol, but the stock transarc
one gets confused about error codes. It's probably trying to return
what it calls KERB_ERR_PRINCIPAL_UNKNOWN (8), defined in kauth/prot.h.
If you have a non-stripped kaserver, you might try using a debugger
to set the variable krb_udp_debug and then run it and watch stdout.
It should produce various possibly useful text messages on stdout.
You'll probably need to find someone who can run the client side
from a debugger, and step through it to find out where things go
wrong. It sounds like somebody might be passing the wrong realm
name down somewhere, but it's got to be more complicated then that since
the client obviously found a cell that matched, and that means the
realm can't totally bogus.
-Marcus Watts
UM ITCS Umich Systems Group
