azure - Azure Kudu 访问被 curl 拒绝

问题描述

正如 Azure Kudu 网页所建议的那样，尝试从 curl 访问 Azure App 日志流。我在 Windows 10 命令提示符下。这是我正在尝试的示例命令行：

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

myApp: 是我的 Azure 应用服务的名称。
myUserName：
- 我尝试使用来自 Web 部署配置文件的凭据，这是 Visual Studio 发布配置文件使用的凭据。也就是说，当用户看起来$myApp和密码是一些 60 字符长的字符串时。
- 我还尝试从 Azure 门户 > MyApp > 部署凭据创建用户级部署凭据，它要求提供部署/FTP 用户名和密码

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

我一定是在做一些非常愚蠢的事情。我已经阅读了几个文档和帖子，例如官方 Kudu 文档，msdn，在这里，我认为我正在按照说明进行操作。其他来源：MSDN 再次，旧的 seirer 帖子。

编辑

根据建议，我尝试使用用户级部署凭据和 VS Web 部署凭据（转义和未转义）访问https://myApp.scm.azurewebsites.net/basicauth ：不走运。我还再次保存了用户级密码，以防我之前犯了错误。

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

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

因此，与 Insomnia 客户端相比，命令行中的 curl 似乎有些有趣。我正在使用的卷曲版本：

curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
发布日期：[未发布]
协议：dict 文件 ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
功能：AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL

再次回到卷曲：

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

编辑#2

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

工作的是 44 个字符长，以单个=.
curl-v输出中显示的是 20 个字符，以 double 结尾=。
它们都共享相同的初始 17 个字符。

据此，这可能是由于尾随换行符被用作密码的一部分。但无论如何，不知道如何从这里继续前进。在这一点上，只需了解正在发生的事情，解决方法已经存在。为了完整起见，这里是（编辑的）详细日志：

*   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}}

标签： azureazure-clikuduazure-cloud-shell

从其他答案继续。

利用

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

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

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

azure - Azure Kudu 访问被 curl 拒绝

问题描述

解决方案

推荐阅读