Azure Top-up without credit card How to Connect to Azure VM via SSH

Azure Account / 2026-05-16 21:49:30

{ "description": "Want to SSH into an Azure Virtual Machine without losing your mind (or your keys)? This guide walks you through everything: preparing your VM and networking, generating or locating an SSH key pair, configuring Azure-side settings, ensuring the NSG allows SSH traffic, and then connecting from macOS, Linux, or Windows. You’ll learn how to troubleshoot the most common problems like authentication failures, firewall blocks, wrong usernames, and “connection timed out” mysteries—plus a few practical tips so your next login is smooth and boring.", "content": "

Introduction: The Great SSH Quest (a.k.a. “Why won’t it connect?”)

Connecting to an Azure VM via SSH sounds straightforward, and in a calm universe it is. In our universe, you’ll inevitably meet at least one of these villains: the Network Security Group (NSG) that silently blocks traffic, the username that’s correct in your head but incorrect in real life, the SSH key that you generated for a different machine three laptops ago, and the ever-popular “Connection timed out” message that provides all the emotional support of a dead hamster.

This article will guide you step-by-step through connecting to an Azure Virtual Machine using SSH. We’ll cover planning, prerequisites, key generation, Azure configuration, the actual SSH command, and troubleshooting. If you follow along, you’ll end up with a working connection and the quiet satisfaction of someone who has successfully tamed networking gremlins.

\n\n

What You Need Before You Start

Before you attempt to SSH into your VM, gather the essentials. Think of it like packing for a trip, except the trip is “into your own server” and the luggage is “keys and IP addresses.”

\n\n

1) A running Azure VM

Your VM must exist and be running. Sounds obvious, but it’s worth checking. If the VM is stopped (or still deploying), SSH will fail. Azure will happily let you try anyway, because failure is the cloud’s love language.

\n\n

2) The VM’s public IP address

To SSH from your local machine, you typically need a public IP address. Some setups use a bastion host or private networking, but the classic approach is: public IP plus port 22. You can find the public IP in the VM’s “Networking” section in the Azure portal, or via CLI.

If you don’t have a public IP, you may need a different connection strategy (like Azure Bastion, VPN, or a jump host). The rest of this guide focuses on the common public-IP scenario.

\n\n

Azure Top-up without credit card 3) SSH credentials

Azure supports password authentication for some configurations, but the modern, sane choice is SSH key authentication. The good news: once you set it up, you can connect quickly and reliably. The bad news: if your keys don’t match or aren’t authorized, SSH will reject you as if you’re trying to enter a nightclub with an expired invitation.

\n\n

Azure Top-up without credit card Decide Which Authentication Method You’ll Use

There are two primary SSH authentication routes:

\n\n

Option A: SSH key authentication (recommended)

You generate a key pair locally (private key stays on your machine, public key goes into Azure). Azure then allows login using the corresponding private key. This is the default best practice and the option you should aim for unless you have a specific reason not to.

\n\n

Option B: Password authentication (works, but be cautious)

If your VM is configured to allow password SSH logins, you can connect with a username and password. However, password authentication is generally less secure than SSH keys and often discouraged. In many secure environments, it’s disabled entirely.

If you’re just getting started, choose SSH keys. Your future self will thank you and also complain less.

\n\n

Create or Obtain an SSH Key Pair

If you already have an SSH key pair you trust, you can skip this section. Otherwise, here’s how to generate one.

\n\n

Generating an SSH key on macOS or Linux

Open your terminal and run something like this (adjust the email/comment if you want):

ssh-keygen -t ed25519 -C \"[email protected]\" -f ~/.ssh/azure_vm_ed25519

When prompted, you may set a passphrase. If you leave it empty, the key won’t be encrypted with a passphrase, which can be convenient but also increases risk if your laptop is compromised. A passphrase is like seatbelts: slightly annoying, very worth it.

This command creates two files:

Private key: ~/.ssh/azure_vm_ed25519
Public key: ~/.ssh/azure_vm_ed25519.pub

\n\n

Generating an SSH key on Windows

If you have Windows with OpenSSH installed (common on modern Windows 10/11), you can use PowerShell:

ssh-keygen -t ed25519 -C \"[email protected]\" -f $env:USERPROFILE/.ssh/azure_vm_ed25519

Azure Top-up without credit card You’ll get:

Private key: %USERPROFILE%\\.ssh\\azure_vm_ed25519
Public key: %USERPROFILE%\\.ssh\\azure_vm_ed25519.pub

