正在尝试从curl访问azure应用程序日志流，如azure kudu网页所建议的那样。我使用的是windows10命令提示符。这是我正在尝试的命令行示例：

curl -u myUserName https://myApp.scm.azurewebsites.net/api/logstream
Enter host password for user 'myUserName':<password typed here>
``` `myApp` ：是我的azure应用程序服务的名称。 `myUserName` :
我尝试使用从web部署配置文件（VisualStudioPublishProfile使用的配置文件）获取的凭据。也就是说，当用户看起来像 `$myApp` 密码是60个字符长的字符串。
我还尝试从azureportal>myapp>deployment-credentials创建用户级部署凭据，其中请求部署/ftp用户名和密码
在这两种情况下，curl都会显示网页标题401-unauthorized:由于凭据无效，访问被拒绝。。我还尝试将用户名用双引号括起来，以及用反斜杠（\）转义美元符号（$）。运气不好。
我一定是在做傻事。我已经通过几个文件和职位，如官方kudu文件，msdn，在这里等，我想我是按照指示。其他来源：msdn，旧seierpost。
编辑
经过建议，我尝试访问https://myapp.scm.azurewebsites.net/basicauth 使用用户级部署凭据和vs web部署凭据（转义和未转义）：运气不好。我还保存了用户级密码再次，以防万一我做了一个错误之前。
然后我从卷发变成了失眠病人。
当我击中 `basicauth` ，同时使用用户级部署凭据和web部署凭据，实际的kudu页面将正确显示。
当我击中 `api/logstream` ，对于这两个凭据，请求似乎永远不会返回，我猜这是由于日志输出的连续流造成的。
所以看起来命令行中的curl有点搞笑，而不是客户端。我使用的 curl 版本：
curl 7.55.1（windows）libcurl/7.55.1 winssl
发布日期：【未发布】
协议：dict file ftp ftps http https imap imaps pop3 pop3s smtps telnet tftp
特性：asynchdns ipv6 largefile sspi kerberos spnego ntlm ssl
再回到 curl ：
当我放下枪的时候 `-u` 选项（从而密码提示）和手动添加由失眠生成的基本身份验证头，一切正常。
当我使用 `-u` 期权转让 `myUserName:myPassword` ，一切都很好。所以在提示下输入密码的方式似乎有点问题。
编辑#2
同样，在@davidebbo建议之后，verbose curl输出显示计算出的base-64令牌似乎是错误的。
工作的一个是44个字符长结束与一个单一的 `=` . 
 curl 的那个 `-v` 相反，输出是20个字符长，以双精度结尾 `=` .
他们都有相同的开头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
<