Set-AzEnvironment -SshAuthScope <string> Errors out for "built-in or discovered environments"

[anwarnuma]

Description

The following commit was added to support adding SshAuthScope to clouds that did not have urls hardcoded in the repo: https://github.com/Azure/azure-powershell/commit/c690c21c318798d4686e70caee1cf22df3acaf4f

Unfortunate for clouds that are 'discovered or built-in' but do not have the SshAuthScope there is no way to add it due to the following line. We are currently encountering the error Cannot change built-in or discovered environment when we try to run the Set-AzEnvironment -Name <EnvName> -SshAuthScope <url> :

https://github.com/Azure/azure-powershell/blob/dd5c97b8ed62bda422fa0d7d6a644ca79763ee6b/src/Accounts/Accounts/Environment/SetAzureRMEnvironment.cs#L214-L218

And when running the Enter-AzVM -ResourceGroupName <Rg-name> -Name <VM-name> command we get: Failed to generate AAD Certificate with exception: The scope of authenticating for SSH is not set. Please run "Set-AzEnvironment -Name <EnvName> -SshAuthScope ..." to set it first

Issue script & Debug output

N/A

Environment data

PSVersion    7.5.1
PSEdition    Core
GitCommitId  7.5.1
Platform     Win32NT
PSCompatibleVersion {1.0, 2.0, 3.0, 4.0...}

Module versions

Az.Accounts 5.1.1
Az.Compute  9.0.0
Az.Ssh      0.2.3

Error output

Message: Failed to generate AAD Certificate with exception: The scope of authenticating for SSH is not set. Please run "Set-AzEnvironment -Name <EnvName> -SshAuthScope ..." to set it first ...

Exception: Microsoft.Azure.Commands.Common.Exception.AzPSApplicationException
InvocationInfo: {Enter-AzVM}

[isra-fel]

For the three built-in environments we have hardcoded values as a fallback so they'll work even if the user doesn't set SshAuthScope. https://github.com/Azure/azure-powershell/blob/f7c0407b860acf0f2e38cbe0b41cf496cc8791f4/src/Accounts/Authentication/Factories/SshCredentialFactory.cs#L36-L38

Problem is with discovered environments that are not one of AzureCloud, AzureChinaCloud or AzureUSGovernment. In this case, there isn't a hardcoded SshAuthScope, and we don't support editing the discovered environment directly. @anwarnuma can you please confirm if that's the case?

Currently, the workaround is to manually create an environment based on the endpoints of the discovered environment, set SshAuthScope, and re-login with the new environment. Which is not convenient at all.

Proposal:

1. Allow editing discovered environments. Question: can the user reset it if they are not happy?
2. Make it easy to copy an environment, e.g. introduce Copy-AzEnvironment for easy editing

[anwarnuma]

Problem is with discovered environments that are not one of AzureCloud, AzureChinaCloud or AzureUSGovernment. In this case, there isn't a hardcoded SshAuthScope, and we don't support editing the discovered environment directly. @anwarnuma can you please confirm if that's the case?

@isra-fel Yes, this is the case exactly

[isra-fel]

OK. I'd prefer introducing a Copy-AzEnvironment command to keep the integrity of the built-in environments. The user scenario would be like

Copy-AzEnvironment -From "DiscoveredEnv" -To "CopyEnv"
Set-AzEnvironment -Name "CopyEnv" -SshAuthScope "******"
Connect-AzAccount -Environment "CopyEnv"

@anwarnuma does it sound right to you? Is it known to you what to put in -SshAuthScope for your environment?

[anwarnuma]

Yes, it known what to put into -SshAuthScope. Would it also be possible to use the -SshAuthScope cmdline option directly with commands under Az.Ssh, so creating a new environment isn't always necessary?

something like: Enter-AzVM -ResourceGroupName <Rg-name> -Name <VM-name> -SshAuthScope <AuthScope>

[isra-fel]

The scope is changing according to the cloud (public cloud, Azure China, Azure US Gov...), so it makes sense for it to live with similar values such as the endpoint of Azure Resource Manager, or the sign-in audience of the data plane APIs of Azure Key Vault.

That said, it would be a good idea to be able to override the scope via parameters.

Draft design

1. A new optional parameter [-SshAuthScope <String>] will be added to cmdlets in Az.Ssh module which require extra authentication.
2. During authentication, the choice of auth scope follows this priority chain: parameter -> environment -> hardcoded values -> throw exception.
3. Enhancement to AzEnvironment: either
   1. Design a command to copy any environment for easy editing, or
   2. Allow editing built-in or discovered environments by -Force

[isra-fel]

@vthiebaut10 Hi! How do you think about the above proposal?

[vthiebaut10]

Sorry for the delay @isra-fel. I don't have a full understanding on how the AzEnvironments work on Azure PowerShell, so I don't know what the best way would be to enhance the cmdlets for editing built-in environments. As for the optional parameter, I think that is a good idea. How would de experience look for the customer once they provide the parameter? They would be attempting to retrieve a certificate for an environment different from the one they would be logged into, so would they be prompted to log in to the environment in the parameter during the execution of the cmdlet?

[anwarnuma]

Hi @isra-fel, is there any update on the above?