I want to reset admin password for my Azure VM running Windows deployed through ARM.
Reset VM password deployed with ARM.
Download and install Azure CLI https://azure.microsoft.com/en-us/documentation/articles/xplat-cli-install/
Open command line and enter the following command:C:\Program Files (x86)\Microsoft SDKs\Azure\CLI\wbin>azure login
Follow the instruction provided by command line
Select the Azure Subscription from which you want to reset the password for VM, Run command: Azure account set "Subscription Name" .
Run the command: azure vm reset-access -g [Resource Group name] -n [VMname] -u[username] -p[newPassword].(don’t use square bracket while forming command ).Make sure you don’t have VmExtension installed for Microsoft.Compute.VMAccessAgent handler.
Related
I am trying to use Add-AzVMSshPublicKey cmdlet to update ssh key on existing Azure linux VM , command executed without an issue but key hasnt been updated on server.
Is there any other way available where i can able to achieve OR any Azure cli command to do same ?
The Add-AzVMSshPublicKey cmdlet is used to add the public keys for SSH for a virtual machine, when only creating the VM. If you use the command with Update-AzVM, the command will error. So it does not use to add the keys after VM is created.
The following example updates the SSH key for the user azureuser on the VM named myVM.
az vm user update \
--resource-group myResourceGroup \
--name myVM \
--username azureuser \
--ssh-key-value ~/.ssh/id_rsa.pub
You can use the above CLI commands to append the new public key text to the ~/.ssh/authorized_keys file for the admin user on the VM. This does not replace or remove any existing SSH keys. You can SSH into that VM to remove the old public key if you would like to remove it.
Read Manage administrative users, SSH, and check or repair disks on Linux VMs using the VMAccess Extension with the Azure CLI for more details.
Alternatively, you can reset the SSH key from the Azure portal---> reset password.
I am building an Azure DevOps pipleline using Terraform. The pipeline creates a Linux server and then logs into the Linux server to update packages and install Apache.
I am currently storing the private key in my BitBucket repo (I know, this is not best practice), which are then pulled down onto the build agent server and then I login to the new server with the following command:
ssh -f -q -o BatchMode=yes -o StrictHostKeyChecking=no -i ../private_key.pem ubuntu#$ip sudo apt update -y
What is the best way to store and then retrieve the private key within Azure DevOps?
Two options I can think of:
1) Create an ssh service connection in azure DevOps. Reference the service connection in your pipeline. https://medium.com/#sibeeshvenu/ssh-deployment-task-in-azure-pipelines-b0e2923bd7b4
2) Store the SSH key as an Azure Key Vault secret and then download the secret using the Azure CLI during the build.
az keyvault secret download --name mysshkey --vault-name mykeyvault --file ~/.ssh/id_rsa
Authenticate the Azure CLI using a service principal, and supply the credentials to the pipeline using a variable group.
I found that Azure DevOps provides you a feature to upload secret files are part of the build. You can see more information here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/library/secure-files?view=azure-devops
I have set up WSL. And then installed docked following this tutorial and then installed azure cli.
I can login from windows command line; but I cannot login to azure container registry by using the command below from bash
$ az acr login --name $ACRNAME
I get the following error
Error response from daemon: Get https://ACRNAME.azurecr.io/v2/:
unauthorized: authentication required
And also if i tried to pull the image by
$ docker pull ${ACRNAME}.azurecr.io/image_name
get the same error
Error response from daemon: Get https://ACRNAME.azurecr.io/v2/:
unauthorized: authentication required
But i am able to see the list. The following command returns list
$ az acr repository list -n $ACRNAME
I have found this closed issue and change my machine DNS server to 8.8.8.8 but no progress. What am i missing?
For you issue, you maybe use the wrong username and password. So, first you can check your username and password which you choose to login. You can get the information in portal: container->Access keys.
You can get more information from this document az acr with az acr check-name and az acr create.
I've tried absolutely everything I can think of to do a SSH reset of my user on my Linux VM (Hortonworks Sandbox to be precise).
The VMAccessForLinux will not install, it simply states that it fails to provision:
I've tried adding it as 1.*,1.1, 1.2 and now 1.4 as per https://github.com/Azure/azure-content/blob/master/articles/virtual-machines/virtual-machines-troubleshoot-ssh-connections.md
I can't access my SSH, and I can't do any of the Azure reset commands, either using Azure CLI or Azure PS.
The VM is a RM vm.
How can I resolve this?
In PS I get errors like:
I'm beyond tearing my hair out.
And before anyone suggest that I use the portal, this is what I'm offered there (thanks Azure):
I can't say if this is a universal fix, but I managed to resolve this issue, by using the following in the Azure CLI:
$ azure vm reset-access -n {VMNAME} -g {GROUPNAME} \
-u {SSH_USER} -p {SSH_PASS} -E 1.4 -vv --json
It did NOT work for my original user on the box though; I created ANOTHER user, and from there I did a password reset with a sudo on the box, then I could SSH into the box from that user.
Firstly, can you go through the instructions here if you've not already. The VM extension has changed recently and that is the latest doc to go through: https://azure.microsoft.com/en-us/blog/using-vmaccess-extension-to-reset-login-credentials-for-linux-vm/.
EDIT #1
Glad to see you resolved it by creating a new user with reset-access.
If azure vm reset-access should fail, the next step would have been to download this tool which can allow you to inspect the VHD when not logged onto the VM: https://github.com/paulmey/inspect-azure-vhd - and inspect Waagent log is /var/log/waagent.log (You can see extension updates here) and
extension.log in /var/log/azure/.
I am using TFS to kick off PSExec to run an InstallShield process that creates installers. Our TFS build agent runs under the NETWORK SERVICE account.
I run PSExec using the -u -p options, and I am able to run the command and successfully build the installers from a command prompt against the remote machine.
However in TFS, I always get a 2250 error code and the installers don't build.
To isolate the problem, I changed the psexec command to the following...
PsExec.exe -accepteula \\<machine> -u <username> -p <password> xcopy /y c:\temp\testing.bat c:\temp\1.bat
If I run the above from the command line it copies the file. If I run the above from TFS (calling out to the above in a batch file), it fails with 2250.
So to simulate what TFS is doing I...
Started a command prompt with elevated Admin privileges
Issued psexec -i -u "nt authority\network service" cmd.exe
Ran the batch file containing the above xcopy command
So step 2 starts a command prompt using the NETWORK SERVICE account. When I run step 3 from this command prompt, I received the same 2250 error. So this is good b/c now TFS is out of the picture, and I am closer to the real issue.
Just for grins I added NETWORK SERVICE to the remote box's Administrators group. That did not solve the issue.
So here is where I am at...
If I login to the TFS box using a login in the Administrator group, open a command prompt, and run the xcopy command batch file with the -u -p parameters, everything works fine.
If I start a cmd prompt with the NETWORK SERVICE account and run the same batch file as in step 1 I get a 2250 access denied.
So in my mind the issue is clearly related to the NETWORK SERVICE account. Question is how can I get psexec to run with this account?
UPDATE
Here are the dialogs that show the NETWORK_SERVICE account in the Administrators group for and that it has full access to the path (c:\temp).
Let's say your two machines are called TFSSERVER and TARGETMACHINE.
The NetworkService on the TFS Server would be seen as the machine account, i.e. DOMAIN\TFSSERVER$, on the TARGETMACHINE. Any accounts in the NT AUTHORITY group are local accounts so it looks like you've just added TARGETMACHINE's network service as an admin, not the TFS machine's network service.
Try adding the TFS machine account to your permissions list and see if it works.
If that doesn't, look at this related question and see if anything there helps you at all: PSEXEC, access denied errors