2017-02-10 31 views
2

我正在嘗試將我的本地Windows 10計算機驗證爲在泊塢窗容器內運行的Web服務。更具體地說,這個容器運行Hadoop服務和MIT Kerberos KDC。我在本地機器上安裝了用於Windows的MIT Kerberos,併成功從KDC獲得了一張票hadoop/[email protected]。當我使用容器中的相同主體進行身份驗證並調用此命令時:curl -i --negotiate -u : "http://quickstart.cloudera:50070/webhdfs/v1/?op=GETFILESTATUS"我收到有效的回覆。然而,從我的Windows機器一樣運行的命令返回此錯誤:從Windows到Linux的HTTP協商失敗

Error 403 GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag) 

任何人都熟悉SSPI/GSSAPI能給我這裏的問題可能是什麼的一些見解?我的環境變量KRB5CCNAME=<path to ccache>設置正確。這是從我的Windows命令提示符下捲曲信息:

curl 7.52.1 (x86_64-w64-mingw32) libcurl/7.52.1 WinSSL zlib/1.2.8 WinIDN libssh2/1.7.0_DEV 
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp 
Features: IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz 

讓我知道,如果你需要我的環境設置的任何詳細信息。

更新:

這裏是我的Windows機器的完整的HTTP響應,當我運行添加了冗長的-v標誌的命令。

* timeout on name lookup is not supported 
* Trying 127.0.0.1... 
* TCP_NODELAY set 
* Connected to quickstart.cloudera (127.0.0.1) port 50070 (#0) 
> GET /webhdfs/v1/?op=GETFILESTATUS HTTP/1.1 
> Host: quickstart.cloudera:50070 
> User-Agent: curl/7.52.1 
> Accept: */* 
> 
< HTTP/1.1 401 Authentication required 
HTTP/1.1 401 Authentication required 
< Cache-Control: must-revalidate,no-cache,no-store 
Cache-Control: must-revalidate,no-cache,no-store 
< Date: Fri, 10 Feb 2017 19:41:27 GMT 
Date: Fri, 10 Feb 2017 19:41:27 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Date: Fri, 10 Feb 2017 19:41:27 GMT 
Date: Fri, 10 Feb 2017 19:41:27 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Content-Type: text/html; charset=iso-8859-1 
Content-Type: text/html; charset=iso-8859-1 
< WWW-Authenticate: Negotiate 
WWW-Authenticate: Negotiate 
< Set-Cookie: hadoop.auth=; Path=/; HttpOnly 
Set-Cookie: hadoop.auth=; Path=/; HttpOnly 
< Content-Length: 1404 
Content-Length: 1404 
< Server: Jetty(6.1.26.cloudera.4) 
Server: Jetty(6.1.26.cloudera.4) 

< 
* Ignoring the response-body 
* Curl_http_done: called premature == 0 
* Connection #0 to host quickstart.cloudera left intact 
* Issue another request to this URL: 'http://quickstart.cloudera:50070/webhdfs/v1/?op=GETFILESTATUS' 
* Found bundle for host quickstart.cloudera: 0x817220 [can pipeline] 
* Re-using existing connection! (#0) with host quickstart.cloudera 
* Connected to quickstart.cloudera (127.0.0.1) port 50070 (#0) 
* Server auth using Negotiate with user '' 
> GET /webhdfs/v1/?op=GETFILESTATUS HTTP/1.1 
> Host: quickstart.cloudera:50070 
> Authorization: Negotiate TlRMTVNTUAABAAAAt4II4gAAAAAAAAAAAAAAAAAAAAAKAFopAAAADw== 
> User-Agent: curl/7.52.1 
> Accept: */* 
> 
< HTTP/1.1 403 GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag) 
HTTP/1.1 403 GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag) 
< Cache-Control: must-revalidate,no-cache,no-store 
Cache-Control: must-revalidate,no-cache,no-store 
< Date: Fri, 10 Feb 2017 19:41:27 GMT 
Date: Fri, 10 Feb 2017 19:41:27 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Date: Fri, 10 Feb 2017 19:41:27 GMT 
Date: Fri, 10 Feb 2017 19:41:27 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Content-Type: text/html; charset=iso-8859-1 
Content-Type: text/html; charset=iso-8859-1 
< Set-Cookie: hadoop.auth=; Path=/; HttpOnly 
Set-Cookie: hadoop.auth=; Path=/; HttpOnly 
< Content-Length: 1546 
Content-Length: 1546 
< Server: Jetty(6.1.26.cloudera.4) 
Server: Jetty(6.1.26.cloudera.4) 

