Repository navigation
Running az login from a remote ubuntu server pops up asking to authenticate in local brower; Ends up with localhost URL #26556
Description
Activity
Thank you for opening this issue, we will look into it.
I just noticed
az login --debugopens the port forwarding automatically in the remote server and the authentication goes into a successful state even with localhost redirect URL, but not withaz logincommand.If I use
az login, I have to manually port forward.Using
localhostis defined by the auth code flow. As defined by the protocol, auth code flow should only be used on the same machine. Runningaz loginon the remote machine and completing the login in a browser on the local machine is against the protocol.The only difference between
az login --debugandaz loginisaz login --debugprints the debug log, nothing more. Neitheraz login --debugnoraz logindoes anything related to port forwarding. If there is indeed a port forwarding, it's very likely to be configured on your client machine.But I am indeed curious how you set up that remote Ubuntu server. Azure CLI and its underlying authentication library MSAL use Python built-in library
webbrowserto open a browser and then open a port onlocalhost. Why wouldwebbrowseropen the a web browser on the client machine? Do you have any special configuration in the remote Ubuntu server related to "browser forwarding" and port forwarding?Jiashuo Li (@jiasli) is right on the using of
localhostand the--debugbehavior.I am indeed curious how you set up that remote Ubuntu server. Azure CLI and its underlying authentication library MSAL use Python built-in library webbrowser to open a browser and then open a port on localhost. Why would webbrowser open the a web browser on the client machine? Do you have any special configuration in the remote Ubuntu server related to "browser forwarding" and port forwarding?
I am also curious on that one. It seems possible that a remote desktop can invoke a local browser (via X-forwarding?), but it is unlikely that the port-forwarding is also set up beforehand, especially when "az login" uses a random port. We may, however, potentially change Azure CLI to specify a specified port, so that to support the X-forwarding scenario. If Nipuna Prashan (@NipunaPrashan) is willing to explore, Jiashuo Li (@jiasli) we can consider building a proof-of-concept Azure CLI "az login --port 1234" which will then feed the port into MSAL.
2 thoughts:
-
Azure CLI / MSAL can detect if the OS is headless or not and provide a meaningful warning / error or default to device code flow. See https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/febbdd3c2746814ba301e65e16c572720b338893/src/client/Microsoft.Identity.Client/PlatformsCommon/Shared/DesktopOsHelper.cs#L148
-
With WSL (Windows Subsystem for Linux) port forwarding and opening of URLs does actually happen on the host OS (Windows). We do not see any security issues with this. So both URL opening and ports are forwared!
-
Hi All,
Thanks for your quick responses. Let me explain a bit about my deployment and how I use az command and why I use it.
- I have remote Azure ubuntu server (Azure VM) which I use to develop and deploy applications to my Azure AKS cluster.
- Sometimes, I need to access my azure resources from my Azure VM, so I use
az logincommand from my VM server. - so I type
az logincommand in the VM server terminal (I use vs code to access my VM) - This opens my local machine browser and allow me to login.
- Then comes the issue I mentioned initially.
- Login redirects to a localhost url in my local machine, so that is not redirecting correctly.
- If I type
az login --debugsomehow this works even-though login completes in my local machine browser.
1 remaining item
Hi Jiashuo Li (@jiasli), do you have any update. Happy to give you any more information if you need to debug this issue.
I am experiencing this too.
For any vscode user stumbling over this:
TL;DR, Set
remote.autoForwardPortsSource=process.When running
az login --debugon a remote server terminal, vscode will automatically forward the port, as the port appears on the terminal and vs codes finds it there.This is the default behavior.
For making plain
az loginworking, the parameterremote.autoForwardPortsSourcecan be set toprocess(instead of the defaultoutput) which monitors the actual opened ports. This will cause vscode to forward the port although it does not appear on the output.
For
azmaintainers (Jiashuo Li (@jiasli) / Ray Luo (@rayluo) ?) - maybe you can add a print of the port (probably in a URL syntax), so it will work with vscode out-of-the-box.A detailed explanation of vscode behavior could be found in microsoft/vscode#143958 (comment).
Reacted by Jiashuo LiFor any vscode user stumbling over this:
TL;DR, Set
remote.autoForwardPortsSource=process.When running
az login --debugon a remote server terminal, vscode will automatically forward the port, as the port appears on the terminal and vs codes finds it there.This is the default behavior.
For making plain
az loginworking, the parameterremote.autoForwardPortsSourcecan be set toprocess(instead of the defaultoutput) which monitors the actual opened ports. This will cause vscode to forward the port although it does not appear on the output.For
azmaintainers (Jiashuo Li (@jiasli) / Ray Luo (@rayluo) ?) - maybe you can add a print of the port (probably in a URL syntax), so it will work with vscode out-of-the-box.A detailed explanation of vscode behavior could be found in microsoft/vscode#143958 (comment).
Interesting finding, indeed. yoshigev (@yoshigev)
Currently,
az login --debugwill contain these two lines:DEBUG:msal.oauth2cli.oauth2:Using http://localhost:1234 as redirect_uri DEBUG:msal.oauth2cli.authcode:Abort by visit http://localhost:1234?error=abortAre you saying they - and probably just one of them - would be enough for VS code to auto-detect the port? I can make the first line as INFO log, but then Azure CLI would need to somehow enable INFO log by default. Alternatively, that line could be a warning log, but then it would sound too scary. What do you think, Jiashuo Li (@jiasli) ?
BTW, these latest conversation does NOT address the current issue which was about "running az login from a remote server". yoshigev (@yoshigev) , we should have create a new issue for this new conversation.
Thanks Ray Luo (@rayluo) for your response.
According to the OP, he's also using vscode, so I think this is the correct thread 😀. From his comment above:
- so I type az login command in the VM server terminal (I use vs code to access my VM)
To your question:
Are you saying they - and probably just one of them - would be enough for VS code to auto-detect the port?
Yes, so your proposed solution should work.
But note that I've had another idea of how to solve this from vscode side - microsoft/vscode#203869.
If it will be accepted, no change would be needed on
az logincode.Reacted by Ray LuoFWIW, I was running codespace and hit the same issue. My colleague suggested me to check the Auto forward ports source from VS code settings.
It was showing as process which was what we need, though the issue still happened. So I ended up setting it to hybrid and then back to process somewhat to enforce it. And it works like a charm now.Reacted by Ray LuoThis is great when running in VSCode but if running it over SSH in Terminal the dynamic port doesn't automatically get forwarded... if there was a parameter to use a standard port like 8000 or something could setup -L 8000:localhost:8000 to hopefully make this work
Just tried with VSCode with
--debugflag to have the auto forward work and Safari opened... I clicked the Identity and then it went to localhost failing saying it's not running... so the remote auto forward didn't work for me here.Curious when using kubelogin it uses https://microsoft.com/devicelogin instead of launching a python web server on localhost... anyway azure cli can do the same thing?
Curious when using kubelogin it uses https://microsoft.com/devicelogin instead of launching a python web server on localhost... anyway azure cli can do the same thing?
Quoted from this doc,
If Azure CLI can open your default browser, it initiates authorization code flow and opens the default browser to load an Azure sign-in page.
Otherwise, it initiates the device code flow and instructs you to open a browser page at
https://aka.ms/devicelogin. Then, enter the code displayed in your terminal.If no web browser is available or the web browser fails to open, you can force device code flow with az login --use-device-code.
Ray Luo (@rayluo) when I use
--use-device-coderemotely it throws error:TypeError: Session.request() got an unexpected keyword argument 'claims_challenge'If I run it locally it gives me the microsoft.com/devicelogin url and code like
kubelogindoes.I was merely quoting existing doc. I'll defer to my colleague Jiashuo Li (@jiasli) for further troubleshooting the
claims_challengeissue, and Iulian C. (@iulico-1) for auth issues. In general, Device Code Flow is on a deprecation path, its usage is not recommended.
Describe the bug
Running az login from a remote ubuntu server pops up asking to authenticate in local machine browser. After successful login browser redirects to a localhost URL with a random port. This does not complete the authentication.
Related command
az login
Errors
the commandline hangs with this, because browser cannot complete the authentication.
Issue script & Debug output
az login --debug
cli.knack.cli: Command arguments: ['login', '--debug']
cli.knack.cli: init debug log:
Enable color in terminal.
cli.knack.cli: Event: Cli.PreExecute []
...
open, use device code flow with
az login --use-device-code.msal.telemetry: Generate or reuse correlation_id: 41ef23e9-e5ab-42c8-89b8-92892ba5a570
msal.oauth2cli.oauth2: Using http://localhost:38149 as redirect_uri
msal.oauth2cli.authcode: Abort by visit http://localhost:38149?error=abort
Expected behavior
I doubt about the redirect URL.
Environment Summary
azure-cli 2.49.0
core 2.49.0
telemetry 1.0.8
Dependencies:
msal 1.20.0
azure-mgmt-resource 22.0.0
Python location '/opt/az/bin/python3'
Extensions directory '/home/nipuna/.azure/cliextensions'
Python (Linux) 3.10.10 (main, May 19 2023, 08:20:32) [GCC 9.4.0]
Legal docs and information: aka.ms/AzureCliLegal
Your CLI is up-to-date.
Additional context
No response