Using SSH with Azure Linux Virtual Machines

Accessing Windows VMs in Azure is pretty straightforward – after you create the VM, you can download an RDP file from the Azure portal and remotely administer the VM. You can also access your VM via PowerShell, although that is a bit more complex due to the need for certificates. But what if you are using a Linux VM?

Turns out – it's pretty easy. The Azure documentation article, at http://azure.microsoft.com/en-gb/documentation/articles/virtual-machines-linux-use-ssh-key/  shows you how to do it. The steps are pretty simple, but will vary with the Linux distro you are using.

The basic way is to first generate the SSH keys. The easiest way to do this is to load and  then using openssl to generate an X.509 certificate, Then connect with Putty.

You can also forego creating keys, and just using a password. You set the password when you create the VM, then just login using putty. When you do, it' looks a bit like this:

del.icio.us Tags: Linux VM,accessing VM,SSH,Putty

d

So for those of you who a) want to learn Linux and b) struggle with loading it on your own hardware – Azure provides a simple way to create then use a Linux VM.

Another Way to Access Azure VMs with PowerShell

In a blog post over the weekend, I demonstrated how you can access an Azure VM from an on-premises workstation using PowerShell. To summarise this approach: you first need to trust the management certificate provided to the VM by Azure, then use Enter-PSSession using the DNS name of the service, the port opened for PowerShell management endpoint and explicitly requesting SSL. While it took me a bit of time to work all this out (getting the cert downloaded was my biggest initial stumbling block), the approach is fairly simple.

But, like almost everything in PowerShell, it seems, there is yet another way to do this. No sooner had I posted that blog article when I got a tweet:

And – the answer was, at that point, no. I'd not noticed that cmdlet! I don't know all of then circa 500 cmdlets (yet)! But it was a nice prod to take a look. Johan's suggestion was a good one as the coding is simpler. Using both methods, you need to create a credential object to pass to the remote machine (specifying the UserID you created when you first created the Azure VM, or some other administrator you have created on the remote Azure system). And you need to trust the certificate the Azure machine presents when negotiating SSL between your client system and the Azure server. Once you have those two done, then you can   enter the PSSession like this:

$PshEP = Get-AzureVm cookhamlo | Get-AzureEndpoint  |
         Where name -eq 'PowerShell'
Enter-PsSession -ComputerName $VmName -Port $PshEp.Port –Credential
         $VmCred –UseSSL

Using Johan's suggestion, the coding would look like this:

$Azuri = Get-AzureWinRmUri -ServiceName $VmName                   
Enter-PsSession -ConnectionUri $Azuri.AbsoluteUri -Credential $VmCred

