DEV Community: Emmanuel Iderima

Azure: SSH to a VM on Azure

Emmanuel Iderima — Thu, 17 Sep 2026 02:49:24 +0000

SSH allows for remote encrypted connection between a two computers (typically a client and server) using cryptography to authenticate and encrypt connection between the devices. In this guide, we would explore how to connect to a virtual machine created on microsoft azure using SSH.

A Brief Overview of SSH

Secure SHell (SSH) is a protocol on the application layer of the OSI model. It is used for remote encrypted connection between two devices. It uses asymmetric key cryptography techniques to safely create a shared key for both devices without needing to send the key across the network. It then uses the shared (symmetric) key for further encryption over the channel. SSH runs on TCP port 22 by default.

Creating a VM on Azure

Login to your azure portal and click on the "Create a Resource" option on the dashboard (you can also find that option on the navigation bar).

Now in the create resource page, select Virtual machine , you will be navigated to the Create Virtual Machine page. Enter the required information to create your vm. A few things to pay attention to in regards to this article, for the_ Authentication Type_ in the Administrator Account section, select SSH public key as the means to authenticate. Enter your vm username, generate a new key pair (except your need requires you to use an existing keypair), for the key type I recommend Ed25519 because it is faster and then enter your keypair name. Another important thing is the inbound port rule, make sure port 22 is open.

Once you're done with all your network, storage and other configurations, you can go ahead and create the vm.

Connecting to the virtual machine

