4
votes

I try to connect to an SPNEGO secured web site with curl (on Mac OS X 10.10 with shipped curl)

$curl -vv --negotiate -u : http://xxx-MacBook-Pro.local:8080 
* Rebuilt URL to: http://xxx-MacBook-Pro.local:8080/
*   Trying 192.168.1.6...
* Connected to xxx-MacBook-Pro.local (192.168.1.6) port 8080 (#0)
> GET / HTTP/1.1
> Host: xxx-MacBook-Pro.local:8080
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 401 Unauthorized
* gss_init_sec_context() failed: : unknown mech-code 0 for mech unknown
< WWW-Authenticate: Negotiate
< Content-Type: application/json; charset=UTF-8
< Content-Length: 303
< 
* Connection #0 to host xxx-MacBook-Pro.local left intact

Problem seems to be "gss_init_sec_context() failed: : unknown mech-code 0 for mech unknown". curl looks like to be compiled with SPNEGO/GSS correctly?

curl 7.43.0 (x86_64-apple-darwin14.0) libcurl/7.43.0 SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps     pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets 

EDIT: HTTPie (https://github.com/ndzou/httpie-negotiate) shows similar behaviour. It stops after the first server response. Does it matter that the server return content with the 401 response and not just headers?

GET / HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: 192.168.1.6:8080
User-Agent: HTTPie/0.9.2



HTTP/1.1 401 Unauthorized
Content-Length: 209
Content-Type: application/json; charset=UTF-8
WWW-Authenticate: Negotiate

{
    "error": {
        "header": {
            "WWW-Authenticate": "Negotiate"
        }, 
        "reason": null, 
        "root_cause": [
            {
                "header": {
                    "WWW-Authenticate": "Negotiate"
                }, 
                "reason": null, 
                "type": "xxx"
            }
        ], 
        "type": "xxx"
    }, 
    "status": 401
}

How can i make curl to get work and to use the correct mech?

1
What GSS-API implementation are you using? Show ldd curl.Michael-O
(there is no ldd on mac) -> "otool -L /usr/bin/curl" master /usr/bin/curl: /usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 8.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)salyh
There is a problem now. From the output I cannot see what GSS-API implementation is used. Please run krb5-config --version and show the result.Michael-O
$ krb5-config --help --version --> master Kerberos 5 release 1.7-prerelease (but man page and says otool -L /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos "Heimdal")salyh
1.7? Seriosly? This is more than 6.5 years old. This is ancient. Why does the output say Heimdal though it is MIT Kerberos? I would highly recommend to compile MIT Kerberos from source and link curl to that. If that works, you can investigate further.Michael-O

1 Answers

2
votes

I'm able to reproduce this behaviour when I don't have valid kerberos ticket.

> klist
Credentials cache: API:F8526791-7C98-45B7-87A0-8426165D376A
        Principal: [email protected]

  Issued    Expires    Principal

As soon as I obtain valid ticket via kinit command the authentication goes on as expected:

> kinit
> klist
Credentials cache: API:F90F79C6-6343-4462-BCD3-54F146FBDBCD
        Principal: [email protected]

  Issued                Expires               Principal
Sep  6 09:16:50 2016  Sep  6 19:16:50 2016  krbtgt/[email protected]