# View all IP addresses and network interfaces (the modern way)
# Each interface has a name (eth0, ens33, wlan0), state (UP/DOWN), and addresses
ip addr
# Key things to look for:
# - "state UP" means the interface is active
# - "inet 192.168.1.50/24" is the IPv4 address and subnet mask
# - "link/ether aa:bb:cc:dd:ee:ff" is the MAC address

# The older ifconfig command still works but is deprecated on modern systems
ifconfig

# View just the IP addresses in a compact format
ip -brief addr

# View the routing table -- how traffic finds its way to destinations
# The "default via" line is your gateway (the exit door to the internet)
ip route
# Example output:
# default via 192.168.1.1 dev eth0   <-- All internet traffic goes through this gateway
# 192.168.1.0/24 dev eth0            <-- Local subnet traffic stays on this interface
# 10.0.0.0/8 via 10.0.0.1 dev tun0  <-- VPN traffic routes through the tunnel

# Step 1: Can you reach the host at all? (ICMP ping)
ping google.com           # Runs forever until Ctrl+C
ping -c 4 8.8.8.8        # Send exactly 4 packets and stop
# If ping works: network path is clear
# If ping fails: could be the host, the network, or a firewall blocking ICMP

# Step 2: Can you reach a specific port? (TCP connectivity)
# This is more useful than ping because many servers block ICMP
nc -zv server.example.com 443   # Test if port 443 (HTTPS) is open
# Or use curl for HTTP services
curl -I https://example.com     # Just fetch headers to test connectivity

# Step 3: Where is the traffic getting stuck? (Trace the route)
traceroute google.com    # Shows every hop between you and the destination
# Each line is a router along the path. If it stops or times out at hop N,
# that is where the problem lives. Useful for diagnosing network-level issues.

# Step 4: Is DNS working? (Name resolution)
nslookup google.com      # Simple DNS lookup
dig google.com           # Detailed DNS lookup (preferred by sysadmins)
dig +short google.com    # Just show the IP address
# If DNS fails but pinging an IP works, your DNS configuration is the problem
# Check /etc/resolv.conf for your configured nameservers

# List all listening ports with the process that owns them
# -t = TCP, -u = UDP, -l = listening, -p = show process, -n = numeric (skip DNS lookup)
ss -tulpn

# Show all active connections (not just listening)
ss -tan

# Count connections by state (useful for diagnosing connection leaks)
ss -s

# Check what process is using a specific port
ss -tlnp | grep :8080
# Or use lsof (list open files -- remember, sockets are files in Linux)
sudo lsof -i :8080

# Basic connection (prompts for password if key auth is not set up)
ssh user@hostname
ssh user@192.168.1.100

# Connect using a specific private key (common with cloud providers like AWS)
ssh -i ~/.ssh/mykey.pem user@server

# Connect on a non-standard port (if SSH was moved from default 22 for security)
ssh -p 2222 user@server

# Run a single command on the remote server without opening an interactive shell
ssh user@server "df -h && free -m"

# Generate a key pair (ed25519 is modern and secure, RSA is the older standard)
ssh-keygen -t ed25519 -C "your@email.com"
# This creates:
# ~/.ssh/id_ed25519       (private key -- NEVER share this)
# ~/.ssh/id_ed25519.pub   (public key -- safe to share)

# Copy your public key to the remote server's authorized_keys file
ssh-copy-id user@server
# After this, SSH will use key authentication automatically -- no more passwords

# Set correct permissions (SSH refuses to use keys with lax permissions)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

# ~/.ssh/config
Host prod-web
    HostName 10.0.1.50
    User deploy
    IdentityFile ~/.ssh/deploy_key
    Port 22

Host staging
    HostName staging.example.com
    User admin
    IdentityFile ~/.ssh/staging_key
    ForwardAgent yes

# Now you can just type:
ssh prod-web
ssh staging
# Instead of remembering IPs, usernames, and key paths every time

# Copy a file to a remote server
scp file.txt user@server:/path/to/destination/

# Copy a file from a remote server to your local machine
scp user@server:/var/log/app.log ./

# Copy an entire directory recursively
scp -r directory/ user@server:/path/

# rsync is better for large transfers (only sends differences, supports resume)
rsync -avz --progress local-dir/ user@server:/remote-dir/
# -a = archive mode (preserves permissions, timestamps, etc.)
# -v = verbose, -z = compress during transfer

# Local port forwarding: access remote-server's port 5432 via your localhost:5432
# Use case: connect to a production database that only accepts connections from localhost
# The database thinks the connection is coming from the server itself, not from your laptop
ssh -L 5432:localhost:5432 user@remote-server
# Now: psql -h localhost -p 5432 connects to the REMOTE database through the tunnel
# "localhost" in the -L flag refers to the remote server's localhost, not yours

# Remote port forwarding: expose your local service on the remote server
# Use case: let a colleague access your local dev server through a shared jump box
ssh -R 8080:localhost:3000 user@jump-server
# Now: anyone who can reach jump-server:8080 sees your local port 3000

# Dynamic SOCKS proxy: route all traffic through the remote server
# Use case: access internal websites behind a corporate VPN from home
ssh -D 1080 user@jump-server
# Configure your browser to use SOCKS proxy at localhost:1080
# All browser traffic now appears to originate from the jump server

# Check current firewall status and rules
sudo ufw status
sudo ufw status verbose  # More detail including default policies

# CRITICAL: Allow SSH before enabling the firewall
# If you enable UFW without allowing SSH, you lock yourself out of the server
sudo ufw allow 22/tcp

# Set default policies (deny all incoming, allow all outgoing)
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Enable the firewall (this takes effect immediately)
sudo ufw enable

# Allow specific services
sudo ufw allow 80/tcp    # HTTP
sudo ufw allow 443/tcp   # HTTPS

# Deny access to a port (block external database connections)
sudo ufw deny 3306/tcp   # MySQL
sudo ufw deny 5432/tcp   # PostgreSQL

# Allow from a specific IP only (e.g., your office IP can access SSH)
sudo ufw allow from 203.0.113.50 to any port 22

# Delete a rule
sudo ufw delete allow 80/tcp

# Reset all rules (start over)
sudo ufw reset

# List all current rules
sudo iptables -L -n -v
# -L = list, -n = numeric (skip DNS lookup), -v = verbose (show counters)

# Allow incoming HTTP traffic
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# Allow established connections (critical -- without this, responses to your
# outgoing requests get blocked)
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Drop all other incoming traffic (put this rule last)
sudo iptables -A INPUT -j DROP

# Save rules so they persist across reboots
sudo iptables-save > /etc/iptables/rules.v4

# Check which nameservers your system uses
cat /etc/resolv.conf
# nameserver 8.8.8.8
# nameserver 8.8.4.4

# The hosts file takes priority over DNS -- useful for local overrides and testing
cat /etc/hosts
# 127.0.0.1   localhost
# 10.0.1.50   db-primary.internal    # Force this hostname to resolve to a specific IP

# Check the name resolution order
cat /etc/nsswitch.conf | grep hosts
# hosts: files dns    <-- checks /etc/hosts first, then DNS