Azure-cli: Azure CLI login will fail if .netrc or _netrc are under home directory

[paulpc]

so, this confuses the crap out of me; az login errors out on one of my macs, but not the other - same config (just that the broken one has been alive longer). reinstalled python3 via homebrew, reinstalled azure-cli a few times via homebrew, tried different networks (just in case it was the proxy), same disappointing result. I assume it's an artifact of an older version of something (removed the ~/.azure folder as well).

$ az login
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code [let_s_say_redacted] to authenticate.

Authentication failed. The 'Authorization' header is provided in an invalid format.

Environment summary

Mac OSX 10.13.3, installed via homebrew
 
$ brew list --versions
azure-cli 2.0.28_2
gdbm 1.14.1_1
gettext 0.19.8.1
libidn2 2.0.4
libunistring 0.9.9
openssl 1.0.2n
python 3.6.4_2 3.6.4_3
readline 7.0.3_1
sqlite 3.22.0
wget 1.19.4_1
xz 5.2.3

$ az --version
azure-cli (2.0.28)

acr (2.0.21)
acs (2.0.27)
advisor (0.1.2)
appservice (0.1.28)
backup (1.0.6)
batch (3.1.10)
batchai (0.1.5)
billing (0.1.7)
cdn (0.0.13)
cloud (2.0.12)
cognitiveservices (0.1.11)
command-modules-nspkg (2.0.1)
configure (2.0.14)
consumption (0.2.2)
container (0.1.19)
core (2.0.28)
cosmosdb (0.1.19)
dla (0.0.18)
dls (0.0.19)
eventgrid (0.1.10)
extension (0.0.9)
feedback (2.1.0)
find (0.2.8)
interactive (0.3.16)
iot (0.1.17)
keyvault (2.0.19)
lab (0.0.17)
monitor (0.1.2)
network (2.0.24)
nspkg (3.0.1)
profile (2.0.19)
rdbms (0.0.12)
redis (0.2.11)
reservations (0.1.1)
resource (2.0.24)
role (2.0.20)
servicefabric (0.0.10)
sql (2.0.22)
storage (2.0.26)
vm (2.0.27)

Python location '/usr/local/opt/python/bin/python3.6'
Extensions directory '/Users/[redacted]/.azure/cliextensions'

Python (Darwin) 3.6.4 (default, Mar 1 2018, 18:36:50)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)]

Legal docs and information: aka.ms/AzureCliLegal

[yugangw-msft]

@paulpc, could you please run with "--debug" and send the trace over to me at yugangw at microsoft dot com?
Also I assume the error of Authentication failed. The 'Authorization' header is provided in an invalid format. occur in the command window, not in the browser, right?

[paulpc]

@yugangw-msft - yes, console. web seems to be happy. will get the debug to you shortly

[paulpc]

looking at the debug output - everything seems the same before line:
the urllib3.connectionpool : https://management.azure.com:443 "GET /tenants?api-version=2016-06-01 HTTP/1.1" 401 150

the mac that works gets a 200, the one that doesn't gets a 401. I thought maybe there's a discrepancy in urllib3 version, but no - same one 1.22

[hdost]

@yugangw-msft Has there been any movement on this?

Here is a dump of my debug output