< 
<html> 
<head> 
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/> 
<title>Error 403 GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)</title> 
</head> 
<body><h2>HTTP ERROR 403</h2> 
<p>Problem accessing /webhdfs/v1/. Reason: 
<pre> GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)</pre></p><hr /><i><small>Powered by Jetty://</small></i><br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 

</body> 
</html> 
* Curl_http_done: called premature == 0 
* Closing connection 0 

相反,這是運行我的容器內的同一命令的響應:

* About to connect() to quickstart.cloudera port 50070 (#0) 
* Trying 172.18.0.2... connected 
* Connected to quickstart.cloudera (172.18.0.2) port 50070 (#0) 
> GET /webhdfs/v1/?op=GETFILESTATUS HTTP/1.1 
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 
> Host: quickstart.cloudera:50070 
> Accept: */* 
> 
< HTTP/1.1 401 Authentication required 
HTTP/1.1 401 Authentication required 
< Cache-Control: must-revalidate,no-cache,no-store 
Cache-Control: must-revalidate,no-cache,no-store 
< Date: Fri, 10 Feb 2017 21:15:39 GMT 
Date: Fri, 10 Feb 2017 21:15:39 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Date: Fri, 10 Feb 2017 21:15:39 GMT 
Date: Fri, 10 Feb 2017 21:15:39 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Content-Type: text/html; charset=iso-8859-1 
Content-Type: text/html; charset=iso-8859-1 
< WWW-Authenticate: Negotiate 
WWW-Authenticate: Negotiate 
< Set-Cookie: hadoop.auth=; Path=/; HttpOnly 
Set-Cookie: hadoop.auth=; Path=/; HttpOnly 
< Content-Length: 1404 
Content-Length: 1404 
< Server: Jetty(6.1.26.cloudera.4) 
Server: Jetty(6.1.26.cloudera.4) 

< 
* Ignoring the response-body 
* Connection #0 to host quickstart.cloudera left intact 
* Issue another request to this URL: 'http://quickstart.cloudera:50070/webhdfs/v1/?op=GETFILESTATUS' 
* Re-using existing connection! (#0) with host quickstart.cloudera 
* Connected to quickstart.cloudera (172.18.0.2) port 50070 (#0) 
* Server auth using GSS-Negotiate with user '' 
> GET /webhdfs/v1/?op=GETFILESTATUS HTTP/1.1 
> Authorization: Negotiate YIICkQYJKoZIhvcSAQICAQBuggKAMIICfKADAgEFoQMCAQ6iBwMFAAAAAACjggGBYYIBfTCCAXmgAwIBBaEKGwhDTE9VREVSQaImMCSgAwIBA6EdMBsbBEhUVFAbE3F1aWNrc3RhcnQuY2xvdWRlcmGjggE8MIIBOKADAgESoQMCAQKiggEqBIIBJnWbXp9WlAVk0nGIqD7T25On1+OCPzXDX/aoH01FTjJbEwrYj4cMML7Tf6jaKDIANEh57kTJOvPknL3CWHI1c3LeNpt1Ir8H2M3Zvk91HpbWXzv5WJTeUOK9L6zTaKFEs/dKQgD7VzmHKDJtMyVKQWLLVU8JuyKAV6iM4FvxfZ+WDF8QCk7pxwjgX1OT7jv9jR28MPpsIweqUYYnneJxVTsxgmsHdOvj5wpMGy9RA9R8jtR+Wh3l5r3a3zcUTmGwAqY+NXhBkviSTw+DgitnipYh5tXBRhNqGfk86qWAdodGgL+SdkwwGsq91PyYQiMCLXjWx90aBOEFeZLDyqBaXlMIZ3TT3urUQEuB206+8KNw1n6N6+u+ZY4QT7NJyVZqHbnOR5V5maSB4TCB3qADAgESooHWBIHTyaBY3PormkycaX9uf/lLe6ISYnItZikJqslAGpJVnla2HXYvhFjqn5yr8td1pw3zzdnDEZx3a9EylIrRQD5IoIvHCzd0mlJhHFj4xxISM5hxlMiL8DewMjGsVcDveqpHw1SyxIsrEPOhe62HuRXS7c1Z9kYkP6KldzyAJOttOVYCuL36hOxwEFqJtbWk1/f9gfTdzmxQmEASM3/wsj2Q/WYCZY/hazDIz6dmHsyla/F6NXGK0BwRnHHBCqSHe7GdWmBDNjHiuo6R0/YvqTl5Uvf0Rw== 
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 
> Host: quickstart.cloudera:50070 
> Accept: */* 
> 
< HTTP/1.1 200 OK 
HTTP/1.1 200 OK 
< Cache-Control: no-cache 
Cache-Control: no-cache 
< Expires: Fri, 10 Feb 2017 21:15:39 GMT 
Expires: Fri, 10 Feb 2017 21:15:39 GMT 
< Date: Fri, 10 Feb 2017 21:15:39 GMT 
Date: Fri, 10 Feb 2017 21:15:39 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Expires: Fri, 10 Feb 2017 21:15:39 GMT 
Expires: Fri, 10 Feb 2017 21:15:39 GMT 
< Date: Fri, 10 Feb 2017 21:15:39 GMT 
Date: Fri, 10 Feb 2017 21:15:39 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Content-Type: application/json 
Content-Type: application/json 
< Set-Cookie: hadoop.auth="u=hadoop&p=hadoop/[email protected]&t=kerberos&e=1486797339425&s=BqBHGJ+/FxxeSR0ayBXHOrfPkwU="; Path=/; HttpOnly 
Set-Cookie: hadoop.auth="u=hadoop&p=hadoop/[email protected]&t=kerberos&e=1486797339425&s=BqBHGJ+/FxxeSR0ayBXHOrfPkwU="; Path=/; HttpOnly 
< Transfer-Encoding: chunked 
Transfer-Encoding: chunked 
< Server: Jetty(6.1.26.cloudera.4) 
Server: Jetty(6.1.26.cloudera.4) 

< 
* Connection #0 to host quickstart.cloudera left intact 
* Closing connection #0 
{"FileStatus":{"accessTime":0,"blockSize":0,"childrenNum":5,"fileId":16385,"group":"supergroup","length":0,"modificationTime":1459909590753,"owner":"hdfs","pathSuffix":"","permission":"755","replication":0,"storagePolicy":0,"type":"DIRECTORY"}} 
+0

'curl -v'給出了更多細節? – rogerdpack

+0

當我運行命令時,你是否指''-v'作爲詳細設置?我會將結果添加到原始問題中。 – ejang

回答

1

答案是在這種情況下很容易。 Windows上的捲曲是用SSPI編譯的。當SSPI被請求執行SPNEGO時,它會嘗試在此處失敗的Kerberos。可能「在數據庫中找不到服務器」(使用Wireshark),然後回退到NTLM。它發出了一個原始的NTLM令牌您JGSS支持的服務器,拒絕令牌,因爲

  1. 這不是SPNEGO包裹道理,但原始NTLM令牌
  2. Java不支持NTLM

Here是示例代碼,如何攔截此信息並用有意義的消息進行響應。引發Hadoop的問題。

此外,Linux上的Curl版本7.19.7是非常古老且不安全的,您應該立即升級,並且Jetty上的SPNEGO Authenticator已損壞,因爲它沒有使用上下文完成令牌進行響應。總之,整個認證不應該被信任,因爲它是錯誤的。見RFC 7546