The SSC Science Program offers a managed VMs, for those that don't need a full subscription.
VMs are automatically patched, and not exposed directly to the Internet, with all inbound traffic being directed via a shared load-balancer, or a Bastion.
The ConsoleUtility a small helper tool for the Azure CLI bastion client, which just needs to a VM name, and it does the rest.
It's possible to run the tool in a number of ways, but the two most obvious are with Docker, or native binaries.
The paramters/flags are the same regardless of which way you do it.
Usage of bin/linux/spconsoleutility:
-h Shows help
-ports The 'local:remote' port mapping when using '-protocol tunnel'
-protocol The Protocol to use when connecting to the VM (ssh|rdp|tunnel) (default "ssh")
-v Shows version
-vm Name of the VM you want to connect to
You can only use rdp protocol on Windows, as it leverages the Window Remote Destkop client mstsc.exe. All other options are platform agnostic.
There's a docker image of the tool, which has all the required underlying commands and extensions pre-installed.
Here are a few ways to run it.
Throwaway container
Connect via SSH requiring authentication every time you want to connect to the VM. Is arguably the simplest form.
docker run -it --rm sscsp.azurecr.io/spconsoleutility -vm <VMName>
Same but tunnelling port 3306.
docker run -it --rm -p 3306:3306 sscsp.azurecr.io/spconsoleutility -vm <VMName> -protocol tunnel -ports 3306:3306
Named volume for Azure session storage
This one is probably the one I'd recommend for most use cases. It saves your session details, but doesn't require setting up a place to store them, and then remembering where they are. Docker automatically creates the named volume, and mounts for you. Easy peasy.
docker run -it --rm -v spconsoleutility:/root/.azure sscsp.azurecr.io/spconsoleutility -vm <VMName> -protocol rdp
The container still gets throwaway after every use (thanks to the --rm paramter), but all Azure session information is captured for re-use.
Bind-mounted volume for Azure session storage
This one is almost identical to above, but instead uses a bind-mounted volume.
docker run -it --rm -v /Path/To/Session/Storage/Folder:/root/.azure sscsp.azurecr.io/spconsoleutility -vm <VMName>
The folder must already exist before you start the container, but the upside is that you could re-use existing session details if you're doing other things in the Science Program cloud.
Persistant container for a particular VM
All the previous examples assumed that you might want to connect to a number of different VMs, providing them to the command as you go.
However it's possible to create one container per VM, which can easily be started, or aliased on the system for ease of use.
For example, to create and start a container that tunnels MySQL from your system to the VM, you'd run the following:
docker run -p 3306:306 --name <VMName>_mysql sscsp.azurecr.io/spconsoleutility -vm <VMName> -protocol tunnel -ports 3306:3306
Subsequent uses would simply require running:
docker start <VMName>_mysql
In addition to using the container, it's also possible to directly use the binary on Linux, Windows, and Mac.
The only pre-requisite is having the Azure CLI installed on your system.
Get the latest binaries here:
| Platform | Binary |
|---|---|
| Linux | spconsoleutility |
| Windows | spconsoleutility.exe |
| Mac | spconsoleutility |
If you have ideas for how to make this tool better, please us know.