Running az login from a remote ubuntu server pops up asking to authenticate in local brower; Ends up with localhost URL

[NipunaPrashan]

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

[yonzhan]

Thank you for opening this issue, we will look into it.

[NipunaPrashan]

I just noticed az login --debug opens the port forwarding automatically in the remote server and the authentication goes into a successful state even with localhost redirect URL, but not with az login command.

If I use az login, I have to manually port forward.

[jiasli]

Using localhost is defined by the auth code flow. As defined by the protocol, auth code flow should only be used on the same machine. Running az login on the remote machine and completing the login in a browser on the local machine is against the protocol.

The only difference between az login --debug and az login is az login --debug prints the debug log, nothing more. Neither az login --debug nor az login does 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 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?

cc @rayluo

[rayluo]

@jiasli is right on the using of localhost and the --debug behavior.

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 @NipunaPrashan is willing to explore, @jiasli we can consider building a proof-of-concept Azure CLI "az login --port 1234" which will then feed the port into MSAL.

[bgavrilMS]

2 thoughts:

1. 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

2. 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!

[NipunaPrashan]

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 login command from my VM server.
• so I type az login command 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 --debug somehow this works even-though login completes in my local machine browser.

[NipunaPrashan]

Hi @jiasli, were you able reproduce the issue?

[NipunaPrashan]

Hi @jiasli, do you have any update. Happy to give you any more information if you need to debug this issue.

[ffMathy]

I am experiencing this too.

[yoshigev]

For any vscode user stumbling over this:

TL;DR, Set remote.autoForwardPortsSource=process.

When running az login --debug on 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 login working, the parameter remote.autoForwardPortsSource can be set to process (instead of the default output) which monitors the actual opened ports. This will cause vscode to forward the port although it does not appear on the output.

---

For az maintainers (@jiasli / @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 https://github.com/microsoft/vscode/issues/143958#issuecomment-1050959241.

[rayluo]

For any vscode user stumbling over this:

TL;DR, Set remote.autoForwardPortsSource=process.

When running az login --debug on 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 login working, the parameter remote.autoForwardPortsSource can be set to process (instead of the default output) which monitors the actual opened ports. This will cause vscode to forward the port although it does not appear on the output.

For az maintainers (@jiasli / @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

Currently, az login --debug will 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=abort

Are 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, @jiasli ?

BTW, these latest conversation does NOT address the current issue which was about "running az login from a remote server". @yoshigev , we should have create a new issue for this new conversation.

[yoshigev]

Thanks @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 - https://github.com/microsoft/vscode/issues/203869.

If it will be accepted, no change would be needed on az login code.

[Devinwong]

FWIW, 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.