If you don’t have OpenSSH, install it or use a tool like Git Bash. The key idea is the same: you need a private key locally and a public key you can copy into Azure.

\n\n

Copy the public key content

Open the .pub file and copy the entire line(s) starting with ssh-ed25519 (or ssh-rsa if you chose RSA). This full string must be placed in the Azure VM configuration so it knows which keys to authorize.

On macOS/Linux:

cat ~/.ssh/azure_vm_ed25519.pub

On Windows PowerShell:

type $env:USERPROFILE\.ssh\azure_vm_ed25519.pub

\n\n

Set Up the VM in Azure for SSH Access

Azure Top-up without credit card Azure lets you configure SSH access in multiple ways depending on how you create the VM. The most common: when you create a Linux VM, you specify an SSH public key during provisioning.

\n\n

When creating a VM: add your SSH public key

During VM creation in the Azure portal, look for a field like “Authentication type” or “SSH public key.” Choose “SSH public key” and paste the public key content.

If you already created the VM without a key, don’t panic. You can still fix SSH access by adding authorized keys later, assuming the VM is reachable via some other method (like an Azure recovery console) or that the VM has another authentication path. But the cleanest setup is to add the key at creation time.

\n\n

Confirm you’re using a Linux VM

SSH is primarily for Linux and Unix-like systems. If you’re trying to SSH into a Windows VM, you’ll need a different approach (like enabling OpenSSH server on Windows and using the appropriate configuration). Since the title is “How to Connect to Azure VM via SSH,” we’ll assume a Linux VM.

\n\n

Check the Azure Network Security Group (NSG)

The NSG is often the reason you get stuck. Azure can be very polite while also preventing connections.

SSH typically uses port 22. You need an inbound rule that allows your source IP (or a broader range, if appropriate) to connect to port 22 on the VM.

\n\n

Find the NSG associated with your VM

In the Azure portal, open the VM, then check “Networking.” Look for an associated Network Security Group. The NSG contains inbound rules.

\n\n

Add an inbound rule for SSH

In the NSG “Inbound security rules,” add a rule such as:

Protocol: TCP
Destination port ranges: 22
Source: your IP address (recommended) or a range
Azure Top-up without credit card Action: Allow
Priority: something higher than deny rules (lower number means higher priority in Azure)

If you don’t know your public IP, you can find it from your local machine’s “what is my IP” website, or using a cloud CLI tool. Just be careful: sometimes the IP changes if you’re on a dynamic network.

\n\n

Wait for changes to apply

Azure networking changes usually propagate quickly, but if you still get timeouts right after adding the rule, give it a minute. The cloud isn’t slow; it’s just deeply committed to suspense.

\n\n

Figure Out the Correct Username for the VM

Your SSH command must include the correct username. Azure images often use default usernames like:

ubuntu for Ubuntu images
azureuser or a custom username you selected during provisioning
adminuser depending on configuration

The best source of truth is what you selected when creating the VM. If you’re not sure, check the VM’s creation parameters or OS details in the Azure portal.

Azure Top-up without credit card Using the wrong username can lead to errors like “Permission denied (publickey).” The server is not judging your soul, it’s just rejecting your login attempt for the wrong account.

\n\n

Connect to the Azure VM Using SSH

Now for the moment of truth: the actual SSH connection.

\n\n

Basic SSH command

From your local machine, run:

ssh <username>@<vm-public-ip>

Example:

ssh [email protected]

\n\n

If your key file isn’t the default

SSH looks for default keys in ~/.ssh (macOS/Linux) or ~/.ssh (Windows with OpenSSH), like id_ed25519 or id_rsa. If you generated a key with a custom filename (like azure_vm_ed25519), you must specify it.

Example (macOS/Linux):

ssh -i ~/.ssh/azure_vm_ed25519 [email protected]

Example (Windows PowerShell):

ssh -i $env:USERPROFILE/.ssh/azure_vm_ed25519 [email protected]

Note: Some environments require the -i path to be formatted correctly for the shell you’re using.

\n\n

Accept the host key fingerprint (first connection)

The first time you connect, you’ll likely see a message like:

“The authenticity of host ... can’t be established.”

This is normal. It’s SSH asking if you want to trust this server identity. If you’re confident you’re connecting to the correct VM, type yes. SSH then remembers the host key for future connections.

Be cautious if you see warnings after you previously connected—host key changes can indicate a VM replacement or misrouting.

\n\n

