perlgssapi-users Mailing List for Perl GSSAPI bindings (Page 3)
Brought to you by:
achimgrolms
Menu
▾
▴
perlgssapi-users — How to use the Bindings, help, feature requests
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
(12) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(26) |
Oct
(13) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
(4) |
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
|
From: Massimiliano M. <mas...@ce...> - 2006-09-25 12:11:45
|
Hi, On Monday 25 September 2006, alle 13:50, Achim Grolms wrote: > > So, I've to create a context on every soap message... > > or you *use* the context and use gss_wrap/gss_unwrap > for integrity protection and/or encryption of messages paylod. This looks good. Once I've created the context, I can use the gss_wrap for cypher all the text. But is a webservice. All the connections are stateless. I've to create a context on every soap message, for use the gss_wrap, no? I'm reading on the examples (par. 7.2 on rfc2222) and I understand that for use gss_wrap/gss_unwrap, I've to use the token to pass at these functions. But, I've to pass the token to the server. I cannot maintain informations on my WS. I'm confused! Help! :-) -- Massimiliano Masi http://www.comunidelchianti.it/~max |
|
From: Achim G. <ac...@gr...> - 2006-09-25 11:50:27
|
On Monday 25 September 2006 13:27, you wrote: > So, I've to create a context on every soap message... or you *use* the context and use gss_wrap/gss_unwrap for integrity protection and/or encryption of messages paylod. RFC2222 describes how they play together in SASL, for example. Achim |
|
From: Massimiliano M. <mas...@ce...> - 2006-09-25 11:28:04
|
Hi, On Monday 25 September 2006, alle 12:29, Achim Grolms wrote: > It's a bad idea, as I wrote in my Email on > Date: 06.09.2006 16:07 to you. > > Me wrote: > "But you can't reuse the token, you have to avoid > replay-attacks. (And I think yout serverside gssapi-lib > will check for replay attacks!)." Sorry,I was reading the mail without the knowledge of the replay attacks! :-( So, I've to create a context on every soap message... -- Massimiliano Masi http://www.comunidelchianti.it/~max |
|
From: Achim G. <ac...@gr...> - 2006-09-25 10:29:41
|
On Monday 25 September 2006 12:14, you wrote: > But, I'm wrong with my implementation? I'm doing > something wrong in your opinion? Is not a good idea > to use the same token for calling the remote procedures It's a bad idea, as I wrote in my Email on Date: 06.09.2006 16:07 to you. Me wrote: "But you can't reuse the token, you have to avoid replay-attacks. (And I think yout serverside gssapi-lib will check for replay attacks!)." Achim |
|
From: Massimiliano M. <mas...@ce...> - 2006-09-25 10:14:45
|
Hi, On Monday 25 September 2006, alle 11:51, Achim Grolms wrote: > You do a token replay, so you get a replay error. > (Heimdal has no replay detection at the moment, so > it still "works" on Heimdal). Of course, I've recompiled your GSSAPI code using heimdal, and everything goes fine. But, I'm wrong with my implementation? I'm doing something wrong in your opinion? Is not a good idea to use the same token for calling the remote procedures? Thanks for your patience! -- Massimiliano Masi http://www.comunidelchianti.it/~max |
|
From: Achim G. <ac...@gr...> - 2006-09-25 09:51:19
|
On Monday 25 September 2006 10:30, Massimiliano Masi wrote: > context MAJOR::Miscellaneous failure MINOR::Request is a replay You do a token replay, so you get a replay error. (Heimdal has no replay detection at the moment, so it still "works" on Heimdal). Achim |
|
From: Massimiliano M. <mas...@ce...> - 2006-09-25 08:30:25
|
Hi,
Finally, removing the flag, I'm able to use the serviceprincipal
ipmi/IT...@CE.... But I got a new error, and I think that is a
GSSAPI problem. Let me reminder a little bit my app:
I'm developing a soap service. From the client (mitkerberos) I
call two procedure (one for making mutual auth, and the other
for doing the right operation, so two soap messages).
I first call the procedure1(), i make an accept() on it,
and I got the serviceticket back. After, I encapsulate the serviceticket
in the soap message and I call the procedure2, where I make another
accept(). If the server is Heimdal on debian, everything goes
well. But if the server is Mit on RHEL, I got this error:
soap:Server, Security error: in retr_pass(): unable to accept security context MAJOR::Miscellaneous failure
MINOR::Request is a replay
(in cleanup) oid has no value at /usr/lib/perl5/site_perl/5.8.5/SOAP/Lite.pm line 2557.
returning from procedure2(). So, the first accept() in procedure1 goes ok,
I receive the serviceticket as:
mascanc@pcitadc05 ~/IPMIDEV/rpm/IPMItoolsuite-client-0.9.0/client $ klist
Ticket cache: FILE:/tmp/krb5cc_1001_I9DWU5
Default principal: ma...@CE...
Valid starting Expires Service principal
09/25/06 10:05:06 09/26/06 10:05:05 krbtgt/CE...@CE...
09/25/06 10:05:09 09/26/06 10:05:05 af...@CE...
09/25/06 10:29:11 09/26/06 10:05:05 ipmi/IT...@CE...
Kerberos 4 ticket cache: /tmp/tkt1001
klist: You have no tickets cached
but the second call to accept() in procedure2() returns error.
Have you any ideas?
Thanks!
--
Massimiliano Masi
http://www.comunidelchianti.it/~max
|
|
From: David L. <Dav...@qu...> - 2006-09-23 13:44:03
|
Achim Grolms wrote: > >> he client should ensure that the hostname part of the >> specified target GSS host-based service name matches the DNS hostname of >> the IP connection's destination host? >> This is addressed by RFC 2743: >> > > Yes. > gss_nt_krb5_principal means no hostnamelookups or anything of that kind. > > > Well, krb5 principal names have 'conventions'.. SRV-HST name type is what could be divined here. And then depending on how you read the rfcs, you could make your server derive the ip address from any given krb5 spn. But, in this case isn't he krb5 name being used as an override? The target host name is known; the IP address is being found through (trusted) DNS, only that the SPN to use in the initial token exchange is not coming from the normal way (i.e. derived from the target dns name) but instead is being provided as an override. So, no need for lookup/canonicalization of the name. d |
|
From: Achim G. <ac...@gr...> - 2006-09-23 13:23:40
|
On Saturday 23 September 2006 15:19, David Leonard wrote: > Achim Grolms wrote: > > Yes, gss_nt_krb5_principal can work, because no hostnames are hardwired > > in the principal name. > Or, do you mean the client should ensure that the hostname part of the > specified target GSS host-based service name matches the DNS hostname of > the IP connection's destination host? > This is addressed by RFC 2743: Yes. gss_nt_krb5_principal means no hostnamelookups or anything of that kind. Achim |
|
From: David L. <Dav...@qu...> - 2006-09-23 13:19:54
|
Achim Grolms wrote:
> On Saturday 23 September 2006 05:09, David Leonard wrote:
>
>> Oops, you're right; that's what happens when I fire off hasty emails! :-(
>> ok, I see that gss_nt_service_name means GSS_C_NT_HOSTBASED_SERVICE..
>>
>> So, then the krb5 principal ipmi/IT-CC would have to be specified as
>> ipmi@IT-CC ... or he could change the example scripts to use
>> gss_nt_krb5_principal instead of gss_nt_service_name. How does that sound?
>>
>
> Yes, gss_nt_krb5_principal can work, because no hostnames are hardwired
> in the principal name.
>
> Is it a good idea not to check the correct hostname/key
> when connecting to?
>
I'm not sure exactly what you mean by this question.
Do you mean the server should check the SPN used by the client? That
doesn't work for active directory when you use host spn aliases. (eg a
client request for "ftp/x.y.z" gets a 'fake' ticket that is actually for
"host/x.y.z"). The practical strategy seems to be ignore the SPN that
the ticket is labelled with, and try to decrypt it with every entry in
the keytab provided.
Or, do you mean the client should ensure that the hostname part of the
specified target GSS host-based service name matches the DNS hostname of
the IP connection's destination host?
This is addressed by RFC 2743:
When a reference to a [host-based service name "service@hostname"]
is resolved, the "hostname" may (as an example implementation
strategy) be canonicalized by attempting a DNS lookup and using the
fully-qualified domain name which is returned, or by using the
"hostname" as provided if the DNS lookup fails. The
canonicalization operation also maps the host's name into lower-case
characters.
d
|
|
From: Achim G. <ac...@gr...> - 2006-09-23 09:26:59
|
On Saturday 23 September 2006 05:09, David Leonard wrote: > Oops, you're right; that's what happens when I fire off hasty emails! :-( > ok, I see that gss_nt_service_name means GSS_C_NT_HOSTBASED_SERVICE.. > > So, then the krb5 principal ipmi/IT-CC would have to be specified as > ipmi@IT-CC ... or he could change the example scripts to use > gss_nt_krb5_principal instead of gss_nt_service_name. How does that sound? Yes, gss_nt_krb5_principal can work, because no hostnames are hardwired in the principal name. Is it a good idea not to check the correct hostname/key when connecting to? Achim |
|
From: David L. <Dav...@qu...> - 2006-09-23 03:10:33
|
Oops, you're right; that's what happens when I fire off hasty emails! :-( ok, I see that gss_nt_service_name means GSS_C_NT_HOSTBASED_SERVICE.. So, then the krb5 principal ipmi/IT-CC would have to be specified as ipmi@IT-CC ... or he could change the example scripts to use gss_nt_krb5_principal instead of gss_nt_service_name. How does that sound? d Achim Grolms wrote: > On Friday 22 September 2006 11:02, David Leonard wrote: > >> Try setting the environment variable KRB5_KTNAME=/etc/ipmi.keytab when >> you run your server >> > > 1. Massimiliano's problem starts on clientside, because the client > can not get a GSSAPI-Token from KDC because GSSAPI tries to lookup the > hostnamepart (because of gss_nt_service_name is used). > No keytab is needed on clientside! > > 2. on Serverside the > gss-server.pl script has a -keytabfile > option to set keytab directly (Massimiliano knows how to use). > > Thanky you, > Achim > > > |
|
From: Achim G. <ac...@gr...> - 2006-09-22 09:58:08
|
On Friday 22 September 2006 11:02, David Leonard wrote: > Try setting the environment variable KRB5_KTNAME=/etc/ipmi.keytab when > you run your server 1. Massimiliano's problem starts on clientside, because the client can not get a GSSAPI-Token from KDC because GSSAPI tries to lookup the hostnamepart (because of gss_nt_service_name is used). No keytab is needed on clientside! 2. on Serverside the gss-server.pl script has a -keytabfile option to set keytab directly (Massimiliano knows how to use). Thanky you, Achim |
|
From: Achim G. <ac...@gr...> - 2006-09-22 09:52:48
|
On Friday 22 September 2006 09:13, Massimiliano Masi wrote: > Hi, > > On Thursday 21 September 2006, alle 19:11, Achim Grolms wrote: > > Whats the hostname part of > > > > ipmi/IT...@CE.... > > I've asked to the people that creates this principal for me. > There are no hostname part. The name of the principal is > simply "ipmi/IT-CC" at the realm "CERN.CH" Sure. And using GSSAPI with "gss_nt_service_name" means the canonical hostname of targethost is hardwired to the Kerberos5 serviceprincipal. Achim |
|
From: David L. <Dav...@qu...> - 2006-09-22 09:02:31
|
Try setting the environment variable KRB5_KTNAME=/etc/ipmi.keytab when you run your server Massimiliano Masi wrote: > Hi, > > On Thursday 21 September 2006, alle 19:11, Achim Grolms wrote: > >> Whats the hostname part of >> >> ipmi/IT...@CE.... >> >> > > I've asked to the people that creates this principal for me. > There are no hostname part. The name of the principal is > simply "ipmi/IT-CC" at the realm "CERN.CH" > > >> Use kvno to check if you can get tickets for your new servicename. >> use kinit command to use the keytab for authentication >> (As a test that keytab works fine) >> > > > Yes, the keytab works fine, I'm able to get tokens: > > [root@lxdev23 root]# /usr/sue/bin/kdestroy > [root@lxdev23 root]# /usr/sue/bin/klist > klist: No ticket file: /tmp/krb5cc_0_22474 > > V4-ticket file: /tmp/tkt0_22472 > klist: No ticket file (tf_util) > [root@lxdev23 root]# /usr/sue/bin/kinit -k --keytab=/etc/ipmi.keytab ipmi/IT-CC > kinit: NOTICE: ticket renewable lifetime is 1 week > [root@lxdev23 root]# klist > -bash: klist: command not found > [root@lxdev23 root]# /usr/sue/bin/klist > Credentials cache: FILE:/tmp/krb5cc_0_22474 > Principal: ipmi/IT...@CE... > > Issued Expires Principal > Sep 22 09:07:02 Sep 23 09:07:02 krbtgt/CE...@CE... > Sep 22 09:07:02 Sep 23 09:07:02 af...@CE... > > V4-ticket file: /tmp/tkt0_22472 > Principal: ipm...@CE... > > Issued Expires Principal > Sep 22 09:07:02 Sep 23 10:33:23 krb...@CE... > > > > But the error is the same: > > root@pcitadc05:~/.cpan/build/GSSAPI-0.23/examples# ./gss-client.pl -hostname lxdev23.cern.ch -prodid ipmi/IT-CC -port 10000 -mutual > ./gss-client.pl: using [ipmi/IT...@lx...:10000] > CLIENT::principal [ipmi/IT-CC] means going to communicate with server name [ipmi/IT-CC] > Use of uninitialized value in subroutine entry at ./gss-client.pl line 88. > CLIENT::gss_init_sec_context success > CLIENT::going to identify client to server > CLIENT::have token to send ... > CLIENT::GSS token length is 511 > CLIENT::sent token to server > CLIENT::Mutual auth requested ... > CLIENT::server did not send needed continue token back > root@pcitadc05:~/.cpan/build/GSSAPI-0.23/examples# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: ma...@CE... > > Valid starting Expires Service principal > 09/22/06 09:10:50 09/23/06 09:10:50 krbtgt/CE...@CE... > 09/22/06 09:10:53 09/23/06 09:10:50 ipmi/IT...@CE... > > > > Look, I'm able to receive the serviceticket for ipmi/IT-CC, but > > > Where the server replies: > > SERVER::waiting for request ... > SERVER::accepted connection from client ... > SERVER::received token (length is 511): > Unable to accept security context: > MAJOR::Miscellaneous failure > MINOR::No principal in keytab matches desired name > Argument "\0\0\0\0" isn't numeric in null operation at ./gss-server.pl line 81, <GEN2> line 1. > (in cleanup) oid has no value at ./gss-server.pl line 81, <GEN2> line 1. > SERVER::exiting after error > > > > > |
|
From: Massimiliano M. <mas...@ce...> - 2006-09-22 07:13:30
|
Hi,
On Thursday 21 September 2006, alle 19:11, Achim Grolms wrote:
> Whats the hostname part of
>
> ipmi/IT...@CE....
>
I've asked to the people that creates this principal for me.
There are no hostname part. The name of the principal is
simply "ipmi/IT-CC" at the realm "CERN.CH"
> Use kvno to check if you can get tickets for your new servicename.
> use kinit command to use the keytab for authentication
> (As a test that keytab works fine)
Yes, the keytab works fine, I'm able to get tokens:
[root@lxdev23 root]# /usr/sue/bin/kdestroy
[root@lxdev23 root]# /usr/sue/bin/klist
klist: No ticket file: /tmp/krb5cc_0_22474
V4-ticket file: /tmp/tkt0_22472
klist: No ticket file (tf_util)
[root@lxdev23 root]# /usr/sue/bin/kinit -k --keytab=/etc/ipmi.keytab ipmi/IT-CC
kinit: NOTICE: ticket renewable lifetime is 1 week
[root@lxdev23 root]# klist
-bash: klist: command not found
[root@lxdev23 root]# /usr/sue/bin/klist
Credentials cache: FILE:/tmp/krb5cc_0_22474
Principal: ipmi/IT...@CE...
Issued Expires Principal
Sep 22 09:07:02 Sep 23 09:07:02 krbtgt/CE...@CE...
Sep 22 09:07:02 Sep 23 09:07:02 af...@CE...
V4-ticket file: /tmp/tkt0_22472
Principal: ipm...@CE...
Issued Expires Principal
Sep 22 09:07:02 Sep 23 10:33:23 krb...@CE...
But the error is the same:
root@pcitadc05:~/.cpan/build/GSSAPI-0.23/examples# ./gss-client.pl -hostname lxdev23.cern.ch -prodid ipmi/IT-CC -port 10000 -mutual
./gss-client.pl: using [ipmi/IT...@lx...:10000]
CLIENT::principal [ipmi/IT-CC] means going to communicate with server name [ipmi/IT-CC]
Use of uninitialized value in subroutine entry at ./gss-client.pl line 88.
CLIENT::gss_init_sec_context success
CLIENT::going to identify client to server
CLIENT::have token to send ...
CLIENT::GSS token length is 511
CLIENT::sent token to server
CLIENT::Mutual auth requested ...
CLIENT::server did not send needed continue token back
root@pcitadc05:~/.cpan/build/GSSAPI-0.23/examples# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ma...@CE...
Valid starting Expires Service principal
09/22/06 09:10:50 09/23/06 09:10:50 krbtgt/CE...@CE...
09/22/06 09:10:53 09/23/06 09:10:50 ipmi/IT...@CE...
Look, I'm able to receive the serviceticket for ipmi/IT-CC, but
Where the server replies:
SERVER::waiting for request ...
SERVER::accepted connection from client ...
SERVER::received token (length is 511):
Unable to accept security context:
MAJOR::Miscellaneous failure
MINOR::No principal in keytab matches desired name
Argument "\0\0\0\0" isn't numeric in null operation at ./gss-server.pl line 81, <GEN2> line 1.
(in cleanup) oid has no value at ./gss-server.pl line 81, <GEN2> line 1.
SERVER::exiting after error
--
Massimiliano Masi
http://www.comunidelchianti.it/~max
|
|
From: Achim G. <ac...@gr...> - 2006-09-21 17:12:12
|
On Thursday 21 September 2006 17:34, Massimiliano Masi wrote: > What is the problem? What is the gss_nt_service_name for? "MINOR::Server not found in Kerberos database" the hostname-part in principal must match the canonical hostname. (For example in case of CNAME-Record the Record the CNAME points to. Or in case of A record the name resultinge in a reverse an a forward lookup. Whats the hostname part of ipmi/IT...@CE.... ? I think you want to create principal ipmi/lxd...@CE... in Kerberos5, in GSSAPI syntax that's ip...@lx... But as far I can see from DNS lxdev23.cern.ch is OK. Ensure DNS an /etc/hosts and that stuff are configured properly on your machine! Use kvno to check if you can get tickets for your new servicename. use kinit command to use the keytab for authentication (As a test that keytab works fine) Most of the hints I have added to <http://www.grolmsnet.de/kerbtut/> may be helpfull for debugging. Achim |
|
From: Massimiliano M. <mas...@ce...> - 2006-09-21 15:34:39
|
Hi, I've another problem. I've a new serviceprincipal, called ipmi/IT...@CE.... When I run the examples, I see from the client part: root@pcitadc05:~/.cpan/build/GSSAPI-0.23/examples# ./gss-client.pl -hostname lxdev23.cern.ch -prodid ipmi -port 10000 ./gss-client.pl: using [ip...@lx...:10000] CLIENT::principal [ipmi] means going to communicate with server name [ipmi] Use of uninitialized value in subroutine entry at ./gss-client.pl line 88. CLIENT::Unable to initialize security context: MAJOR::Unspecified GSS failure. Minor code may provide more information MINOR::Server not found in Kerberos database root@pcitadc05:~/.cpan/build/GSSAPI-0.23/examples# ./gss-client.pl -hostname lxdev23.cern.ch -prodid ipmi/IT-CC -port 10000 ./gss-client.pl: using [ipmi/IT...@lx...:10000] CLIENT::principal [ipmi/IT-CC] means going to communicate with server name [ipmi/IT-CC] Use of uninitialized value in subroutine entry at ./gss-client.pl line 88. CLIENT::Unable to initialize security context: MAJOR::Unspecified GSS failure. Minor code may provide more information MINOR::Server not found in Kerberos database If I change the my $status = GSSAPI::Name->import(my $gss_server_name, $server_name, gss_nt_service_name); with my $status = GSSAPI::Name->import(my $gss_server_name, $server_name); I got MINOR::No principal in keytab matches desired name What is the problem? What is the gss_nt_service_name for? Thank you! -- Massimiliano Masi http://www.comunidelchianti.it/~max |
|
From: Achim G. <ac...@gr...> - 2006-09-21 09:14:58
|
> Should the client/server pair work properly? Is there anyone > that might have an idea why its also coring? 1. SSPI is the Win32 API to Windows Authentication system. SSPI is able to deal with the GSSAPI protocol, Kerberos5 over GSSAPI (the protocol) for example. GSSAPI.pm is not an interface to SSPI. GSSAPI.pm is an interface to GSSAPI (the C-interface, RFC 2744). Maybe in future I am going to write a Perl-Wrapper to Win32-API SSPI to make Perlskripts on Windows use the SSPI directly. As a workaround you can build GSSAPI.pm against MIT Kerberos for Windows. 2. Can you use the versions from Subversion repository http://sourceforge.net/projects/perlgssapi/ (I've added workarounds to the client/server scripts). 3. GSSAPI.pm has a bug (I have added it). to avoid you can use a quick workaround and change all lines of type my $out_mech, to undef in your code. example: my $status = GSSAPI::Context::accept( $server_context, GSS_C_NO_CREDENTIAL, $gss_input_token, GSS_C_NO_CHANNEL_BINDINGS, my $gss_client_name, undef, my $gss_output_token, my $out_flags, my $out_time, my $gss_delegated_cred); Let me know what happens then an let me know the output. Achim |
|
From: Tuc at T-B-O-H.N. <ml...@t-...> - 2006-09-21 02:39:55
|
Hi,
I don't know if I'm WAY WAY WAY off, but lets see. :)
I'm trying to write a perl program to replace a
Windows based program using SSPI. I was under the impression
that GSSAPI could be used to handle SSPI transactions somehow.
I first decided to take the gss-server.pl in the example
directory and use it as a starter. I started it on port 2068
and started my application. It seemed to die so I made a few
mods to the server mostly not to print anything if whats read
from the socket is empty, and then when it does contain
something, not to decode it. It looks like :
print "SERVER::accepted connection from client ...\n";
my $gss_input_token =3D <$client_socket>;
if (length($gss_input_token) ) {
print "SERVER::received token - Before $gss_input_token\n";
# $gss_input_token =3D decode_base64($gss_input_token);
# print "SERVER::received token - After $gss_input_token\n";
print "SERVER::received token (length is " . length($gss_input_to=
ken) .
"):\n";
my $status =3D GSSAPI::Context::accept(
$server_context,
GSS_C_NO_CREDENTIAL,
$gss_input_token,
GSS_C_NO_CHANNEL_BINDINGS,
my $gss_client_name,
my $out_mech,
my $gss_output_token,
my $out_flags,
my $out_time,
my $gss_delegated_cred);
When I run it it outputs :
./gss-server.pl: -name not specified, using hostname result [SOME.t-b-o-h=
.net]
./gss-server.pl: using [SOME.t-b-o-h.net:2068]
SERVER set environment variable KRB5_KTNAME to FILE:/etc/krb5.keytab
Listening on port 2068 ...
SERVER::waiting for request ...
SERVER::accepted connection from client ...
Use of uninitialized value in length at ./gss-server.pl line 79.
SERVER::waiting for request ...
SERVER::accepted connection from client ...
SERVER::received token - Before NT8NTLMSSP=A21 ((
SERVER::received token (length is 47):
Unable to accept security context:
MAJOR:: A token was invalid
MINOR::Unknown error: 0
Segmentation fault (core dumped)
I went back to the original server and started it
the same way, then used the client from the examples directory.
I invoked :
./gss-client.pl -hostname=3DSOME.t-b-o-h.net -prodid=3Dtest -port=3D2068
CLIENT:
./gss-client.pl: using [te...@SO...:2068]
CLIENT::principal [te...@SO...] means going to communicate with=
server name [test/SOM...@T-...]
Use of uninitialized value in subroutine entry at ./gss-client.pl line 88.
CLIENT::Unable to initialize security context:
MAJOR:: Miscellaneous failure (see text)
MINOR::open(/tmp/krb5cc_0): No such file or directory
SERVER:
asgard# ./gss-serveroriginal.pl --keytabfile=3D/etc/krb5.keytab --port=3D=
2068
./gss-serveroriginal.pl: -name not specified, using hostname result [SOME=
.t-b-o-h.net]
./gss-serveroriginal.pl: using [SOME.t-b-o-h.net:2068]
SERVER set environment variable KRB5_KTNAME to FILE:/etc/krb5.keytab
Listening on port 2068 ...
SERVER::waiting for request ...
SERVER::accepted connection from client ...
Use of uninitialized value in subroutine entry at ./gss-serveroriginal.pl=
line 78.
SERVER::received token (length is 0):
SERVER::waiting for request ...
Should the client/server pair work properly? Is there anyone
that might have an idea why its also coring?
Thanks, Tuc
|
|
From: Massimiliano M. <mas...@ce...> - 2006-09-04 06:51:37
|
Hi, On Friday 01 September 2006, alle 18:16, Achim Grolms wrote: > send me the output of > > krb5-config --version > perl -v > uname -a Yes, this is the output: CLIENT SIDE: root@pcitadc05:~# krb5-config --version Kerberos 5 release 1.5 root@pcitadc05:~# perl -v This is perl, v5.8.7 built for i486-linux-gnu-thread-multi (with 1 registered patch, see perl -V for more detail) Copyright 1987-2005, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. root@pcitadc05:~# uname -a Linux pcitadc05 2.6.15-26-server #1 SMP Thu Aug 3 04:09:15 UTC 2006 i686 GNU/Linux root@pcitadc05:~# SERVER SIDE: higgs:~# krb5-config --version heimdal 0.7.2 $Id: krb5-config.in,v 1.10.2.1 2006/02/03 15:01:28 lha Exp $ higgs:~# perl -v This is perl, v5.8.4 built for i386-linux-thread-multi Copyright 1987-2004, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. higgs:~# uname -a Linux higgs 2.6.8-2-386 #1 Tue Aug 16 12:46:35 UTC 2005 i686 GNU/Linux > Do you use a self-installed version of Kerberos? On the client side, I'm using the kerberos distribution of UBUNTU, and on the server, I've compiled heimdal, for mantaining a version compatibility with the heimdal installed at CERN. > > If so, and if you live in germany, we are close! :) > > I live in Germany. > <http://paderborn.pm.org/> > Why are we close? Because I'm in Switzerland, a Geneve! :-) Best, -- Massimiliano Masi http://www.comunidelchianti.it/~max |
|
From: Achim G. <ac...@gr...> - 2006-09-01 16:16:24
|
On Friday 01 September 2006 09:40, Massimiliano Masi wrote: > Yes. With your updated version, the server remains alive, without > any problems. The problems still persist on the client side. send me the output of krb5-config --version perl -v uname -a Do you use a self-installed version of Kerberos? (Why don't you use the Kerberos of your OS-distribution?) > By the way, are you german? :) yes. > If so, and if you live in germany, we are close! :) I live in Germany. <http://paderborn.pm.org/> Why are we close? Achim |
|
From: Massimiliano M. <mas...@ce...> - 2006-09-01 07:40:50
|
Hello,
On Thursday 31 August 2006, alle 19:49, Achim Grolms wrote:
> I can see two problems.
>
> 1. The Segmentation fault from your client script.
> I can not reproduce it on my side.
If you need, I can give you access to the server and client machine.
This is not a problem. We can investigate together.
> 2. the "Argument "^XQ,@" isn't numeric in null operation at ./gss-server.pl
> line 81, <GEN15> line 1."
> messages on serverside.
Yes. With your updated version, the server remains alive, without
any problems. The problems still persist on the client side.
I still got the SIGSEGV. I see stracing a little bit, a problem here:
stat64("/usr/local/etc/krb5.conf", 0xbff5a32c) = -1 ENOENT (No such file or directory)
open("/dev/urandom", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0
read(4, "\235\fn\35\252%+62L\"$\231P-3\246\251?>", 20) = 20
close(4) = 0
gettimeofday({1157096241, 408163}, NULL) = 0
time(NULL) = 1157096241
time(NULL) = 1157096241
time(NULL) = 1157096241
time(NULL) = 1157096241
time(NULL) = 1157096241
time(NULL) = 1157096241
time(NULL) = 1157096241
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Just at the exit of the $status = GSSAPI::Context::init().
> I don't know what's the meaining of the word 'prodid', but the parameter is
> used as the servicename-part of the GSSAPI name, as described in
> <http://www.iana.org/assignments/gssapi-service-names>
> I think "servicename" is the better label than "prodid".
> Do you agree?
Yes !!! :)
>
> Thank you,
> Achim
By the way, are you german? :)
If so, and if you live in germany, we are close! :)
--
Massimiliano Masi
http://www.comunidelchianti.it/~max
|
|
From: Achim G. <ac...@gr...> - 2006-08-31 17:50:04
|
On Thursday 31 August 2006 09:17, Massimiliano Masi wrote: I can see two problems. 1. The Segmentation fault from your client script. I can not reproduce it on my side. 2. the "Argument "^XQ,@" isn't numeric in null operation at ./gss-server.pl line 81, <GEN15> line 1." messages on serverside. I've made adjustments on gss-client.pl and gss-server.pl. I've commit them to the Subveriosn-repository https://svn.sourceforge.net/svnroot/perlgssapi/GSSAPI/trunk Please check what results you get by using the modified version. I don't know what's the meaining of the word 'prodid', but the parameter is used as the servicename-part of the GSSAPI name, as described in <http://www.iana.org/assignments/gssapi-service-names> I think "servicename" is the better label than "prodid". Do you agree? Thank you, Achim |
|
From: Massimiliano M. <mas...@ce...> - 2006-08-31 07:17:29
|
On Wednesday 30 August 2006, alle 18:06, Achim Grolms wrote:
> I think -prodid ipmi/higgs.massicern.ch is wrong, use -prodid ipmi instead.
Thanks a lot for your answer. But still doesn't works... Using ipmi as prodid
(BTW, what's the meaining of prodid?) I got something new:
mascanc@pcitadc05 ~/Desktop/GSSAPI-0.23/examples $ ./gss-client.pl -hostname higgs.massicern.ch -prodid ipmi -port 10000
./gss-client.pl: using [ip...@hi...:10000]
CLIENT::principal [ip...@hi...] means going to communicate with server name [ip...@hi...]
Use of uninitialized value in subroutine entry at ./gss-client.pl line 88.
CLIENT::gss_init_sec_context success
CLIENT::going to identify client to server
CLIENT::have token to send ...
CLIENT::GSS token length is 538
CLIENT::sent token to server
Segmentation fault
And in the server side:
SERVER::waiting for request ...
SERVER::accepted connection from client ...
SERVER::received token (length is 538):
SERVER::authenticated client name is ma...@MA...
Argument "^XQ,@" isn't numeric in null operation at ./gss-server.pl line 81, <GEN15> line 1.
(in cleanup) oid has no value at ./gss-server.pl line 81, <GEN15> line 1.
SERVER::waiting for request ...
Have you any idea???
Many, many thanks!
--
Massimiliano Masi
http://www.comunidelchianti.it/~max
|
1 message has been excluded from this view by a project administrator.
