用--negotiate卷曲/Kerberos似乎不起作用 [英] curl with --negotiate / Kerberos doesn't seem to work

查看：474
本文介绍了用--negotiate卷曲/Kerberos似乎不起作用的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我正在尝试将curl与Kerberos配合使用(针对TM1).在中使用答案时，将--negotiate与curl一起使用时，需要一个密钥表文件吗?似乎很有帮助，但是，它仍然对我不起作用.

I'm trying to use curl with Kerberos (against TM1). The answers in When using --negotiate with curl, is a keytab file required? seem very helpful, however, it still doesn't work for me.

我遵循了Avinash Reddy的说明

I followed the instructions from Avinash Reddy

$curl --version
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.44 zlib/1.2.7 libidn/1.28 libssh2/1.8.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz unix-sockets

$/usr/share/centrifydc/kerberos/bin/kinit myuser
Password for myuser@MYREALM:

$/usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_100123
Default principal: myuser@MYREALM

Valid starting       Expires              Service principal
01/24/2020 12:11:30  01/24/2020 22:11:30  krbtgt/MYREALM@MYREALM
        renew until 01/25/2020 12:11:26

WattsInABox表示他成功使用了curl 7.29 .0 ，但对我来说似乎不起作用:

WattsInABox says he successfully used curl 7.29.0 but for me, it doesn't seem to work:

