When your Ubuntu VM can SSH but workloads fail on DNS resolution, package installs, or API callbacks, these read-only diagnostics generate a structured network report to identify the root cause.
This guide exists as a tested, machine-readable recipe in the Massed Compute MCP. Skip the manual steps and let an AI agent handle the network diagnostics automatically. Learn more about MCP automation.
Network connectivity issues are among the most frustrating problems in cloud computing. Your VM responds to SSH, but Hugging Face downloads time out, pip installations fail, or API callbacks never reach their destination. This guide provides systematic read-only diagnostics to identify DNS, routing, egress HTTPS, and firewall issues without changing any configurations.
The diagnostics generate a structured report with clear sections for DNS resolution, egress connectivity, listening ports, and firewall snapshots. Unlike trial-and-error troubleshooting, this approach gives you the complete network picture before making any changes.
| Component | Purpose | Notes |
|---|---|---|
| Ubuntu 24.04 | Base operating system | LTS with modern networking stack |
| SSH diagnostics | Remote network checks | No package installs required |
| DNS resolution | Name lookup testing | Tests both system and custom resolvers |
| HTTPS egress | Outbound connectivity | Tests Hugging Face, PyPI, GitHub |
| UFW/netfilter | Firewall snapshot | Read-only rule inspection |
| Resource | Minimum | Recommended |
|---|---|---|
| vCPUs | 2 cores | 4+ cores |
| RAM | 4 GB | 8+ GB |
| Storage | 20 GB | 50+ GB |
| Network | SSH access | Public IP assigned |
| OS | Ubuntu 24.04 | Fresh installation |
Massed Compute VM Pricing
Pricing data fetched July 15, 2026. No matching SKUs found for the minimum requirements. Check live pricing for current availability and rates.
Step-by-Step Network Diagnostics
Verify VM Access
Confirm your VM is running and SSH-accessible before starting network diagnostics.
ssh -i ~/.ssh/your_key -p 22 ubuntu@YOUR_VM_IP 'echo "VM access confirmed"'
You should see “VM access confirmed” printed to confirm basic connectivity.
DNS Resolution Test
Test both system DNS and common public resolvers to identify DNS issues.
ssh -i ~/.ssh/your_key ubuntu@YOUR_VM_IP 'echo "=== DNS Resolution ===" &&
nslookup google.com &&
nslookup huggingface.co &&
dig @8.8.8.8 pypi.org &&
cat /etc/resolv.conf'
Look for failed lookups or timeout errors that indicate DNS problems.
Egress HTTPS Connectivity
Test outbound HTTPS connections to common package repositories and APIs.
ssh -i ~/.ssh/your_key ubuntu@YOUR_VM_IP 'echo "=== Egress HTTPS ===" &&
curl -I --connect-timeout 10 https://huggingface.co &&
curl -I --connect-timeout 10 https://pypi.org &&
curl -I --connect-timeout 10 https://github.com &&
curl -I --connect-timeout 10 https://api.github.com'
Successful responses show HTTP/2 200 or similar status codes. Connection timeouts indicate egress blocking.
Network Interface Status
Check network interface configuration and routing table.
ssh -i ~/.ssh/your_key ubuntu@YOUR_VM_IP 'echo "=== Network Interfaces ===" &&
ip addr show &&
echo "=== Routing Table ===" &&
ip route show &&
echo "=== Default Gateway ===" &&
ping -c 3 $(ip route | grep default | awk "{print \$3}")'
Verify your VM has a valid IP, default route, and can reach the gateway.
Listening Ports Audit
Document which services are listening on which ports.
ssh -i ~/.ssh/your_key ubuntu@YOUR_VM_IP 'echo "=== Listening Ports ===" &&
ss -tlnp &&
echo "=== Process Network Usage ===" &&
netstat -tulnp | head -20'
This helps identify port conflicts or unexpected services.
Firewall Snapshot
Capture current firewall rules without requiring sudo access.
ssh -i ~/.ssh/your_key ubuntu@YOUR_VM_IP 'echo "=== Firewall Status ===" &&
ufw status 2>/dev/null || echo "UFW status requires sudo" &&
echo "=== iptables (if accessible) ===" &&
iptables -L 2>/dev/null || echo "iptables requires sudo" &&
echo "VM_NETWORK_CONNECTIVITY_OK"'
The final token confirms the diagnostic completed successfully.
Troubleshooting Common Issues
DNS Resolution Failures
If nslookup or dig commands fail, check your /etc/resolv.conf file. Many cloud providers use their own DNS servers. Try switching to public DNS temporarily:
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf
Egress HTTPS Blocked
If curl commands timeout or fail with connection errors, your cloud provider may have egress filtering. Check your security group rules and firewall policies. Some providers require explicit outbound rules for HTTPS traffic.
SSH Key Rejection
If SSH connections fail with “Permission denied (publickey)”, remove the old host key and verify your private key:
ssh-keygen -R YOUR_VM_IP
ssh-add ~/.ssh/your_key
Network Interface Down
If ip addr show shows your interface as DOWN, the network configuration may need rebuilding. This typically requires a VM restart or manual interface configuration.
Skip All of This: Deploy with an AI Agent
This guide exists as a tested, machine-readable recipe in the Massed Compute MCP. Instead of running commands manually, configure an AI agent to handle the network diagnostics automatically.
Add this configuration to your MCP client:
{
"mcpServers": {
"massed-compute": {
"type": "http",
"url": "https://vm.massedcompute.com/api/mcp",
"headers": { "Authorization": "Bearer MC_TOKEN" }
}
}
}
Then say:
The agent matches your request against the recipe catalog (tested June 10, 2026), connects to your running VM, executes the diagnostic commands above in sequence, and reports back with the structured network analysis. If any step fails, the agent stops and provides the exact error output for troubleshooting.
Quick Setup Guide
For rapid network diagnostics deployment:
- Ensure your VM is running and SSH-accessible
- Have your private key file path ready
- Note any specific URLs or services that are failing
- Run the diagnostic commands in sequence
- Look for the
VM_NETWORK_CONNECTIVITY_OKsuccess token - Analyze the structured output for DNS, egress, and firewall issues
The entire diagnostic process takes 5-10 minutes and requires no package installations or configuration changes on your VM.
Frequently Asked Questions
1. Do these diagnostics require sudo access?
Most diagnostic commands run without sudo. Firewall status checks may show limited information without elevated privileges, but the core network tests (DNS, egress, routing) work with standard user access.
2. Will this change my VM’s network configuration?
No, these are read-only diagnostics. The commands only gather information about your current network state without modifying DNS settings, firewall rules, or routing tables.
3. What if my VM can’t reach the diagnostic URLs?
That’s exactly what we’re trying to identify. Failed connections to test URLs indicate egress filtering, DNS issues, or firewall blocking that you can then address with your cloud provider’s network security settings.
4. Can I customize which URLs to test for egress?
Yes, replace the default URLs (huggingface.co, pypi.org, github.com) with your specific failing endpoints. The diagnostic pattern works for any HTTPS destination.
5. How do I interpret the network diagnostic output?
Look for timeouts in DNS lookups, connection refused errors in HTTPS tests, missing default routes in the routing table, and unexpected listening services in the port audit. Each section provides specific clues about network problems.











