Dear managers,
I got an excelent solution from Mr. Kevin Sullivan, Pittsburgh
Supercomputing Center. There is a conflict between library function calls
in kth-krb and OpenSSL. After applying the workaround, everything goes
well. I have only to mention that the second problem was probably not
realet to incorrect server key version - it disappeared after modifying
the source and relinking ssh/ssd binaries.
Thanks a lot.
BR,
David Komanek
Charles University
KEVIN SULLIVAN'S GUIDE
======================
On Thu, 22 Mar 2001, Kevin Sullivan wrote:
> I managed to get it running. Boy, was this a pain!
>
> I found that the DES libraries in OpenSSL were conflicting with the DES
> libraries in kth-krb. I did the following:
>
> * Made a copy of libcrypto.a (from OpenSSL)
> * Removed set_key.o and des_enc.o from the copy
> * Added des_set_key_unchecked() (just call des_set_key()) to set_key.c and
> recompile a new libdes.a (from kth-krb).
> * Linked ssh and sshd with the modified libcrypto.a and libdes.a. I think
> I had to play with the order of the libraries to get the link to work.
>
> This worked for both Tru64 4.0f and 5.0.
>
> OpenSSH wants you to have a rcmd.`hostname` kerberos ID per sshd, with a
> proper /etc/srvtab file. Older versions of SSH didn't care about this for
> AFS authentication. It's easy to set up, it's just a pain if your Krb4
> servers are actually AFS servers (like ours are).
>
> --
> Kevin Sullivan
> Pittsburgh Supercomputing Center
>
>
ORIGINAL MESSAGE:
=================
Dear administrators,
did you managed to run OpenSSH with kth-krb ver. IV ? Please, if you have
some comments to the problem described bellow, say them :-)
Thanks in advance.
Sincerely,
David Komanek
Charles University
Prague
CZ
When I use
ssh -l username machine
without any Kerberos ticket, I'm normaly prompted for the password and can
successfully log in.
If I issue
kinit
to get the ticket and then use "ssh", The client ends up wth a core dump:
OpenSSH_2.5.2p1, SSH protocols 1.5/2.0, OpenSSL 0x00906010
debug1: Seeding random number generator
debug1: ssh_connect: getuid 222 geteuid 0 anon 0
debug1: Connecting to xyz [xxx.yyy.zzz.www] port 22.
debug1: Allocated local port 1022.
debug1: Connection established.
debug1: identity file /usr/users/username/.ssh/identity type 0
debug1: Remote protocol version 1.99, remote software version
OpenSSH_2.3.0p1
debug1: match: OpenSSH_2.3.0p1 pat ^OpenSSH_2\.3\.0
debug1: Local version string SSH-1.5-OpenSSH_2.5.2p1
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
debug1: Host 'bbs' is known and matches the RSA1 host key.
debug1: Found key in /usr/users/username/.ssh/known_hosts:2
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Remote: Kerberos V4 tgt accepted
(krbtgt.XXX.YYY.ZZZ_at_XXX.YYY.ZZZ, username_at_XXX.YYY.ZZZ)
debug1: Trying Kerberos authentication.
debug1: Trying to reverse map address xxx.yyy.zzz.www.
Segmentation fault
It faults somewhere in the krb_mk_req() function. The same code in the
kerberos telnet works fine. I noticed this problem only with ssh client
running on tru64, regardless if connecting to daemons on the same or other
platforms. Clients running i.e. on IRIX are working well.
Another problem, probably coupled with: if I connect with the client from
another platform, i.e. IRIX, to the OpenSSH daemon running on Tru64, it
claims "bad principal name (kerberos)" after I get the ticket and try to
connect with. But working against "SSH 1.1.27" or using Kerberos Telnet
works fine, so I don't think this is the Kerberos server problem.
Tested on:
Tru64 4.0D, latest patchkit
OpenSSH both 2.2.3p1, 2.5.2p1 (Kerberos and AFS options used)
kth-krb 1.0.6
OpenSSL 0.9.6
DEC C V5.6-084
Received on Fri Mar 23 2001 - 12:59:04 NZST