Improve Usability with an SSH Config File

If you’ll connect often, you can store your connection details in an SSH config file so you don’t have to type the full command every time. This is like labeling your keys so you don’t have to guess which one fits.

\n\n

macOS/Linux: edit ~/.ssh/config

nano ~/.ssh/config

Add something like:

Host azure-myvm\n  HostName 203.0.113.42\n  User ubuntu\n  IdentityFile ~/.ssh/azure_vm_ed25519\n  IdentitiesOnly yes

Now connect with:

ssh azure-myvm

\n\n

Azure Top-up without credit card Windows: edit %USERPROFILE%\\.ssh\\config

notepad $env:USERPROFILE\.ssh\config

Then use a similar Host block. Paths may need adjusting depending on how your shell interprets them.

\n\n

Troubleshooting: The Most Common SSH Problems

When SSH fails, you’ll typically get one of a few error types. Each points to a different culprit. Let’s decode the messages like a networking detective story.

\n\n

Problem 1: “Connection timed out”

This usually means network connectivity is blocked. Possible causes:

NSG inbound rule doesn’t allow port 22 from your source IP
The VM has no public IP or the public IP is incorrect
Port 22 is blocked by a firewall in front of the VM (less common but possible)
Wrong network security rule priority prevents your allow rule from taking effect

What to do:

Double-check the VM’s public IP
Verify NSG inbound rule for TCP 22
If you used a restricted source IP, confirm your current public IP matches

\n\n

Problem 2: “No route to host”

Less common, but it can indicate routing issues. This might happen if the IP is wrong, the VM is gone, or your network environment blocks outbound traffic.

What to do:

Confirm the IP address is correct
Try from a different network (e.g., mobile hotspot) to rule out corporate firewall interference

\n\n

Problem 3: “Permission denied (publickey)”

This means your connection reaches the VM, but authentication failed. Usually caused by:

The private key you’re using doesn’t match the public key installed in the VM
You specified the wrong -i key file
Your username is incorrect
Key is present but not in the right user’s authorized_keys

What to do:

Make sure you used the correct username
Ensure you passed the correct private key with -i
If your SSH config uses IdentityFile, confirm it matches the key pair you uploaded

If you can access the VM via Azure serial console or another method, you can check that the public key is in the correct home directory’s ~/.ssh/authorized_keys.

\n\n

Problem 4: “Bad owner or permissions on ~/.ssh/authorized_keys”

SSH is extremely picky about file permissions. If authorized_keys has overly permissive permissions, SSH may refuse to use it.

Common permission expectations for Linux are:

~/.ssh should be 700
~/.ssh/authorized_keys should be 600

If you have access to the VM, you can fix permissions. If you don’t, you’ll need some alternative access method to repair it.

\n\n

Problem 5: “Connection refused”

This typically means the TCP handshake worked but the service isn’t listening on port 22. Causes include:

SSH server (sshd) isn’t installed
sshd is disabled or crashed
Port 22 was changed in the VM configuration

What to do:

Check VM OS configuration
Confirm sshd is running
Look for custom SSH port configurations

\n\n

Problem 6: “Host key verification failed”

This suggests the server’s host key changed compared to what SSH previously recorded. Could happen if the VM was reinstalled or replaced, or if you’re connecting to a different machine with the same IP (rare but not impossible in some environments).

What to do:

Verify you’re connecting to the correct VM
If you intentionally rebuilt the VM, remove the old host key entry in your local known_hosts and reconnect

Be careful: don’t blindly accept host key changes if you didn’t expect them. SSH is trying to protect you, not annoy you.

\n\n

Security Tips (Because SSH Is Powerful, Not Playful)

SSH gives you remote control. That’s awesome—also it’s exactly why you should configure it thoughtfully.

\n\n

Use a restricted NSG source IP

If you can, restrict the NSG inbound rule to your home/work public IP rather than allowing from everywhere. Allowing SSH from 0.0.0.0/0 is basically saying “Door unlocked, please come steal my server’s soul.”

\n\n

Prefer key authentication and disable password login

If your VM is configured for SSH keys, keep it that way. Password-based SSH invites brute-force attempts. Keys aren’t magic, but they are far harder to guess than passwords humans invent at 2 a.m.

\n\n

Consider changing the SSH port (optional)

Changing the SSH port (from 22 to something else) can reduce noise from opportunistic scans. However, it’s not a substitute for firewall rules and proper authentication. If you do change the port, remember to update NSG rules and your SSH command.

