[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem: default realm in openssh

Well, I have no idea what these tests are doing :-) I tried to use it as


kinit ....
gssapi_client --service=hprop hostname     (hprop as any other service here is good ?)


both server and client on host A:

User is `komanek@NATUR.CUNI.CZ'
gss_verify_mic: hej
gss_unwrap: hemligt

both server and client on B:

User is `komanek@NATUR.CUNI.CZ'
prfdec# gss_verify_mic: hej
gss_unwrap: hemligt

server on A, client on B:

A: gssapi_server: gss_accept_sec_context
A: Error 0
B: gssapi_client: EOF in read

server on B, client on A:

A: gssapi_client: EOF in read
B: gssapi_server: gss_accept_sec_context
B: Successful

Can you or anybody else on this list explain these results ? Do you have
some suggestion where to go more deeply ?

But, I think I have found something very interesting - as I already have
written before, connection from B to A with tiket works only if I use
fully qualified target hostname, not with the short form. Today I tried
the same, but with IP address instead. Debug output from openssh seems to
be more descriptive about what is wrong:

debug1: Next authentication method: gssapi
debug2: we sent a gssapi packet, wait for reply
debug1:  Miscellaneous failure (see text)
Server (krbtgt/113.56.251@NATUR.CUNI.CZ) unknown

debug1: Trying to start again
debug2: we did not send a packet, disable method

The IP address of the target is, not 113.56.251. I suppose
the lines "Miscelaneous failure ...." and "Server ...." are not from
openssh itself but from heimdal, right ? So all the wear and tear is
result of some bad parsing routine dealing with hostname ?

Thanks again,


> David Komanek <xdavid@lib-eth.natur.cuni.cz> writes:
> > Please, do you have some small test program to see if heimdal gssapi
> > itself works well ?
> There are test programs in appl/test.
> /Johan