Azure Kudu Access denied with curl
Asked Answered
U

2

14

Trying to access Azure App log stream from curl, as suggested by Azure Kudu web page. I'm on Windows 10 command prompt. This is a sample command line I'm trying:

curl -u myUserName https://myApp.scm.azurewebsites.net/api/logstream
Enter host password for user 'myUserName':<password typed here>
  • myApp: is the name of my Azure App service.

  • myUserName:

    • I tried with credentials taken from web deployment profile, the one used by Visual Studio publish profile. That is, when user looks like $myApp and password is some 60-char long string.
    • I also tried creating user-level deployment credentials from Azure portal > MyApp > Deployment credentials where it asks for a deployment/FTP username and password

In both cases, curl shows the content of a web page title 401 - Unauthorized: Access is denied due to invalid credentials.. I tried also wrapping username within double quotes, as well as escaping the dollar sign ($) with a backward slash (\). No luck.

I must be doing something really silly. I've been through several docs and posts, like official Kudu docs, msdn, here on SO and I think I'm following the instructions. Other sources: MSDN again, old seirer post.

Edit

After suggestions, I tried to access https://myApp.scm.azurewebsites.net/basicauth with user-level deployment credentials, and with VS web deploy credentials (both escaped and unescaped): no luck. I also saved user-level password again, just in case I did a mistake before.

Then I switched from curl to Insomnia client.

When I hit basicauth, both with user-level deployment credentials and Web deploy credentials, the actual Kudu page is correctly shown.
When I hit api/logstream, with both credentials, it seems the request never returns, which I guess is due to the continuous flow from log output.

So it seems there's something funny going on with curl from command line, as opposed to Insomnia client. Curl version I'm using:

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

Back again on curl:

when I drop the -u option (and thus password prompt) and manually add the basic authentication header as generated by Insomnia, all is fine.
When I use -u option passing myUserName:myPassword, all is fine. So it really seems something in the way password is typed at its prompt.

Edit #2

Again, after @David Ebbo suggestion, the verbose curl output shows that calculated Base-64 token seems wrong.

  • The working one is 44-chars long ending with a single =.
  • The one shown in curl -v output instead is 20-chars long ending with a double =.
  • Both of them share the same initial 17 chars.

That might be due to trailing newline being taken as part of the password, according to this. But anyhow, not sure how to move on from here. At this point it's just a matter of understanding what's going on, the workarounds are already there. For completeness, here's the (redacted) verbose log:

*   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}}
Unbelt answered 12/6, 2018 at 14:56 Comment(9)
What you tried should have worked (both approaches). As a test, try going to myApp.scm.azurewebsites.net/basicauth. Do the same creds work there?Pendergast
thanks for suggestion. Tried with user-level deployment credentials, with VS web deploy credentials (both escaped and unescaped): no luck. I also saved user-level password again, just in case I did a mistake before. Just to confirm, yes I used https this time too. Maybe I should enable some flag in app properties?Unbelt
I updated the answer after more findingsUnbelt
Yeah, definitely looks like some curl issue, with it improperly building the basic auth header. Did you try passing -v in the failure case to see the full request?Pendergast
thanks again. Updating question. Base-64 token seems wrong.Unbelt
In my case my username had a dollar sign and dash -> $user-name. My solution was single quotes (double and no quotes will not work) -> curl -u '$user-name' my-app.scm.azurewebsites.net/api/logstreamTorticollis
Tried this from the command prompt on Windows. Getting access denied. Tried Cygwin, everything works correctly. Assuming it would work on Linux as well. Guessing the problem lies within Window's curl implementation. Try using Linux or cygwin.Maggee
@Unbelt Please mark one of the answers as the answer.Immersionism
@FrancoisBotha basically none of the answers seem to points to the actual problem, which seems to lie in the way curl works in Windows command prompt. It was not a matter of picking the right credentials, nor using the right quotes. That's why no answer is markedUnbelt
I
22

To follow on from other answers.

Use

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

Where username and password are the publishing username and password. These can be found in your Azure portal at the Azure Function overview menu item. Click Get publish profile to get an XML file. Look for the Web Deploy publish profile element in the XML. This element contains the userName and userPWD attributes which are your publishing username and password.

Most likely your username will start with a $. If you use bash or one of those shell, you'll have to use single quotation marks in your curl -u parameter. Using double quotation marks will lead to parameter substitution.

enter image description here

Immersionism answered 5/9, 2020 at 11:40 Comment(1)
I was calling this from a DevOps pipeline, the single quote did the trick on an Ubuntu image.Cuspidor
B
11

Try:

curl -u 'myUserName:password' https://myApp.scm.azurewebsites.net/api/logstream
Blare answered 11/4, 2019 at 17:17 Comment(3)
This should be the excepted answer along with a bit more information saying to make sure to use the publishing profile username and passwordVassell
Is there a solution wherein you don't have to disclose your password in the console?Salsbury
@Lopsided you can use curl -u username and it'll ask for the password.Gile

© 2022 - 2024 — McMap. All rights reserved.