salyh salyh - 1 year ago 369
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
* Connected to xxx-MacBook-Pro.local ( 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 ( 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
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 Source

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
Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download