Azure Kudu 访问被curl 拒绝

Question

按照 Azure Kudu 网页的建议，尝试从curl 访问Azure 应用程序日志流。我使用的是 Windows 10 命令提示符。这是我正在尝试的示例命令行:

curl -u myUserName https://myApp.scm.azurewebsites.net/api/logstream
Enter host password for user 'myUserName':<password typed here>

• myApp:是我的 Azure 应用服务的名称。

• 我的用户名:

  • 我尝试使用从 Web 部署配置文件(Visual Studio 发布配置文件使用的配置文件)中获取的凭据。也就是说，当用户看起来像 $myApp 并且密码是某个 60 个字符的长字符串时。
  • 我还尝试从 Azure 门户 > MyApp > 部署凭据创建用户级部署凭据，其中要求提供部署/FTP 用户名和密码

在这两种情况下，curl 都会显示网页标题的内容401 - 未经授权:由于凭据无效，访问被拒绝。。我还尝试将用户名括在双引号内，以及使用反斜杠 (\) 转义美元符号 ($)。运气不好。

我一定是在做一些非常愚蠢的事情。我已经阅读了几个文档和帖子，例如 official Kudu docs , msdn , here on SO我想我正在遵循指示。其他来源:MSDN again , old seirer post .

编辑

经过建议，我尝试访问https://myApp.scm.azurewebsites.net/basicauth使用用户级部署凭据和 VS Web 部署凭据(转义和未转义):没有运气。我还再次保存了用户级密码，以防万一我之前犯了错误。

然后我从curl切换到Insomnia客户端。

当我使用用户级部署凭据和 Web 部署凭据点击 basicauth 时，实际的 Kudu 页面会正确显示。
当我使用两个凭据点击 api/logstream 时，请求似乎永远不会返回，我猜这是由于日志输出的连续流所​​致。

因此，与 Insomnia 客户端相比，来自命令行的 curl 似乎发生了一些有趣的事情。我正在使用的 Curl 版本:

curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
Release-Date: [unreleased]
Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL

再次返回 curl :

当我删除 -u 选项(以及密码提示)并手动添加 Insomnia 生成的基本身份验证 header 时，一切都很好。
当我使用 -u 选项传递 myUserName:myPassword 时，一切都很好。因此，在提示符下输入密码的方式似乎确实有些问题。

编辑#2

同样，在@David Ebbo 建议之后，详细的curl 输出显示计算出的Base-64 token 似乎是错误的。

• 有效的长度为 44 个字符，以单个 = 结尾。
• curl -v 输出中显示的结果是 20 个字符长，以双 = 结尾。
• 它们都具有相同的开头 17 个字符。

根据this，这可能是由于尾随换行符被视为密码的一部分。 。但无论如何，不​​知道如何从这里继续前进。此时，只需了解发生了什么，解决方法已经存在。为了完整起见，这是(经过编辑的)详细日志:

*   Trying xxx.xx.xx.xxx...
* TCP_NODELAY set
* Connected to myApp.scm.azurewebsites.net (xxx.xx.xx.xxx) port 443 (#0)
* schannel: SSL/TLS connection with myApp.scm.azurewebsites.net port 443 (step 1/3)
* schannel: disabled server certificate revocation checks
* schannel: verifyhost setting prevents Schannel from comparing the supplied target name with the subject names in server certificates.
* schannel: sending initial handshake data: sending 186 bytes...
* schannel: sent initial handshake data: sent 186 bytes
* schannel: SSL/TLS connection with myApp.scm.azurewebsites.net port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with myApp.scm.azurewebsites.net port 443 (step 2/3)
* schannel: encrypted data got 2904
* schannel: encrypted data buffer: offset 2904 length 4096
* schannel: received incomplete message, need more data
* schannel: SSL/TLS connection with myApp.scm.azurewebsites.net port 443 (step 2/3)
* schannel: encrypted data got 818
* schannel: encrypted data buffer: offset 3722 length 4096
* schannel: sending next handshake data: sending 126 bytes...
* schannel: SSL/TLS connection with myApp.scm.azurewebsites.net port 443 (step 2/3)
* schannel: encrypted data got 51
* schannel: encrypted data buffer: offset 51 length 4096
* schannel: SSL/TLS handshake complete
* schannel: SSL/TLS connection with myApp.scm.azurewebsites.net port 443 (step 3/3)
* schannel: stored credential handle in session cache
* Server auth using Basic with user 'myUserName'
> GET /api/logstream HTTP/1.1
> Host: myApp.scm.azurewebsites.net
> Authorization: Basic {{CALCULATED TOKEN}}
> User-Agent: curl/7.55.1
> Accept: */*
>
* schannel: client wants to read 102400 bytes
* schannel: encdata_buffer resized 103424
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: encrypted data got 1501
* schannel: encrypted data buffer: offset 1501 length 103424
* schannel: decrypted data length: 1472
* schannel: decrypted data added: 1472
* schannel: decrypted data cached: offset 1472 length 102400
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: decrypted data buffer: offset 1472 length 102400
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 1472
* schannel: decrypted data buffer: offset 0 length 102400
< HTTP/1.1 401 Unauthorized                  
< Content-Type: text/html                    
< Server: Microsoft-IIS/10.0                 
* Authentication problem. Ignoring this.     
< WWW-Authenticate: Basic realm="site"       
< Date: Wed, 13 Jun 2018 21:23:59 GMT        
< Content-Length: 1293                       
<
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<title>401 - Unauthorized: Access is denied due to invalid credentials.</title>
{{... CONTINUES}}

Answer 1

继续其他答案。

使用

curl -u 'myUserName:password' https://myApp.scm.azurewebsites.net/api/logstream

其中用户名和密码是发布用户名和密码。这些可以在 Azure 门户的 Azure Function 概述菜单项中找到。单击获取发布配置文件以获取 XML 文件。在 XML 中查找 Web Deploy 发布配置文件元素。此元素包含 userName 和 userPWD 属性，它们是您的发布用户名和密码。

您的用户名很可能以 $ 开头。如果您使用 bash 或其中一种 shell，则必须在 curl -u 参数中使用单引号。使用双引号会导致参数替换。