Konfigurasi VPS Ubuntu untuk situs pertama Anda

Siapkan domain dan akses pemulihan

Gunakan VPS baru Ubuntu 24.04, IPv4 publik, SSH port 22, akun awal dengan sudo, dan domain yang Anda kendalikan. Buat kunci SSH sebelum provisioning pada langkah berikut. Jika server kosong sudah dibuat, gunakan cabang pemasangan kunci melalui akses yang masih bekerja. Perintah komputer menggunakan Bash di Linux, macOS, atau WSL; perintah server dijalankan di SSH.

Ganti 203.0.113.10 dan app.example.com dengan IP serta hostname Anda. Nama akun ubuntu harus disesuaikan dengan akun penyedia. Buka konsol pemulihan sebelum mengubah akses. Hentikan langkah bila path contoh dipakai layanan yang sudah ada. Image Oracle Ubuntu membutuhkan cabang firewall khusus.

Buat kunci atau tambahkan lewat sesi yang bekerja

Pada komputer, buat kunci tersendiri dengan passphrase. Jika nama file sudah ada, pilih nama lain pada seluruh langkah. .pub adalah public key; private key tetap di komputer.

mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pub

VPS belum dibuat: sekarang buat Ubuntu 24.04 dan masukkan public key pada kolom SSH penyedia. Konfirmasikan nama akun, lalu langsung ke verifikasi fingerprint. Lewati langkah penyalinan melalui kunci lama.

VPS kosong sudah dibuat: biarkan sesi SSH yang bekerja tetap terbuka. Dari terminal komputer lain, salin public key dengan metode autentikasi yang sudah berfungsi. Ganti existing_vps_key dengan private key lama. Jika akses memakai password atau agent, hilangkan -i ~/.ssh/existing_vps_key; jangan mengubah kebijakan autentikasi server.

scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

Di sesi server yang masih bekerja, validasi file unggahan dan tambahkan ke authorized_keys akun awal Anda. Penambahan mempertahankan kunci lama dan memberi baris baru bila baris terakhir sebelumnya tidak diakhiri newline. Tanpa akses yang bekerja, gunakan pemulihan penyedia dahulu.

if ssh-keygen -lf ~/ubuntu-vps-admin.pub; then
    mkdir -p ~/.ssh
    chmod 700 ~/.ssh
    printf '\n' >> ~/.ssh/authorized_keys
    cat ~/ubuntu-vps-admin.pub >> ~/.ssh/authorized_keys
    chmod 600 ~/.ssh/authorized_keys
fi

Untuk kedua cabang, verifikasi host key melalui konsol terpercaya sebelum menerima koneksi baru. Untuk algoritme Ed25519, jalankan pada konsol server:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Pada komputer, buka koneksi baru menggunakan kunci baru. Pertahankan akses awal sampai berhasil.

ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Dari terminal komputer lain, salin public key untuk akun administrator yang dibuat berikutnya. File sementara ini boleh disalin ulang bila sudah dikirim sebelumnya.

scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

Buat administrator tanpa mengganti akun lain

Pada server, periksa getent passwd deploy. Seharusnya tidak ada akun yang ditemukan. Jika deploy sudah ada, gunakan nama belum terpakai dan ubah semua username, home path, serta group pada contoh. Jangan mengganti file kunci milik pengguna yang sudah ada.

Periksa image dan resource, tinjau pembaruan, lalu buat administrator. Pilih password kuat untuk permintaan sudo. Perintah install memberikan kepemilikan serta izin terbatas pada file kunci.

cat /etc/os-release
free -h
df -h /
sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy ~/ubuntu-vps-admin.pub /home/deploy/.ssh/authorized_keys

Pada terminal komputer baru, masuk sebagai administrator tersebut.

ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10

Dalam sesi baru itu, jalankan sudo. Sesudah menerima password deploy, hasilnya harus root. Lanjutkan hanya bila login dan sudo bekerja; biarkan akses sebelumnya tersedia.

sudo whoami

Pasang Nginx dan ikuti firewall image

Pada server, pasang Nginx. Firewall penyedia dan guest sama-sama memengaruhi akses.

sudo apt install nginx
sudo systemctl enable --now nginx

Di firewall penyedia, izinkan TCP 22 dari lokasi administrasi dan TCP 80/443 untuk pengunjung. Jika SSH memakai port berbeda, pertahankan port sebenarnya. Buka konsol pemulihan serta sesi yang sudah bekerja selama perubahan.

