Friday, October 27, 2017

OpenBSD 6.2 on Azure

I can confirm multiple successful installations of OpenBSD 6.2 (AMD64 GENERIC-MP) running in Azure. There's an official document by MS that I ran off of:
https://docs.microsoft.com/en-us/azure/virtual-machines/linux/create-upload-openbsd

Of course, there are some differences in my implementation, hence this post. To use an OpenBSD VM in Azure, you have to-
  • create it outside Azure (Windows10 Pro or any other Hyper-V capable system).
  • do some basic configuration work.
  • create the Azure resources of the VM.
  • push the VHD up to Azure.
  • Turn on and test connectivity to the VM.


Create the VM

Simply create a VM on Hyper-V. Caveats:
  • must be VHD, fixed-size. The drive can be small if you are savvy about attaching other larger drives to the system later.
  • must have some basic configuration work done on it or it won't be accessible
  • must have either DHCP on it, or the IP address the VM gets in the 'lab' must be the IP address it will have in Azure.

VM Creation Steps

  • Create the fixed-size vhd disk first (to allow the creation of a vhd and not a vhdx)
  • Create the VM - 2-core, 2048GB RAM, one nic. No console redirection.
  • Attach the created drive and the latest OpenBSD iso file as a DVD disc
  • Boot

OpenBSD Installer instructions

  • give it the name you want it to be in Azure
  • create an extra user aside from root.
  • set DNS to be globally accessible like 8.8.8.8
  • Don't use DHCP, instead designate the IP address you want to be used in Azure 
About IP addressing: it might be easier to have the LAN address you use re-created in Azure. This allows you to update the VM as much as you want in your environment prior to uploading it to Azure. Just remember that you will want to change the address later in Azure if you are going to have a site-to-site tunnel between that Azure environment and the one you created the VM in.

Post-Creation Configuration Steps

As root:
  • grab a pre-created doas.conf file and load it into /etc/. be sure it has the user accounted for in it so that you can ssh in as the user and then elevate to root.
  • it's best to also have pre-created .profile files for root and the other user to sit in their home directory, which can do things like color-highlight root's prompt, or account for the ftp server to install packages from.
  • install the following packages and make the following links:
pkg_add nano py-setuptools openssl git
ln -sf /usr/local/bin/python2.7 /usr/local/bin/python
ln -sf /usr/local/bin/python2.7-2to3 /usr/local/bin/2to3
ln -sf /usr/local/bin/python2.7-config /usr/local/bin/python-config
ln -sf /usr/local/bin/pydoc2.7  /usr/local/bin/pydoc

  • git the latest Azure agent, install and run it
git clone https://github.com/Azure/WALinuxAgent 
cd WALinuxAgent
python setup.py install
waagent -register-service
waagent -force

  • confirm the Azure agent is running 
ps auxw| grep waagent

Create the Azure Resources of the VM

When the VM is created it will take the specs you configured in VMM, like CPU Count and RAM. For the file system itself, however, some work needs to be done, namely a logical storage space needs to be created in Azure where the VM VHD file can be uploaded and subsequently used. The logic to Azure storage is Account=>Container=>blob (file).

Log into the target Azure Environment

IN this post, this is done via Azure CLI (2.0) on Windows on your local workstation (perhaps later I'll update with a straight-PS method). Confirm you're in the right environment by listing the resource group of the target environment you are provisioning into:

az group list --output table

Create the Storage Account

A storage account needs to be created and then a storage container, then the VHD can be uploaded to it and used. Here's the storage account creation command:

az storage account create --resource-group <rgrpname> --name <storageaccountname> --location <azure dc region> --sku Premium_LRS

This could look like this :

az storage account create --resource-group obsdrgrp --name obsd62storacc1 --location eastus --sku Premium_LRS

Create the Container

In ARM go to the storage account that was just created (in our example, obsd62storacc1) and copy one of the two keys in the Settings => Access keys page of the storage account. Then create the storage container with the following command that utilizes said key:

az storage container create --name <container name> --account-name <storageaccountname> --account-key <storage account key>


Implement the VM in Azure

We're in the action phase, uploading the VHD and creating the VM.

Upload the VHD

Issue the following the command to push the VHD (you shut down the VM, right?) up to Azure in the storage container you just created:

az storage blob upload --container-name <container name> --file <full-path-filename> --name <name you want for VHD in Azure> --account-name <storageaccountname> --account-key <storage account key>

Be sure to enclose the local path of the VHD in double-quotes, especially if the path includes directories with spaces in their labeling.

Create the VM in Azure

This is the final command to issue!
az vm create --resource-group <rgrpname> --name <VM name> --image "https://<storageaccountname>.blob.core.windows.net/<container name>/<VHD name in Azure>" --use-unmanaged-disk --os-type linux --admin-username <created user> --generate-ssh-keys

I've had the command 'fail' due to a timeout, seen it as a failure in ARM, and then restarted the VM and it was fine. Yep. In fact, I think it's supposed to fail if you follow this method because of the IP addressing that needs to be wonked in this next step.

Wonk the IP addressing

You may have stipulated the address in the VM, but Azure doesn't care, it will assign it a random address from the first subnet in the VNET this is VM is being provisioned into. In the environment I based this post on, this was a pain. I had to-

  • Change the base subnet the VM nic was looking at, and wait for a save.
  • Change the IP address to 'static', then to the address configured in the VM itself.

While this may seem like a pain, it well yeah, it is... this imho is better than Azure DHCP. Perhaps there's some mac-address reservation capability, but as of this writing I hadn't run into it, and I prefer actual static addressing anyway. I suspect many OBSD users do as well. Here's one little bonus I'll include for your troubles- in the NSG created for the VM, if you create an inbound allow-all policy, you'll actually be able to ping your VM. That's a bonus in Azure territory, as you can't do that with Windows VM's in Azure.

Connect to the VM

Now it's time to test connectivity to the VM and get on with your life. We'll use Putty on Windows to accomplish this- assumedly from the same workstation you created and uploaded the VM from. If you did not, then you'll need to get the keys that were created in the last command and use them where you will be using Putty from. First let's see what public IP address the VM got so we can use it to SSH to :

az vm list-ip-addresses --resource-group <rgrpname> --name <VM name>

Convert the Key for Putty

Unless you already have it, download and then run puttygen. In the File tab, select "Load private key". There were two keys generated in the Windows User .ssh directory that were created, id_rsa and id_rsa.pub. You want to select id_rsa. It's emphatic about your success or failure to find the right file.

Upon success, on the bottom-right of the menu, choose "Save private key", ensuring it was set to "RSA" key type and "2048" bits. Give it whatever name you want, but naming convention adherence is something I've never taken lightly :)

Use Putty to connect to the VM 

In the putty configuration for this VM connection, under Connection => SSH => Auth, hit the browse button on the right-side and select the key file you generated with puttygen. Also under Connection => Data, put in the username that was created in the VM prior to uploading it to Azure. 

That 'should' be all it takes to get in! You won't even need the user's password, it should authenticate via the key and you should be on your way! Let me know if this works for you, or if not, why!

Thanks for reading!