SRJahirTech

Linux Tutorial — Part 6: Networking Commands

By Suraj Ahir December 05, 2025 6 min read

In cloud environments and DevOps work, understanding Linux networking is essential. You need to configure network interfaces, diagnose connectivity problems, check open ports, test DNS resolution, and manage firewall rules — all from the command line. This part covers the networking tools you will use regularly in real operations work.

Network Interface Management

ip addr                       # Show all interfaces and IPs
ip addr show eth0             # Specific interface details
ip link                       # Show interface status (up/down)
ip link set eth0 up           # Bring interface up
ip route                      # Show routing table
ip route show default         # Default gateway

Connectivity Testing

ping google.com               # Test basic connectivity
ping -c 4 192.168.1.1         # Ping 4 times only
traceroute google.com         # Trace network path
tracepath srjahir.in          # Path without root privileges
mtr google.com                # Continuous traceroute (interactive)

DNS Lookups

nslookup srjahir.in           # Basic DNS lookup
dig srjahir.in                # Detailed DNS query
dig srjahir.in MX             # Mail server records
dig @8.8.8.8 srjahir.in       # Query specific DNS server
host srjahir.in               # Quick DNS lookup
cat /etc/resolv.conf          # Configured DNS servers

Port and Connection Checking

ss -tulnp                     # Open ports and listening services
netstat -tulnp                # Alternative (older systems)
lsof -i :80                   # What is using port 80
lsof -i :443                  # What is using HTTPS port
ss -s                         # Connection statistics summary

HTTP Testing with curl

curl https://srjahir.in                    # Fetch page
curl -I https://srjahir.in                 # Headers only
curl -v https://srjahir.in                 # Verbose — full request/response
curl -o output.html https://srjahir.in     # Save to file
curl -X POST -d '{"key":"value"}'   -H "Content-Type: application/json"   https://api.example.com/endpoint         # POST request
curl -u user:pass https://secure-api.com   # Basic auth

Firewall with ufw and iptables

sudo ufw status               # Firewall status
sudo ufw enable               # Enable firewall
sudo ufw allow 22             # Allow SSH
sudo ufw allow 80             # Allow HTTP
sudo ufw allow 443            # Allow HTTPS
sudo ufw deny 3306            # Block MySQL from outside
sudo ufw allow from 192.168.1.0/24  # Allow from subnet only
sudo ufw status numbered      # Show rules with numbers
sudo ufw delete 3             # Delete rule number 3

SSH Configuration and Tunneling

ssh -L 8080:localhost:80 user@remote     # Local port forward
ssh -R 9090:localhost:3000 user@remote   # Remote port forward
ssh -N -f -L 5432:db-host:5432 bastion  # Background tunnel

# SSH config file (~/.ssh/config)
Host production
  HostName 54.1.2.3
  User ubuntu
  IdentityFile ~/.ssh/prod.pem
  Port 22

# Then just: ssh production

Network File Transfer

scp file.txt user@remote:/path/        # Secure copy to remote
scp user@remote:/path/file.txt .       # Copy from remote
rsync -avz --progress local/ remote:path/  # Sync with progress
wget https://example.com/file.tar.gz   # Download file

Practical Networking Workflow

When you encounter a connectivity problem in production, having a systematic approach saves time. Start with ping to check basic reachability. If ping fails, check if the interface is up with ip addr. If the interface is up, check the routing table. If routing looks right, check DNS with dig. If DNS resolves but the service is unreachable, check if the port is open with ss and if the firewall is blocking with ufw status. This top-down systematic approach resolves most network issues quickly.

In Part 7, we will cover shell scripting — combining commands into automated scripts that do real work without manual intervention.

SSH Configuration and Key Management

SSH key authentication — using a public-private key pair rather than a password — is more secure and more convenient once configured. Generate an SSH key pair with ssh-keygen -t ed25519 -C "your_comment". The private key stays on your machine in ~/.ssh/. The public key is placed on the server in ~/.ssh/authorized_keys. The ~/.ssh/config file on your local machine can define shortcuts for frequently accessed servers:

Host myserver
    HostName 203.0.113.10
    User ubuntu
    IdentityFile ~/.ssh/my_key
    Port 22

This allows ssh myserver instead of typing the full connection string every time. Always protect your private key — set permissions to 600 (chmod 600 ~/.ssh/id_ed25519) and never share it or commit it to version control.

Network Troubleshooting Workflow

When network connectivity fails, work through a systematic approach. First verify local config with ip addr and ip route. Test local network with ping to your gateway IP. Test internet connectivity with ping 8.8.8.8. If that works but hostnames fail, test DNS with dig google.com or nslookup google.com. If the host is reachable but a port is not responding, test with nc -zv hostname 80 or telnet hostname 80. Use traceroute hostname to trace where packets are being dropped. Use ss -tulnp to see all listening services on the local machine — useful for verifying that a service is actually bound to the expected port.

Practice Exercise

Use ss -tulnp to list all listening services. Identify three services by their port numbers. Use curl -I https://google.com to make an HTTP request and examine response headers. Practice the full troubleshooting workflow: check IP, check routing, ping gateway, ping internet IP, test DNS. If you have a cloud VM, set up SSH key authentication — copy your public key to ~/.ssh/authorized_keys on the server and verify passwordless login works before disabling password authentication.

Linux in Your Daily Engineering Practice

Linux command-line proficiency is not something you learn once and then stop improving. It is a skill that deepens continuously as you encounter new tools, new use cases, and new problems to solve. The engineers who are most effective at the command line did not become that way by reading comprehensive guides — they became that way by spending years solving real problems at the terminal, gradually accumulating a toolkit of commands, aliases, scripts, and muscle memory. The best approach is to use Linux for real work as much as possible, to look up better ways to do things you already do, and to make note of efficient patterns you observe in others' work. Over time, the terminal becomes faster than any GUI for the tasks you do repeatedly.