Linux networking and SSH

You generate a key pair. The public key goes into the server's authorized_keys; the private key stays on your machine. When you connect, the server sends a challenge that only the holder of the private key can sign, and verifies the signature with the public key. The private key never crosses the network. Passwords can be guessed, reused or phished, and every public SSH port receives constant brute-force attempts. A key has far more entropy than any password, and when protected with a passphrase it is also useless to someone who steals the file. You can also revoke one device's key without affecting others.

I go layer by layer. DNS first: dig +short example.com should return the server's IP. Then reachability: curl -I from outside, and check the provider and ufw firewalls allow 80 and 443. On the server, ss -tlnp shows whether nginx is listening on those ports, and systemctl status nginx and nginx -t show whether it is running with a valid config. Next I bypass nginx and curl the app directly on its local port. If that fails, the app's journal or log tells me why. If it works, the problem is the proxy config or TLS, which curl -v shows clearly.

ss lists sockets: -t for TCP, -l for listening ones, -n for numeric ports instead of names and -p for the owning process. It answers 'what is open on this machine and who opened it'. The address matters: 127.0.0.1 means only local processes can connect, 0.0.0.0 (or [::]) means every interface, including the public one. A database or Redis listening on 0.0.0.0 on an internet-facing host is one firewall mistake away from being exposed, and exposed databases are found and attacked by scanners within hours. So I bind internal services to localhost or a private network interface.

Through an SSH tunnel. ssh -N -L 5433:127.0.0.1:5432 your_user@server opens port 5433 on my laptop, and anything connecting to it travels inside the encrypted SSH session and comes out on the server as a local connection to PostgreSQL. My database client points at localhost:5433. The database keeps listening only on localhost, so nothing is opened in the firewall. If the database runs on a separate private host, I tunnel through the app server or a bastion with ProxyJump. For a team, a VPN like WireGuard or a managed access tool can replace ad-hoc tunnels.

Not by default, which surprises many people. When you publish a port with -p 8080:80, Docker inserts its own iptables rules that forward traffic to the container before ufw's rules are checked, so the port is reachable from the internet even if ufw denies it. The simplest fix is to publish only on localhost, for example -p 127.0.0.1:8080:80, and put nginx in front. Docker also supports filtering in the DOCKER-USER chain, and a cloud provider firewall in front of the server blocks the traffic regardless. I always verify from outside with a port scan or curl.

Both copy files over SSH. scp is a simple copy, like cp across machines: it always transfers the whole file and has few options. rsync compares source and destination and sends only what changed, so repeated syncs of large directories are fast. It can resume interrupted transfers, preserve permissions, owners and timestamps with -a, compress with -z, exclude patterns, and mirror a directory exactly with --delete. That makes it the right tool for deployments of static builds and for backups. I always run it with --dry-run first when --delete is involved, and I pay attention to the trailing slash on the source path.

Copying personal public keys to every server works for two people and five servers; beyond that, onboarding and especially offboarding become error-prone. The better model is central identity with short-lived credentials. SSH certificates signed by an internal CA, issued for a few hours after single sign-on, mean servers trust one CA key and nothing needs cleaning up when someone leaves. Tools like Teleport, cloud session managers or HashiCorp Vault's SSH engine automate issuing and add session recording. Put servers on a private network reachable through a bastion or a VPN mesh like WireGuard or Tailscale, so SSH is not exposed publicly at all. The trade-offs are operating the CA or tool itself and having a break-glass path if it is down.

With agent forwarding (-A), the remote server gets a socket to your local ssh-agent. Your private key never leaves your laptop, but anyone with root on that server, or access to your user there, can use the socket to authenticate as you to any other host while you are connected. On a shared or compromised jump host that is a real lateral-movement risk. For reaching internal servers, ProxyJump (-J) is the safer replacement: the connection to the target is tunneled through the bastion, but authentication happens end to end from your laptop, so the bastion never touches your keys. For pulling from Git on a server, use a read-only deploy key specific to that repository rather than forwarding your personal agent.

Both, because they fail differently. The provider's cloud firewall filters traffic before it reaches the machine, survives a misconfigured or flushed host ruleset, and is not bypassed by Docker's iptables rules. The host firewall works regardless of provider, can express finer rules such as per-interface or per-source limits, and keeps protecting the host if the cloud rule set is edited by mistake. Neither replaces binding internal services to localhost or a private interface, which removes exposure entirely instead of filtering it. On top come rate limits and fail2ban for login endpoints, and a CDN or proxy in front of web traffic for DDoS absorption, with the origin accepting web traffic only from the proxy's ranges. The cost is keeping two rule sets consistent, ideally in code.