Virtual Machines (VM) in Azure are like Amazon EC2s. To launch an instance, we have to know which VM image we want to launch. We can use the az vm image list command to list a set of images that we can use. In the following example, we'll use a CentOS image:

# az vm image list --output table
You are viewing an offline list of images, use --all to retrieve an up-to-date list
Offer Publisher Sku Urn UrnAlias Version
------------- ---------------------- ------------------ -----------------------------------------
CentOS OpenLogic 7.5 OpenLogic:CentOS:7.5:latest CentOS latest
CoreOS CoreOS Stable CoreOS:CoreOS:Stable:latest CoreOS latest
Debian credativ 8 credativ:Debian:8:latest Debian latest
openSUSE-Leap SUSE 42.3 SUSE:openSUSE-Leap:42.3:latest openSUSE-Leap latest
RHEL RedHat 7-RAW RedHat:RHEL:7-RAW:latest RHEL latest
SLES SUSE 12-SP2 SUSE:SLES:12-SP2:latest SLES latest
UbuntuServer Canonical 16.04-LTS Canonical:UbuntuServer:16.04-LTS:latest UbuntuLTS latest
WindowsServer MicrosoftWindowsServer 2019-Datacenter MicrosoftWindowsServer:WindowsServer:2019-Datacenter:latest Win2019Datacenter latest
WindowsServer MicrosoftWindowsServer 2016-Datacenter MicrosoftWindowsServer:WindowsServer:2016-Datacenter:latest Win2016Datacenter latest
WindowsServer MicrosoftWindowsServer 2012-R2-Datacenter MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest Win2012R2Datacenter latest
WindowsServer MicrosoftWindowsServer 2012-Datacenter MicrosoftWindowsServer:WindowsServer:2012-Datacenter:latest Win2012Datacenter latest
WindowsServer MicrosoftWindowsServer 2008-R2-SP1 MicrosoftWindowsServer:WindowsServer:2008-R2-SP1:latest Win2008R2SP1 latest

Then, we could use az vm create to launch our VM. Specifying --generate-ssh-keys will create an ssh for you to access:

# az vm create --resource-group devops --name newVM --image CentOS --admin-username centos-user --generate-ssh-keys
SSH key files '/home/chloe/.ssh/id_rsa' and '/home/chloe/.ssh/id_rsa.pub' have been generated under ~/.ssh to allow SSH access to the VM. If using machines without permanent storage, back up your keys to a safelocation.
 - Running ..
{
  "fqdns": "",
  "id": "/subscriptions/f825790b-ac24-47a3-89b8-9b4b3974f0d5/resourceGroups/devops/providers/Microsoft.Compute/virtualMachines/newVM",
  "location": "centralus",
  "macAddress": "00-0D-3A-96-6B-A2",
  "powerState": "VM running",
  "privateIpAddress": "10.0.0.4",
  "publicIpAddress": "40.77.97.79",
  "resourceGroup": "devops",
  "zones": ""
}

We can see that the publicIpAddress of the newly created VM is 40.77.97.79. Let's connect to it with the username we specified earlier:

# ssh [email protected]
The authenticity of host '40.77.97.79 (40.77.97.79)' can't be established.
ECDSA key fingerprint is SHA256:LAvnQH94bY7NaIoNgDLM5iMHT1LMRseFwu2HPqicTuo.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '40.77.97.79' (ECDSA) to the list of known hosts.
[centos-user@newVM ~]$

It isn't appropriate to allow SSH into the instance all the time. Let's take a look at how to fix this. First, we'll have to know the network interfaces that attach to this VM:

# az vm get-instance-view --name newVM --resource-group devops
{
 ...
 "networkProfile": {
    "networkInterfaces": [
      {
        "id": "/subscriptions/f825790b-ac24-47a3-89b8-9b4b3974f0d5/resourceGroups/devops/providers/Microsoft.Network/networkInterfaces/newVMVMNic",
        "primary": null,
        "resourceGroup": "devops"
      }
    ]
  },
  ...
}

After we find the id of the NIC, we can find the associated network security group based on the NIC ID:

# az network nic show --ids /subscriptions/f825790b-ac24-47a3-89b8-9b4b3974f0d5/resourceGroups/devops/providers/Microsoft.Network/networkInterfaces/newVMVMNic | jq .networkSecurityGroup
{
  "defaultSecurityRules": null,
  "etag": null,
  "id": "/subscriptions/f825790b-ac24-47a3-89b8-9b4b3974f0d5/resourceGroups/devops/providers/Microsoft.Network/networkSecurityGroups/newVMNSG",
  "location": null,
  "name": null,
  "networkInterfaces": null,
  "provisioningState": null,
  "resourceGroup": "devops",
  "resourceGuid": null,
  "securityRules": null,
  "subnets": null,
  "tags": null,
  "type": null
}

Here, we can see that the name of the NSG is newVMNSG. Let's list the rules that attach to this NSG:

# az network nsg rule list --resource-group devops --nsg-name newVMNSG
[
  {
    "access": "Allow",
    "description": null,
    "destinationAddressPrefix": "*",
    "destinationAddressPrefixes": [],
    "destinationApplicationSecurityGroups": null,
    "destinationPortRange": "22",
    "destinationPortRanges": [],
    "direction": "Inbound",
    "etag": "W/"9ab6b2d7-c915-4abd-9c02-a65049a62f02"",
    "id": "/subscriptions/f825790b-ac24-47a3-89b8-9b4b3974f0d5/resourceGroups/devops/providers/Microsoft.Network/networkSecurityGroups/newVMNSG/securityRules/default-allow-ssh",
    "name": "default-allow-ssh",
    "priority": 1000,
    "protocol": "Tcp",
    "provisioningState": "Succeeded",
    "resourceGroup": "devops",
    "sourceAddressPrefix": "*",
    "sourceAddressPrefixes": [],
    "sourceApplicationSecurityGroups": null,
    "sourcePortRange": "*",
    "sourcePortRanges": [],
    "type": "Microsoft.Network/networkSecurityGroups/securityRules"
  }
]

There is a default-allow-ssh rule with the ID /subscriptions/f825790b-ac24-47a3-89b8-9b4b3974f0d5/resourceGroups/devops/providers/Microsoft.Network/networkSecurityGroups/newVMNSG/securityRules/default-allow-ssh attached to the NSG. Let's delete it:

# az network nsg rule delete --ids "/subscriptions/f825790b-ac24-47a3-89b8-9b4b3974f0d5/resourceGroups/devops/providers/Microsoft.Network/networkSecurityGroups/newVMNSG/securityRules/default-allow-ssh"

As soon as we delete the rule, we can no longer access the VM via SSH:

# ssh [email protected]
...