Having tried them, both approaches work perfectly fine (assuming you have a valid credential object and trust the remote system's management port certificate).  both approaches work, but it feels like the second approach to be easier.

del.icio.us Tags: PowerShell,Azure,Remote Management

Accessing Azure VMs with PowerShell

I've been doing quite a lot of work recently with Azure VMs and PowerShell. I've written some scripts to create a VM and to automate some common management functions on those Azure VMs (like re-size the VM, etc). I'm slowly posting the actual scripts to my PowerShell scripts blog (http://pshscripts.blogspot.co.uk). In the work I'm doing and in conversations with customers, many of the Azure VMs being created are stand alone. I see this as a great on-ramp to Azure, allowing the customer to dip their toe into the Azure water, for pretty minor costs. Once they are happy, they can move on to linking their on-premises infrastructure to the Azure Cloud. But in the meantime, those Azure VMs need to be managed – and of course, that means using PowerShell!

One of the first scripts I wrote was to create a simple, stand-alone VM in Azure. It took me quite a while, mainly because Azure is different to on-premises Hyper-V. I had to go through a small Azure learning curve. The first thing I want to do after creating an Azure VM is to manage it with PowerShell using remoting. You can do that, but there are a few barriers in the way (that would largely be absent in an on-premises Kerberos based authentication model!).

When you create an Azure VM, Azure creates a PowerShell endpoint to enable PowerShell management. Since the Azure VM is not in your on premises AD, you can certainly use Ntlanman authentication. (and authenticate against the in-VM user database). You need to provide a PowerShell credential object when logging into the remote session. But you know how to do that!!

The second issue is, since the VM is in a different secuity realm, the need to do mutual authentication upon creating the PowerShell session. For non-domain joined systems, this means using SSL. Yes there are ways around this or to simplify things, but there are security risks in doing so – so I'll stick with SSL. To use SSL, you need to trust the SSL certificate offered up by, in this case, the Azure VM.

When you create an Azure VM, you can either provide a certificate (e.g. issued by a CA you trust), or Azure can create a VM self signed certificate. To use the self signed cert, you need to trust the cert. To do this, you just Import the VM's defaul cert into your local host's trusted root store. Once in place, your system will trust the VM and complete authentication successfully

I've automated the task of importing the Cert with the the Install-WinRmAzureVmCert function, which I posted tonight on my scripts blog. This script defines a function that takes an Azure VM name and Azure service name, and installs the VM's default self signed cert into the local host's Trusted

$Vmname = 'CookhamLO.CloudApp.Net'
# Get the relevant Azure Subscription and set it
$SubscriptionName = (Get-AzureSubscription)[1].subscriptionname
Select-AzureSubscription $SubscriptionName
# And now install the cert
Install-WinRMAzureVMCert -CloudServiceName Cookhamlo  -VMName Cookhamlo

And once that is done, I just get the credential (I'll leave that up to the reader!), get the remote management end point to get the TCP port number to use for PowerShell remoting then call Enter-PsSession. Like this:

As you can see at the bottom of the screenshot, I just use Enter-PsSession and am able to access the remote VM.

This is all pretty easy, albeit complicated by the security architecture of Windows and Azure. It's nice to know one can create a very secure remoting tunnel to your Azure VMs and manage them simply – just using PowerShell.

del.icio.us Tags: Azure,VM,PowerShell

More Azure VM sizes Available

At the beginning of January, Microsoft announced the general availability of bigger Azure VM sizes. The G-Series proved more RAM, more logical processors combined with lots of SSD disk storage – these VM sizes should provide extraordinary  performance. The G-Series currently scales from Standard_G1 (2 CPU, 28 GB ram, 412 SSD), through to Standard_G5 (32 CPS, 448GB Ram, 6.5TB SSD). http://azure.microsoft.com/blog/2015/01/08/azure-is-now-bigger-faster-more-open-and-more-secure/ provides more capacity details for these new VMs.

These VM sizes are ideal for large database servers – not only SQL Server, but also My SQL, MongoDB, Cassandra, Cloudera, DataStax and others. Each VM can also have up to 64 TB of attached data disks! To help the compute grunt of these VMs, they feature the latest Intel CPUs (Intel® Xeon® processor E5 v3 family) and DDR4 memory.

When Microsoft first announced these new VM sizes, availability was restricted to the West US Azure region (but they were clear that they were working to add support in additional regions).  To help me find where I can get a particular VM size, I wrote a script function to find out which regions hold a particular VM size. Here's the function:

Function wherecaniget {
  [CmdletBinding()]
  param ($VMSize)
  # Get Locations
  $Locations = Get-AzureLocation
  # Where is that VM size?
  Foreach ($loc in $Locations) {
    $ln = $loc.DisplayName
    $rs = $loc.VirtualMachineRoleSizes
    If ($rs -contains $VMSize) {$ln}
  }
}

I notice that these new VM sizes are now available in the East US region as well.

 

The rate of change is just awesome!

del.icio.us Tags: Azure,Azure VM Sixes

Adding an Endpoint to an Azure VM

In a recent blog article, I showed you how you can create an Azure VM. If you are familiar with Hyper-V and the Hyper-V cmdlets – the approach is a little different (since you configure Azure differently). One aspect of creating a VM is how you, in effect, open ports to an Azure VM.

With Azure, you create an end point that, in effect, creates a public port and an internal port for your VM. You create one port, which is the public port (on the Azure service) and an internal port for the VM. The approach to doing this is pretty straightforward, although it's a pipelined pattern:

Get-AzureVM -ServiceName $ServiceName -Name $VmName  |
  Add-AzureEndPoint -Name "Http" -Protocol "tcp" -PublicPort 80 -LocalPort 80  |
    Update-AzureVm

This pattern has you first get the Azure VM object, to which you add an Azure endpoint. Then the updated object is piped to Update-AzureVm which adds the new endpoint to the VM. Of course, if the end point already exists, this pattern would throw an exception. With Add-AzureEndPoint, you specify the protocol, and public and external ports. This 'one-liner' creates a public port and an internal (local) port to enable the VM to serve HTTP traffic.

I've created a simple script, over on http://pshscripts.blogspot.com, that implements a New-HttpVmEndpoint function which you can use to add a new HTTP endpoint to a virtual machine. This script omits some error handling you might wish to add in. For example, you might want to check whether the end point already exists. or whether the VM and VM service exist. You could obviously extend that script to add other endpoints (eg HTTPS).

del.icio.us Tags: Azure,PowerShell,VM Endpoint,script

Creating Azure VMs with PowerShell

I've been playing for the past few weeks with Azure VMs. I can, obviously, do most things from the GUI, but somehow, as a PowerShell guy, that just seems wrong! So I've been honing up my PowerShell Skills. The Azure module contains over 500 commands. In the version on my home workstation, there are 509 commands, of which 35 are aliases.

As an aside, those aliases are use to alias the old 'windows azure pack' cmdlets which have in effect been replaced with newer cmdlets. For example, the old Get-WAPackSubscription is now an alias for Get-AzureSubscription. This is a great idea for helping to ensure forwards compatibility. I suspect we'll see more of it. For those of you with older Windows Azure Pack based scripts – you may consider upgrading those to use the new Azure Module native cmdlets.

The first thing you have to know about Azure VMs is that, while they are in the end 'just' a Hyper-V VM, they are a bit more complex than on-premise VMs. There are several Azure features, including storage accounts, images, endpoints, locations, and azure services to consider).

In azure, each VM runs within an Azure service. I like to think of the Azure service as the load balancer. In the simplest case of a single VM, you have a VM and the service and use the name and IP of the service to access the VM. The Service also allows you to provide more instances of the VM in an lbfo fashion. But today, I just want to create a simple VM. The VM I am creating runs inside a new Azure service of the same name as the VM

To create an Azure VM, you have two main options: use and Azure VM Image as the starting point for your VM, or create the VM on premise, and ship it's VHD up to azure and then create a VM using that uploaded VHD. In this blog post, I'll concentrate on the first, leaving the second for another day.

A VM image is a sysprepped operating system image often with additions and customisations. The image was built from some base OS with some changes possibly made. You can get simple base OS images – in effect what would be on the product DVD. Others have been customised, some heavily. Azure images come from a host of places, including Microsoft and the family. Once the reference Image is created, the creator then prepares.

You can easily create a VM from an existing VM image. To see the VM images in Azure, you simply use Get-AzureVMImage. As of writing there are 438 images. Of these, 187 are Linux based and 251 Windows based. A given image is in one and typically all Azure locations. An image belongs to an image family and has a unique image name. With 125 image families to chose from finding your image (and it's specific image name is based on Get-AzureVmImage and piping the output to your normal PowerShell toolset!

One suggestion if you are experimenting. Doing a Get-AzureVMImage call takes a while as you are going out to the internet (in my case behind a slow adsl line) is to save the images to a variable, then pipe the variable to where/group/sort/select thus avoiding the round trip up to the azure data center.

Today, I just want to create an image of Windows Server 2012 R2 Datacenter. So to find the image I do this:

 

Next, in creating the Azure VM, you need an Azure Storage Storage Account in which you are going to store the VHD for your VM. The VHD starts off as, in effect, a copy of the image (i.e. a syspreped version of Windows) stored in Azure Storage VM. You can pre-create the storage account, although in this case, I let the cmdlets build the storage account for me.

So here's the script:

# Create-Azurevm.ps1
# This script creates an azure VM
# Set Values
# VM Label we are looking for
$label          = 'Windows Server 2012 R2 Datacenter, December 2014'
#vm and vmservice names
$vmname         = 'psh1'
$vmservicename  = 'psh1'
# vm admin user and username
$vmusername     = 'tfl'
$vmpassword     = '~+aQ8$3£-4'
# instance size and location
$vminstancesize = 'Basic_A3'
$vmlocation     = 'West Europe'

# Next, create a credential for the VM
$Username = "$vmname\$vmusername"
$Password = ConvertTo-SecureString $vmpassword -AsPlainText -Force
$VMcred = new-object system.management.automation.PSCredential $username,$Password

# Get all Azure VM images
$imgs = get-AzureVMImage 

# Then get the latest image's image name
$img = $imgs| where label -eq $label
$imgnm = $img.imagename

# OK - do it and create the VM

New-AzureVMConfig -Name $vmname -Instance $vminstancesize -Image $imgnm `
| Add-AzureProvisioningConfig -Windows -AdminUser'tfl' -Pass $vmpassword `
| New-AzureVM -ServiceName 'psh1' -Location $vmlocation

Once the VM is created, you can then start and use it. Having said that, there are some pre-requisites, like setting up end points and enabling remote management inside the VM. I'll cover these topics in later blog posts.

del.icio.us Tags: Azure VM,PowerShell

Using Azure VMs for an Exchange DAG Witness Server

Last week, the Azure team released a cool new feature: support for a DAG Witness server inside an Azure VM. With the latest version of exchange, you can configure automatic data centre failover. But to do that, you new require three physical sites. However, according to Microsoft, many customers only had two physical sites deployed. This is where Azure comes in, since these clients can use Azure as their third physical site. This provides a cost-effective method for improving the overall availability and resiliency of their Exchange deployment, and requires no up front capital expenditure.

OF course, deployment of production Exchange servers is still unsupported on Azure virtual machines. But I can't help thinking that in due course we'll see this restriction changed.  MS kind of hint that by saying; "Stay tuned for future announcements about additional support for Azure deployment scenarios.".

Yet another cool scenario available to Azure customers today . For more details on how to do it, see the TechNet article at: http://technet.microsoft.com/en-us/library/dn903504(v=exchg.150).aspx.

del.icio.us Tags: Azure,Azure VM,Exchange. DAG,Exchange DAG Witness