adal-python : <redacted> - OAuth2Client:Get token with device code Server returned this correlation_id: <redacted>
adal-python : <redacted> - TokenRequest:Storing retrieved token into cache
adal-python : <redacted> - CacheDriver:Adding entry AccessTokenId: b'<redacted>=', RefreshTokenId: b'<redacted>='
adal-python : <redacted> - CacheDriver:Added entry is MRRT
msrest.pipeline : Configuring request: timeout=100, verify=True, cert=None
msrest.pipeline : Configuring redirects: allow=True, max=30
msrest.pipeline : Configuring proxies: ''
msrest.pipeline : Evaluate proxies against ENV settings: True
msrest.pipeline : Configuring retry: max_retries=4, backoff_factor=0.8, max_backoff=90
urllib3.connectionpool : Starting new HTTPS connection (1): management.azure.com
urllib3.connectionpool : https://management.azure.com:443 "GET /tenants?api-version=2016-06-01 HTTP/1.1" 401 150
msrest.http_logger : Request URL: 'https://management.azure.com/tenants?api-version=2016-06-01'
msrest.http_logger : Request method: 'GET'
msrest.http_logger : Request headers:
msrest.http_logger :     'Connection': 'keep-alive'
msrest.http_logger :     'Accept': 'application/json'
msrest.http_logger :     'Accept-Encoding': 'gzip, deflate'
msrest.http_logger :     'User-Agent': 'python/3.4.7 (Darwin-16.7.0-x86_64-i386-64bit) requests/2.18.4 msrest/0.4.26 msrest_azure/0.4.21 subscriptionclient/1.2.1 Azure-SDK-For-Python'
msrest.http_logger :     'Authorization': '*****'
msrest.http_logger :     'x-ms-client-request-id': '<redacted>'
msrest.http_logger :     'accept-language': 'en-US'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger : Request body:
msrest.http_logger : None
msrest.http_logger : Response status: 401
msrest.http_logger : Response headers:
msrest.http_logger :     'Cache-Control': 'no-cache'
msrest.http_logger :     'Pragma': 'no-cache'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'Expires': '-1'
msrest.http_logger :     'WWW-Authenticate': 'Bearer authorization_uri="https://login.windows.net/", error="invalid_token", error_description="The authentication scheme of Basic is not supported."'
msrest.http_logger :     'x-ms-failure-cause': 'gateway'
msrest.http_logger :     'x-ms-request-id': '<redacted>'
msrest.http_logger :     'x-ms-correlation-request-id': '<redacted>'
msrest.http_logger :     'x-ms-routing-request-id': '<redacted>'
msrest.http_logger :     'Strict-Transport-Security': 'max-age=31536000; includeSubDomains'
msrest.http_logger :     'X-Content-Type-Options': 'nosniff'
msrest.http_logger :     'Date': 'Thu, 05 Apr 2018 13:29:20 GMT'
msrest.http_logger :     'Connection': 'close'
msrest.http_logger :     'Content-Length': '150'
msrest.http_logger : Response content:
msrest.http_logger : b'{"error":{"code":"AuthenticationFailedInvalidHeader","message":"Authentication failed. The \'Authorization\' header is provided in an invalid format."}}'
msrest.exceptions : Authentication failed. The 'Authorization' header is provided in an invalid format.

This dump is from 2.0.26 on Mac OSX Sierra 10.12.6, However I have tried also 2.0.30 as well. I have also tried this on a Fedora machine with 2.0.26 as well as 2.0.30.

One thing that I don't know if it's true in @paulpc's case is that my account is authenticated through a corporate SSO.

Finally I have tried this with both Firefox and Chrome. My assumption would be that this is not necessarily something in the CLI client, but is in the authorization service itself.

[paulpc]

@hdost - corporate SSO as well. Tried different browsers as well. What confuses the crap out of me is that my macbooc laptop works, whilst my desktop does not. Same networks, same configs.
I'll try ubuntu as well - just in case i'll be able to replicate.

[yugangw-msft]

@paulpc @hdost, I will get this clarified from AAD group and will post updates here

[paulpc]

@hdost - did you get it figured out?

I was greping through some burp output today for this and noticed that on the mac that's broken, it inserts an authentication header of basic for all the outgoing requests. The one that works, does not. Not really sure what would make it do that - can't find much reference to the authorization header in the code. if you're still broken, can you replicate?

[hdost]

I was not able to get it working, I can try again tomorrow. I'll set a
reminder.

---

Harold Dost | @hdost

On Wed, Apr 25, 2018, 13:13 Paul Poputa-Clean [e-mail]
wrote:

@hdost https://github.com/hdost - did you get it figured out?

I was greping through some burp output today for this and noticed that on
the mac that's broken, it inserts an authentication header of basic for all
the outgoing requests. The one that works, does not. Not really sure what
would make it do that - can't find much reference to the authorization
header in the code. if you're still broken, can you replicate?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-cli/issues/5767#issuecomment-384364072,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnTBqe9WMyCWLjhiqUAfW1qqKKBBkIeks5tsK7SgaJpZM4SkWw2
.

[paulpc]

FIGURED IT OUT!!!! az login was using the credentials in ~/.netrc that I had set up for a cron job in the past. Removed file, problem went away

[yugangw-msft]

Be more accurate, it is not CLI does this, instead the requests package does it, which is one of CLI's dependencies. Also it appears there are 2 files being silently considered under the home directory: .netrc and _netrc

[yugangw-msft]

@paulpc, by the way, thanks for the finding. I am marking this as document which we can find somewhere to call this out. It appears nowhere in the requests package that we can let it opt-out. //CC: @lmazuel

[lmazuel]

@yugangw-msft requests is full of surprise... thanks for the tag. I will dig this one.

Seems we got hit by that:
https://github.com/requests/requests/issues/3929

[hdost]

What @paulpc suggested also worked for me. I really hope that requests is willing to setup something. Would be make sense to leave this open as some sort of low priority. Honestly it would be a good fix to have.

Tracking: requests/requests#3929

[troydai]

File under requests being requests

[yonzhan]

I refine the title to make search engine can find it easily.