salyh salyh - 2 months ago 52
HTTP Question

curl stops negotiating SPNEGO - unknown mech-code 0 for mech unknown

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?

Answer

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: me@DOMAIN.COM

  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: me@DOMAIN.COM

  Issued                Expires               Principal
Sep  6 09:16:50 2016  Sep  6 19:16:50 2016  krbtgt/DOMAIN.COM@DOMAIN.COM
Comments