curl with --negotiate / Kerberos 似乎不起作用
curl with --negotiate / Kerberos doesn't seem to work
我正在尝试将 curl 与 Kerberos（针对 TM1）结合使用。 中的答案似乎很有帮助，但是，它仍然对我不起作用。
curl 7.29.0 和 GSS-Negotiate 没有成功
我关注了
$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
但对我来说，它似乎不起作用：
$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：
$/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 的机器上，我遵循了 除了 我试图在没有 keytab 文件的情况下（我们不会有可用的）：
$ 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（应该不是必需的），它也不起作用：
$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 的官方客户端，集成登录完美无缺。
有没有人看出问题所在，或者知道如何获取更多调试信息？
更新 #1
我找到了 this blog post，它似乎在做同样的事情。然而，我注意到服务器响应 WWW-Authenticate: Negotiate 而 TM1 响应 WWW-Authenticate: Negotiate, Basic realm="TM1"。所以我构建了一个虚拟应用程序来模拟这两种情况并猜测我发现了什么：在仅协商的情况下，curl 正确地发送了第二个请求。然而，在 TM1 的情况下，它没有。
事实证明，从 7.64.0 开始 curl doesn't support comma-separated 服务器响应中的 HTTP header 值。
所以这行不通：
WWW-Authenticate: Negotiate, Basic realm="TM1"
同时这样做：
WWW-Authenticate: Negotiate
我正在尝试将 curl 与 Kerberos（针对 TM1）结合使用。
curl 7.29.0 和 GSS-Negotiate 没有成功
我关注了
$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
$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：
$/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 的机器上，我遵循了
$ 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（应该不是必需的），它也不起作用：
$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 的官方客户端，集成登录完美无缺。
有没有人看出问题所在，或者知道如何获取更多调试信息？
更新 #1
我找到了 this blog post，它似乎在做同样的事情。然而，我注意到服务器响应 WWW-Authenticate: Negotiate 而 TM1 响应 WWW-Authenticate: Negotiate, Basic realm="TM1"。所以我构建了一个虚拟应用程序来模拟这两种情况并猜测我发现了什么：在仅协商的情况下，curl 正确地发送了第二个请求。然而，在 TM1 的情况下，它没有。
事实证明，从 7.64.0 开始 curl doesn't support comma-separated 服务器响应中的 HTTP header 值。
所以这行不通：
WWW-Authenticate: Negotiate, Basic realm="TM1"
同时这样做：
WWW-Authenticate: Negotiate