Image Oracle Cloud Ubuntu: lewati seluruh blok UFW berikut. Oracle memperingatkan konflik dengan aturan firewall image yang dapat mengganggu boot. Pertahankan iptables, termasuk aturan iSCSI boot/block volume. Atur security list atau NSG OCI dan aturan guest yang didokumentasikan untuk HTTP/HTTPS. Jangan mengosongkan aturan atau mengganti paket firewall image.

Image Ubuntu baru lain yang mendukung UFW: jalankan blok berikut hanya bila penyedia mendukungnya dan tidak mewajibkan firewall berbeda. Izinkan port SSH sebenarnya sebelum mengaktifkan firewall; contoh memakai 22.

sudo apt install ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Setelah cabang mana pun, uji login SSH baru. Sesi lama yang tetap hidup bukan bukti koneksi baru berhasil. Uji HTTP dari luar sebelum meminta sertifikat.

Terbitkan file pada konfigurasi situs tersendiri

Pada server, buat document root serta konfigurasi baru. Ganti hostname di dalam blok. Pertahankan penanda EOF yang dikutip agar shell tidak memperluas variabel Nginx seperti $uri.

sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="id"><title>Publikasi pertama</title><h1>Halaman ini berjalan di VPS Ubuntu</h1></html>' | sudo tee /var/www/first-site/index.html
sudo tee /etc/nginx/sites-available/first-site >/dev/null <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;
    root /var/www/first-site;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
sudo ln -s /etc/nginx/sites-available/first-site /etc/nginx/sites-enabled/first-site
sudo nginx -t

Reload hanya sesudah nginx -t berhasil.

sudo systemctl reload nginx

Pada komputer, minta hostname langsung ke alamat server sebelum mengubah DNS. Harapkan judul halaman contoh, bukan halaman sambutan Nginx.

curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/

Hubungkan DNS dan aktifkan HTTPS

Buat record A menuju IPv4 VPS. Buat AAAA hanya bila IPv6 server benar-benar bekerja. AAAA lama dapat mengirim pengunjung atau validasi sertifikat ke tujuan salah. Contoh menggunakan DNS langsung ke VPS, tanpa proxy.

Dari komputer, buka http://app.example.com/ tanpa --resolve. Lanjutkan bila halaman contoh tampil. Di server, pasang Certbot dari arsip Ubuntu beserta plugin Nginx. Paket membutuhkan repositori Universe; selesaikan error paket tidak ditemukan sebelum melanjutkan.

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect
sudo nginx -t
sudo certbot renew --dry-run
systemctl list-timers --all certbot.timer

Ikuti permintaan email dan persetujuan ketentuan. Certbot mengubah konfigurasi situs dan membuat redirect HTTP ke HTTPS. Pastikan timer pembaruan terjadwal; bila belum aktif, gunakan sudo systemctl enable --now certbot.timer. Port 80 tetap diperlukan untuk validasi dan pembaruan HTTP.

Uji dari luar dan setelah restart

Jalankan dari komputer. HTTP harus beralih ke HTTPS; HTTPS harus berhasil dan menampilkan isi yang benar. Jangan memakai curl -k karena menutupi kegagalan pemeriksaan sertifikat.

curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/

Saat situs masih uji coba, jalankan sudo reboot pada server. Setelah kembali, masuk sebagai deploy, periksa systemctl is-active nginx, dan ulangi permintaan HTTPS eksternal. Restart memutus SSH; gunakan konsol bila mesin tidak kembali.

Tangani kegagalan dan simpan bahan pemulihan

Geser tabel ke samping untuk melihat semua kolom.

Untuk kegagalan login, gunakan diagnosis SSH sebelum mengubah autentikasi. Simpan file situs, konfigurasi Nginx, DNS, dan langkah pembangunan ulang di luar VPS. Private key sertifikat perlu penyimpanan terlindungi bila ikut dibackup.

Latihan backup dan pemulihan file memeriksa salinan tanpa menimpa situs aktif. Pemulihan penuh juga mencakup aset lain, sertifikat, dan dependensi layanan. Aktifkan pemantauan ketersediaan dan kedaluwarsa sertifikat; satu pengujian tidak memantau hari berikutnya.

Prosedur ini menerbitkan file statis. Database atau runtime memerlukan konfigurasi layanan dan backup sendiri. Gunakan pengukuran resource saat menambah komponen.