\n\n

Log and monitor

Keep an eye on authentication logs. If you’re in a mature environment, connect this to your SIEM or monitoring tools. If you’re in a small setup, at least pay attention to repeated login failures. Your server has feelings; it just expresses them through logs.

\n\n

Example Walkthrough: From “VM Created” to “Logged In”

Let’s stitch it all together with a realistic scenario.

\n\n

Step 1: Create a Linux VM

During creation, set authentication to “SSH public key.” Paste your public key from ~/.ssh/azure_vm_ed25519.pub. Also choose a username like ubuntu.

\n\n

Step 2: Ensure the VM has a public IP

Confirm it. If your VM is created without a public IP, you’ll need to attach one or use a different connectivity method.

\n\n

Step 3: Confirm NSG allows port 22

In the NSG inbound rules, add or verify a rule that allows inbound TCP 22 from your IP.

\n\n

Step 4: Connect from your machine

Use:

ssh -i ~/.ssh/azure_vm_ed25519 [email protected]

On first connection, accept the host key prompt.

\n\n

Step 5: Celebrate quietly

If you see your shell prompt and can run commands, you’re in. If not, refer to the troubleshooting section. Remember: “Connection timed out” is a networking problem; “Permission denied” is an authentication problem. SSH errors are like clues, not random insults.

\n\n

Connecting with SSH Using Azure-Specific Notes

Azure sometimes introduces details that are worth knowing, even if SSH itself is the same everywhere.

\n\n

Use the correct public IP

Azure public IPs can change if you delete and recreate resources or if you use certain dynamic IP configurations. Make sure the IP you’re connecting to belongs to the VM you think it does.

\n\n

Be mindful of custom images

If you’re using a custom VM image, the default username and SSH configuration might differ from typical marketplace images. For example, some images might not use ubuntu as the username. The username mismatch is the classic “I swear I typed the right thing” problem.

\n\n

NSG applies at the subnet or NIC level

Depending on your network setup, NSG rules may attach at different scopes: the subnet or the network interface. If you have multiple NSGs, rules can combine in ways that make you feel like you’re fighting an octopus made of firewall rules. The key point: check the NSG that actually applies to your VM’s NIC.

\n\n

Common SSH Command Variations

Here are a few useful variants people often need.

\n\n

Use verbose mode for debugging

If something fails, verbose mode can reveal where SSH is getting stuck.

ssh -v [email protected]

If you want more detail:

ssh -vvv [email protected]

Look for lines mentioning the identity file, authentication attempts, and connection timing.

\n\n

Specify the remote command directly

You can run a command without entering an interactive shell:

ssh [email protected] \"uname -a\"

\n\n

Specify a non-default SSH port

If your VM uses a port other than 22:

ssh -p 2222 [email protected]

And remember: the NSG must allow that port too.

\n\n

When You Can’t Use Public SSH: Alternative Approaches

Sometimes you don’t want (or can’t) open port 22 to the internet. That’s a responsible choice. If so, consider:

Azure Bastion: provides browser-based SSH without exposing public SSH directly
VPN or private link: connect your network to Azure privately
Jump host: use an intermediate machine you trust
Private IP + internal routing: if your client network can reach it

The core SSH concept remains similar, but the path to reach the VM changes. If you tell me your network approach (public IP, Bastion, VPN, private subnet), I can tailor the exact steps.

\n\n

Quick Checklist: Are You Ready to SSH?

Use this checklist when you want the fastest path to success:

VM is running
You have the correct VM public IP
Azure Top-up without credit card NSG allows inbound TCP 22 (or your chosen port) from your source IP
Username is correct
Private key matches the public key in the VM’s authorized_keys
Your SSH command includes -i if using a non-default key path
SSH host key warnings are expected (first connect) and not suspicious (later connects)

\n\n

Conclusion: Your Azure VM Is Now Your Typewriter

Once your SSH connection works, your Azure VM becomes a place you can manage quickly: install packages, edit configs, run services, and do all the administrative magic that makes cloud infrastructure feel less like a mysterious black box and more like a helpful machine you can talk to.

Remember: network errors (timeouts/refused) are usually NSG or service/port issues. Authentication errors (permission denied) are usually key/username mismatches or permissions on authorized_keys. If you treat SSH like a logic puzzle instead of a cursed ritual, you’ll solve it fast.

Go forth, connect confidently, and may your next SSH attempt be boring. Boring is the highest compliment in infrastructure.

" }