When you created the vm, a key.pem file was downloaded into your computer, this will be used for authentication. First of all, move this file to the ~/.ssh folder (create one if it's not already there). Now change the the permissions of the key.pem file to give readonly access.

chmod 400 ~/.ssh/key.pem

Now all we need is the public IP address of our virtual machine, we can get it on our azure portal.

To connect to our cloud vm, we run this command on our teminal:

ssh -i ~/.ssh/key.pem testvm@102.113.114.200

In general, the syntax is:

ssh -i <path_to_key_file> <vm_name>@<vm_ip_addr>

Now since this is the first time connecting to the vm, we will get a message like this:

The authenticity of host '102.133.144.206 (102.133.144.206)' can't be established.
ED25519 key fingerprint is SHA256:bbZQo2Ph2ZV77Koob9iQT7i0G+oDNZVo9Q3fMg89T64.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? y
Please type 'yes', 'no' or the fingerprint: yes

What this means is we should verify the host (the vm) fingerprint before connecting. Now even though we just created the vm, we should still verify the returned fingerprint to make sure this response is actually from the vm. We need to make sure the figerprint on the server matches the one returned to us. We can do this by running this command on the vm through our azure portal.

ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub | awk '{print $2}'

To run a command on your vm through the azure portal, go to the vm dashboard, in the sidebar, navigate to operations, and click run command. In the current page, click run shell script and enter the command above.

Once the server fingerprint has been verified, proceed with the connection and now you are connected to your remote vm through ssh.

How DNS Works

Emmanuel Iderima — Mon, 03 Aug 2026 07:08:04 +0000

Every device on the internet is identified by it's unique IP address. An IP address is a group of four 8 bit numbers (IPv4) separated by dots (eg 192.168.1.1) or group of eight 16 bit numbers (IPv6) separated by a column (eg 2001:0db8:85a3:0000:0000:8a2e:0370:7334 ) that uniquely identifies a device on a network.

When you visit a website on the internet, you enter the site's domain name (eg example.com) on the browser, then an http request is made to the server hosting the site which then returns the requested data.

But since every device on the internet is identified by it's IP address and not a domain name, how does the browser know to locate the server with the requested site or data? It does this using the Domain Name System (DNS).

The Domain Name System simply put is a system used to translate human readable domain names to IP addresses that are used by computers and devices on the internet. In this article, we'll discuss:

How DNS works
Types of DNS servers and their functions
DNS records
And DNS caching

How DNS works

When a user enters a web address, the browser begins the DNS resolution process which is essentially the process of translating a web address (eg example.com) to an IP address. It first checks the browser DNS cache if the required DNS information is there. If the required information is in the cache, it resolves quickly and the webpage loads faster.

If the required DNS information is not in the cache, the browser makes a DNS query to a recursive resolver, which is typicaly ran by your network internet service provider or a public service like google's 8.8.8.8 or cloudflare's 1.1.1.1. This resolver then takes responsiblility of getting the DNS information from the right source. This include making a series of network requests to various DNS servers until either the required DNS information is found or there's a timeout.

Types of DNS Servers

Recursive Resolver (DNS recursor): A recursive resolver accepts DNS queries from clients (web browsers) and then acts a the middle man between the client and a DNS nameserver. It is the first stop for DNS queries on the network. It either responds with a cached data (if the required information is already in it's cache) or makes a request to a DNS root nameserver. The root name server responds with the IP address of the required TLD nameserver. The recursor then makes a request to the TLD server who then responds with the IP address of the required authoritative nameserver. Lastly (in most case) the recursor makes a request to the authoritative nameserver which responds with the required DNS information. It is called a recursive resolver because it takes responsibility of tracking a website IP address by making a series of requests to other servers until the required information is found. Some recursive resolvers include google's 8.8.8.8 and cloudflare's 1.1.1.1.
Root Nameserver: This is the first stop a recursive resolver makes for an uncached DNS query. The root nameserver accepts DNS query from a recursive resolver and responds by directing the recursive resolver to a TLD nameserver based on the extension of that domain (eg .com, .net, .org, etc). There are 13 different IP addresses that serves as DNS root nameservers (but much more physical servers) all managed by the Internet Corporation of Assigned Names and Numbers (ICANN).
Top Level Domain (TLD) Nameserver: A TLD nameserver maintains information on all domain names that share a common domain extension (eg .com). A .com TLD nameserver contains information on every website with a .com extension. A TLD nameserver accepts DNS query from a recursive resolver and responds by directing it to the correct authoritative nameserver for that domain.
Authoritative Nameserver: An authoritative nameserver maintains information specific to the domain it serves (eg example.com). It is usually the last stop for the recursive resolver's DNS lookup journey. It responds with a DNS A record which will contain the IP address of the requested server. In some cases though, it can respond with a CNAME record in which case, the recursive resolver restarts the resolution process for the domain name given in the CNAME record.

DNS Records

DNS records are instructons that live in the authoritative DNS servers and provide information about the domain including what IP address is associated with that domain and how to handle requests for that domain. Below is an inexhaustive list of some DNS record types:

DNS A Record: An A record maps the domain name to the actual IPv4 address of the server that hosts it. Many websites have only one A record though it is possible to have multiple A records pointing to different IP addresses each serving the same content, it is done as a means of round robin load balancing.
DNS AAAA Record: An AAAA record maps a domain to an IPv6 address (as opposed to the A record's IPv4 mapping).
CNAME Record: The CNAME (canonical name) record maps a domain name to another domain name rather than an IP address. This triggers a fresh DNS lookup chain to search for the server of the mapped domain. You might ask, why CNAME? In mordern cloud infrastructure, IP addresses are fluid (changing) but hostnames are permanent. If every service require an IP address via an A record, maintaining web applications on cloud infrastructure would be a nightmare because mordern platforms like AWS S3, vercel, heroku, etc continously route traffic through load balancers, auto-scaling groups and changing IP pools. If a server changes from 192.0.2.1 to 192.0.2.10, millions of users would have to manually update their DNS A records but with CNAME, when you route docs.example.com to example.s3.amazonaws.com, AWS can change the underlying server IP thousands of times a day and your link never breaks because it follows the hostname not the IP.

DNS Caching

DNS caching can help speed up the DNS lookup chain. It involves tempoarily storing the DNS records for some domain names closer to the requestng client to speed up DNS query. DNS records can be cached in different locations each of which will store the DNS record for a certain amount of time determined by the time to live (TTL).

Web browsers are the first layer of DNS record cache from the client. When a request is made for a DNS record, the browser cache is the first location checked for the requested record. In chrome, you can view the DNS cache here at chrome://net-internals/#dns.

If the required information isn't in the browser cache, the next stop before making any network request is the operating system DNS cache. The process that handles this is called a stub resolver. The DNS stub resolver uses names and addresses of the host file (a special text file containing DNS entries) to respond to application name resoluton requests. You can find the host file on /etc/hosts on linux.

The recursive resolver is the last caching layer in the DNS lookup chain. It not only caches DNS records for websites (ie the actual A record) but also the TLD server for various domain names.