$curl -ik -vvv --negotiate -u : -b ~/cookiejar.txt -c ~/cookiejar.txt https://mytm1server/api/v1/Configuration
* About to connect() to mytm1server port 80 (#0)
*   Trying 10.48.199.126...
* Connected to mytm1server (10.10.100.100) port 80 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA
* Server certificate:
*       subject: CN=TM1Server,OU=TM1,O=www.ibm.com,C=US
*       start date: Mar 31 18:50:22 2015 GMT
*       expire date: Mar 27 18:50:22 2035 GMT
*       common name: TM1Server
*       issuer: CN=TM1Server,OU=TM1,O=www.ibm.com,C=US
* Server auth using Basic with user ''
> GET /api/v1/Configuration HTTP/1.1
> Authorization: Basic Og==
> User-Agent: curl/7.29.0
> Host: mytm1server:80
> Accept: */*
> Cookie: TM1SessionId=iJiQkqUDOEmdvN6A6_tHfQ
>
< HTTP/1.1 401 Unauthorized
HTTP/1.1 401 Unauthorized
< Content-Type: text/plain
Content-Type: text/plain
< Content-Length: 0
Content-Length: 0
< Connection: keep-alive
Connection: keep-alive
< OData-Version: 4.0
OData-Version: 4.0
* gss_init_sec_context() failed: : Success
< WWW-Authenticate: Negotiate, Basic realm="TM1"
WWW-Authenticate: Negotiate, Basic realm="TM1"

<
* Connection #0 to host mytm1server left intact

注意有帮助的gss_init_sec_context() failed: : Success;-)

我还尝试获取服务票证而不是TGT:

I also tried getting a service ticket instead of a TGT:

$/usr/share/centrifydc/kerberos/bin/kinit -S tm1s/mytm1server
Password for myuser@MYREALM:

$/usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_100771
Default principal: myuser@MYREALM

Valid starting       Expires              Service principal
01/24/2020 13:37:52  01/24/2020 23:37:52  tm1s/mytm1server@MYREALM
        renew until 01/25/2020 13:37:46

也没有成功

$curl -ik --negotiate -u : -b ~/cookiejar.txt -c ~/cookiejar.txt https://mytm1server/api/v1/Configuration
HTTP/1.1 401 Unauthorized
Content-Type: text/plain
Content-Length: 0
Connection: keep-alive
OData-Version: 4.0
WWW-Authenticate: Negotiate, Basic realm="TM1"

curl 7.48.0以及GSS-API和SPNEGO均未成功

在另一台使用curl 7.48.0的计算机上，我遵循了 Michael-O的说明 除了我正在尝试没有密钥表文件(我们将没有可用的密钥表文件):

No success with curl 7.48.0 and GSS-API and SPNEGO

On a different machine with curl 7.48.0, I followed the instructions of Michael-O except that I'm trying to go without a keytab file (we won't have that available):

$ curl --version
curl 7.61.1 (x86_64-redhat-linux-gnu) libcurl/7.61.1 OpenSSL/1.1.1c zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh/0.8.5/openssl/zlib nghttp2/1.33.0
Release-Date: 2018-09-05
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz brotli TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL Metalink

$/usr/share/centrifydc/kerberos/bin/kinit myuser
Password for myuser@MYREALM:

$/usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_100123
Default principal: myuser@MYREALM

Valid starting       Expires              Service principal
01/24/2020 15:19:34  01/25/2020 01:19:34  krbtgt/MYREALM@MYREALM
        renew until 01/25/2020 15:19:31

$curl -ik --negotiate -u : -b ~/cookiejar.txt -c ~/cookiejar.txt https://mytm1server/api/v1/Configuration
*   Trying 10.10.100.100...
* TCP_NODELAY set
* Connected to mytm1server (10.10.100.100) port 80 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=US; O=www.ibm.com; OU=TM1; CN=TM1Server
*  start date: Mar 31 18:50:22 2015 GMT
*  expire date: Mar 27 18:50:22 2035 GMT
*  issuer: C=US; O=www.ibm.com; OU=TM1; CN=TM1Server
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET /api/v1/Configuration HTTP/1.1
> Host: mytm1server:80
> User-Agent: curl/7.61.1
> Accept: */*
> Cookie: TM1SessionId=m0uTI8ceIVM2TamOFMxPHg
>
< HTTP/1.1 401 Unauthorized
HTTP/1.1 401 Unauthorized
< Content-Type: text/plain
Content-Type: text/plain
< Content-Length: 0
Content-Length: 0
< Connection: keep-alive
Connection: keep-alive
< OData-Version: 4.0
OData-Version: 4.0
< WWW-Authenticate: Negotiate, Basic realm="TM1"
WWW-Authenticate: Negotiate, Basic realm="TM1"

<
* Connection #0 to host mytm1server left intact

请注意，这里没有gss_init_sec_context() failed: : Success

无论我是否手动export KRB5CCNAME=/tmp/krb5cc_100123(不需要)，它也不起作用:

Whether or not I manually export KRB5CCNAME=/tmp/krb5cc_100123 (shouldn't be required), it doesn't work either:

$export KRB5CCNAME=/tmp/krb5cc_100123
$curl -ik -u : -b ~/cookiejar.txt -c ~/cookiejar.txt https://mytm1server/api/v1/Configuration
HTTP/1.1 401 Unauthorized
Content-Type: text/plain
Content-Length: 0
Connection: keep-alive
Set-Cookie: TM1SessionId=mGR4OPSynQmCBIRd_B_L7g; Path=/api/; HttpOnly; Secure
WWW-Authenticate: Negotiate, Basic realm="TM1"

现在，当然可以问是否允许用户登录.但是使用TM1的官方客户端，集成登录可以正常工作.

Now of course, one may ask if the user is even allowed to log in. But using TM1's official client, integrated login works flawlessly.

有人看到问题了吗，还是知道如何获取更多调试信息?

Does anyone see what's wrong, or know how to get more debug information?

更新#1

我发现了此博客帖子，而且看来确实可以完全一样的东西.但是，我注意到服务器使用WWW-Authenticate: Negotiate进行响应，而TM1使用WWW-Authenticate: Negotiate, Basic realm="TM1"进行响应.因此，我构建了一个虚拟应用程序来模拟这两种情况并猜测我发现了什么:在仅协商"情况下，curl正确发送了第二个请求.但是，在TM1情况下则不会.

I found this blog post and it seems to do the exact same thing. I noticed, however, that the server responds with WWW-Authenticate: Negotiate whereas TM1 does with WWW-Authenticate: Negotiate, Basic realm="TM1". So I built a dummy application to simulate both cases and guess what I found: in the Negotiate-only case, curl correctly sends a second request. In the TM1 case however, it does not.

推荐答案

事实证明，自7.64.0起

As it turned out, as of 7.64.0 curl doesn't support comma-separated HTTP header values in the server response.

所以这不起作用:

WWW-Authenticate: Negotiate, Basic realm="TM1"

这样做的时候:

WWW-Authenticate: Negotiate

这篇关于用--negotiate卷曲/Kerberos似乎不起作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