az vm create doesn't work if the user specifies an admin password + ssh key; gives an unhelpful error message

[colemickens]

$ az vm create --name=colemick-nixosdev1 --resource-group=colemick-nixosdev1 --admin-username=cole --admin-password=redacted '--ssh-key-value=...' --size=Standard_D16s_v3 --image=/subscriptions/aff271ee-e9be-4441-b9bb-42f5af4cbaeb/resourceGroups/aznixos/providers/Microsoft.Compute/images/nixos-image-16.09.1694.019dcc3-x86_64-linux-vhd

az vm create: error: incorrect usage for authentication-type 'password': [--admin-username USERNAME] --admin-password PASSWORD

and then it works if I removed the SSH key.

1. The error message is unhelpful.
2. This should be allowed...

[tjprescott]

Why do you feel it should be allowed? The portal does not let you do both.

The error message should be improved.

[colemickens]

Hm. I thought the CLI used to allow this, but the history in Git doesn't support that; maybe the xplat-cli...

However, I do believe that CRP allows this (and re-checking the documentation doesn't list any limitation). Further, the CRP API exposes disablePasswordAuthentication which round-trips into the agent, and I'm curious if that flag is adjusted in the CLI based on which authentication_type it has chosen.

I wanted this because it's generally a valid conceptual choice. Raw cloud-init allows this, for example (though I know that user provisioning is still done via waagent). In my specific case, I want SSH access to the nodes, but I need a password because sudo is requiring one to elevate in this particular image.

It's actually just sort of overly, unnecessarily restrictive, maybe meant to prevent users from making a user error?

Side note, if someone picks this up for the error message, it looks like the same validation code is in the vm labs module, so update it there too possibly.

[colemickens]

I've just checked, @tjprescott, Compute RP certainly allows both a password and SSH key. I think this is a bug, and it should be an easy fix, just remove that validation code. The Portal isn't really important to me.

Can you confirm that you'd take this change? I can send a PR for it.

[tjprescott]

@colemickens if the API has no issue with it, I see no reason not to accept this change. I think the original validation was likely based on the Portal behavior. cc/ @yugangw-msft, @johanste

[Trotts]

Has this been fixed yet, running into the same error

[adewaleo]

@Trotts, @colemickens. I have started looking into this issue. The fix should be out in the release after this upcoming release.