All-

We're using ssh 1.2.31 + the two recent security patches on most of our
UNIX boxes.  We also have krb5 1.2.1 in place, and ssh has been compiled
with krb5 support, including

        --enable-kerberos-tgt-passing

Most of our users are in one realm, let's call it A.FOO.BAR.  We also
have most of the UNIX machines we manage with host principals in that
same realm.

We now have a few users in realm B.FOO.BAR that want to ssh into some of
our UNIX servers.  We have "shared secrets" between the realms, so cross-realm
authentication is working for pure krb5 clients.  For example, if I, on
my desktop workstation, do a

        kinit -f [EMAIL PROTECTED]

and get a krbtgt for that user, I can then proceed to

        rlogin -x -l user1 host.in.realm.a.foo.bar

or even

        ssh host.in.realm.a.foo.bar -l user1

and it works.

However, if I don't get the krbtgt for user1 first, ssh doesn't work.  The
problem is that with the Windows based ssh client(s) these people have been
trying, there's no way for them to get a krbtgt first.

This particular stipulation is *not* needed if the user's krbtgt is in
the same realm as the machine, i.e.  I can

        kdestroy
        ssh host.in.realm.a.foo.bar -l user2
                <enter krb5 password for [EMAIL PROTECTED]>

and I'm in.

Is this a configuration problem, a usage problem, or something that
fundamentally isn't supported in ssh 1.2.x?   If the latter, is is
supported in some other version of ssh?

Thanks!

Tim
-- 
Tim Mooney                              [EMAIL PROTECTED]
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J1, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

Reply via email to