Understanding SSH, Public Keys & Private Keys for Automated Website Updates

Every time you update a website running on the cloud or a rented server, one technology is almost always working behind the scenes: SSH. It’s what lets a developer in one country safely control a server on the other side of the world — and, more importantly, what makes updates run automatically, with no password typed at all. Let’s break it down from the ground up.

What is SSH?

SSH (Secure Shell) is a protocol for connecting to and controlling another computer remotely, over an encrypted channel. Picture opening the “terminal” of a server sitting in a data center while you’re at home. Every command you type and all data sent is encrypted, so it can’t be intercepted along the way.

Before SSH, people used protocols like Telnet that sent data — including passwords — in plain text. Anyone on the network could read it. SSH was created to close that gap.

The most common command:

ssh user@202.74.74.73

This means: “connect me as user to the server at 202.74.74.73.” Once in, you can run any command on that server as if you were sitting right in front of it.

The problem with passwords

The simplest way to prove “I’m allowed in” is a password. But passwords have serious weaknesses for servers:

• They can be guessed via brute-force attacks (trying millions of combinations).
• They can leak if you type them in the wrong place or store them carelessly.
• They’re awkward for automation — a script running on its own can’t safely “type” a password.

The answer is a far stronger approach: public-key cryptography, the heart of public keys and private keys.

Public key & private key: the padlock and key analogy

Imagine you have a pair of objects made together and matched to each other:

• 🔓 Public key = a padlock. You can share it with anyone. You install it on the server.
• 🔑 Private key = the one and only key that opens that padlock. It’s secret, only you hold it, and it’s never sent anywhere.

How login works:

1. The private key stays safe on your computer (e.g. ~/.ssh/id_ed25519).
2. You copy your public key to the server (into ~/.ssh/authorized_keys).
3. When you connect, the server “challenges” you with a puzzle only the holder of the matching private key can answer correctly.
4. Your computer answers using the private key — without ever sending the private key itself. The server verifies it using the public key. Match → you’re in.

The crucial part: your private key never leaves your computer. Even if someone intercepts the entire conversation, they can’t reconstruct your private key. That’s why this is far safer than a password.

Creating and installing a key pair

Creating a key pair takes one command:

ssh-keygen -t ed25519 -C "your-email@example.com"

This produces two files:

• id_ed25519 → the private key (SECRET, never share it).
• id_ed25519.pub → the public key (safe to distribute).

Then copy the public key to the server:

ssh-copy-id user@202.74.74.73

From then on, you can log in without a password — just ssh user@202.74.74.73 and you’re in, because your private key proves your identity automatically.

⚠️ Guard your private key like a safe’s key. If it leaks, others can get into your server. Protect it with a passphrase so it stays safe even if the file is stolen.

The core point: how this automates website updates

This is where the beauty appears. Because key-based login needs no human interaction (no password to type), the entire website update process can be run by an automated script.

A typical flow for updating a website on the cloud:

# Run from the developer's machine, automatically and password-free:
ssh user@server "cd /var/www/website && git pull && npm run build"

That single line connects to the server, pulls the latest code, and rebuilds the site — all triggered by one command. Because it uses keys, no password prompt stops the process.

The same pattern is everywhere:

• Deploy scripts (deploy.ps1 / deploy.sh) that copy built files to the server via scp or rsync.
• CI/CD like GitHub Actions: the CI server stores the private key as a secret, then uses SSH to deploy automatically every time you git push.
• Scheduled cron jobs that sync data between servers overnight.

Without public/private keys, none of this automation would be possible — because no human is standing by to type a password at 3 a.m. when the script runs.

Essential safe practices

• Use keys and disable password login on the server (PasswordAuthentication no) so brute-force is pointless.
• Protect your private key with a passphrase.
• One key per device/purpose — easy to revoke one if it leaks without disturbing the rest.
• Limit the account’s privileges used for deploys (don’t always use root).
• Pair it with a firewall (UFW) and fail2ban for extra layers of defense.

Summary

🔐 SSH = an encrypted channel to control a remote server · 🔓 Public key = the padlock installed on the server (shareable) · 🔑 Private key = the secret key that’s never sent · 🤖 Because login needs no password, website updates can be 100% automated via scripts, CI/CD, or cron.

SSH with a key pair is the quiet foundation that keeps the modern cloud running: safe for humans, and seamless for machines.

---

Elang apps run self-hosted on your own server and are updated with exactly this safe pattern. Learn why the foundation is solid in why Linux servers are so reliable, or see Elang products.