Network Injected Azure Cloud Shell Not Supported

[lsuarez5280]

Windows Terminal version

1.17.11461.0

Windows build number

10.0.22621.0

Other Software

No response

Steps to reproduce

1. Configure Cloud Shell with Azure Virtual Network injection according to the documentation. IMPORTANT: Deploy the virtual network in a Cloud Shell primary region to avoid failures, e.g. East US, West US, or South Central US as it seems secondary region support isn't guaranteed for the virtual network injection scenario in other regions.
2. Open an Azure Cloud Shell tab and perform device code login.
3. [Optional] Select a tenant from the list displayed by Terminal if appropriate for your account.
4. Elect whether to save connection settings.
5. Observe outputs.

Expected Behavior

A terminal prompt.

Actual Behavior

After logging in, selecting a tenant from my account list, and confirming saving connection settings, the terminal immediately displays:

Requesting a cloud shell instance...
Succeeded.
Requesting a terminal (this might take a while)...

[process exited with code 1 (0x00000001)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

[lhecker]

I personally don't use Azure Cloud Shell, so I'm a little unfamiliar with how it behaves, but when you write:

[process exited with code 1 (0x00000001)]

then that's a message specific to regular, local shells (including ssh). In other words, you're not talking about our built-in "Azure Cloud Shell" profile, right? So, when you write

Attempt to obtain a cloud shell from your tenant using Windows Terminal.

How are you "obtaining a cloud shell" then? After reading the documentation you've linked, I still don't quite understand how one would do that. Do you use some PowerShell commands to create a connection? If so, could you tell us your profile's command line (stripped of anything that's secret of course)?

[lsuarez5280]

@lhecker this is what you receive when opening an Azure Cloud Shell in terminal.

This is what I mean by attempting to obtain a cloud shell. I have no idea how Windows Terminal meaningfully functions, but if I had to guess, it's likely trying to function similarly to the Azure Portal cloud shell by proxying commands for an Azure Container Instance that lives in your Azure Virtual Network. This begins by logging in, selecting your tenant, and if it behaves anything like Portal, likely using Azure resource APIs from the Microsoft.Portal provider (I'd guess) to launch that container and poll for it to start.

To describe how this is done in Portal, this looks something like:

PUT /providers/Microsoft.Portal/consoles/default?api-version=2023-02-01-preview HTTP/1.1
Host: management.azure.com
Content-Type: application/json
Authorization: Bearer [jwt]

{
  "properties": {
    "osType": "linux"
  }
}

...and then transitioning to a periodic GET request on that same resource until the provisioningState property in the response is Succeeded. The response body is similar to the following:

{
  "properties": {
    "osType": "Linux",
    "provisioningState": "Succeeded",
    "uri": "https://gateway12.southcentralus.console.azure.com:443/n/cc-2edbc364/cc-2edbc364"
  }
}

A request is made to the URI provided in the response to identify the running terminal container's web socket interface and indicate window size (I would imagine for stream output formatting):

POST /n/cc-2edbc364/cc-2edbc364/terminals?cols=230&rows=13&version=2019-01-01&shell=pwsh
Host: gateway12.southcentralus.console.azure.com
Content-Type: application/json
Authorization: Bearer [jwt]

{}

And the response provides a URI for the web socket endpoint:

{
    "id": "[guid]",
    "socketUri": "wss://gateway12.southcentralus.console.azure.com/n/cc-2edbc364/cc-2edbc364/terminals/[guid]",
    "idleTimeout": "20",
    "tokenUpdated": true,
    "rootDirectory": "/home/lindsey"
}

The Portal uses that response to open web socket connections and stream commands to the endpoint providing access to cloud shell container using the socketUri returned in that API request, e.g.:

• wss://gateway12.southcentralus.console.azure.com/$hc/n/cc-2edbc364/cc-2edbc364/terminals/[guid], and
• wss://gateway12.southcentralus.console.azure.com/$hc/n/cc-2edbc364/cc-2edbc364/terminals/[guid]/control

---

As far as the full output of my experience in Windows Terminal, it is as follows when attempting to obtain a cloud shell from a tenant where I have configured those containers to be network injected into my Azure Virtual Network:

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code F4TD22D5B to authenticate.
This code will expire in 15 minutes.
Authenticated.
Tenant 0: Lindsey Suarez - Personal (lsuarezlearn.onmicrosoft.com)
Tenant 1: Corporate ([redacted].onmicrosoft.com)
Tenant 2: Sandbox ([redacted].com)
Tenant 3: Client ([redacted].onmicrosoft.com)
Please enter the desired tenant number.
> 0
Do you want to save these connection settings for future logins? [y/n]
> y
Your connection settings have been saved for future logins.
Requesting a cloud shell instance...
Succeeded.
Requesting a terminal (this might take a while)...

[process exited with code 1 (0x00000001)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

Normal output after selecting a tenant without my cloud shell settings configured for network injection instead looks like this:

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code FVRCS8MPB to authenticate.
This code will expire in 15 minutes.
Authenticated.
Tenant 0: Lindsey Suarez - Personal (lsuarezlearn.onmicrosoft.com)
Tenant 1: Corporate ([redacted].onmicrosoft.com)
Tenant 2: Sandbox ([redacted].com)
Tenant 3: Client ([redacted].onmicrosoft.com)
Please enter the desired tenant number.
> 2
Do you want to save these connection settings for future logins? [y/n]
> y
Your connection settings have been saved for future logins.
Requesting a cloud shell instance...
Succeeded.
Requesting a terminal (this might take a while)...


MOTD: SqlServer has been updated to Version 22!

VERBOSE: Authenticating to Azure ...
VERBOSE: Building your Azure drive ...
PS /home/lindsey>

The original report has been updated for clarity.

[JoeyC-Dev]

You may want to check with Cloud shell web version, which may give you more detailed error message.

One possible reason is that your fileshare which was mounted to cloud shell is unmounted. If this is the case, then:
https://learn.microsoft.com/en-us/azure/cloud-shell/persisting-shell-storage#the-clouddrive-mount-command

It is possible that this has nothing to do with Terminal.

---

Update: The reason I comment this is because that I faced the same issue, and eventually find out there is something wrong about the fileshare. You may want to "remove the saved connection settings" and then re-login in Terminal after solving the issue. To check if the issue gets solved, try using Cloud Shell web version.

[lsuarez5280]

@JoeyC-Dev Thank you for the suggestion. However, the network injected cloud shell works normally via the web interface.