Cara Set Hermes Agent untuk Kontrol Website VPS

Kamu punya satu VPS yang menampung banyak website, misalnya blog.example.com, webhook.example.com, dan beberapa lagi. Sekarang kamu ingin Hermes Agent bisa ikut mengelola salah satunya (misalnya halaman blog), tapi dengan satu syarat penting: Hermes jangan sampai merambah website atau direktori yang lain. Ini panduan praktik nyata untuk mencapai itu.

⚠️ Catatan: semua contoh IP, username, alamat, dan nama domain di artikel ini adalah data dummy / fiktif demi keamanan — ganti dengan milikmu sendiri.

Kabar baiknya, cara paling aman dan simpel adalah SSH key + script deploy — bukan membuat API/webhook baru yang malah menambah permukaan serangan (attack surface) dan beban maintenance. Berikut langkah lengkapnya.

Prinsip Utama: Least Privilege

Sebelum ngoding, pahami satu filosofi keamanan: beri akses minimum yang dibutuhkan. Hermes hanya perlu:

1. Bisa upload file markdown ke folder website yang dituju.
2. Bisa menjalankan script deploy untuk website itu saja.

Dia tidak perlu akses root, tidak perlu akses ke folder website lain, dan tidak perlu command shell bebas. Dengan membatasinya hanya pada itu, satu kebocoran kredensial tidak akan menghancurkan seluruh server.

Lihat Dulu Struktur Direktori VPS

Katakanlah VPS kamu (misalnya server dengan username root@srv-nyata, yang demo kita samarkan jadi root@vps saja) punya struktur website di /www/wwwroot/:

/www/wwwroot/
├── default/                 # default site (biarkan)
├── depotes.example.com/     # website lain (jangan disentuh)
├── webhook.example.com/     # website lain (jangan disentuh)
├── blog.example.com/        # website yang ingin dikelola Hermes
└── blog-source/             # source code blog (tempat Hermes bekerja)

Tujuan kita: membuat Hermes bekerja hanya di blog-source/ (sumber) dan blog.example.com/ (hasil publish). Dua folder itu saja.

Langkah 1: Bereskan SSL Dulu (Wajib Sebelum Deploy Otomatis)

Kalau website belum pakai HTTPS, publish otomatis akan sering terbentur masalah (browser menganggap konten tidak aman, atau JS/API diblokir). Di server aaPanel (BT Panel / 宝塔), jangan repot pakai certbot CLI yang tidak terpasang — pakai cert manager bawaan panel:

1. Buka Panel GUI → Website → pilih blog.example.com.
2. Buka tab SSL.
3. Pilih Let’s Encrypt (atau yang tersedia) → Apply.
4. Panel otomatis memperbarui konfigurasi nginx (mengaktifkan listen 443 ssl).

Setelah ini, HTTPS aktif dan kamu siap lanjut.

Langkah 2: Buat User Linux Khusus untuk Hermes

Jangan pernah pakai user root atau www untuk akses otomatis. Buat user khusus bernama hermes dengan policy least privilege — dia hanya hidup di dalam folder website blog:

adduser --disabled-password --home /www/wwwroot/blog-source hermes
mkdir -p /home/hermes/.ssh
chmod 700 /home/hermes/.ssh
echo "ssh-ed25519 AAAA_PUBLIC_KEY_DUMMY_SUDAH_DIGANTI hermes@mesin" >> /home/hermes/.ssh/authorized_keys
chmod 600 /home/hermes/.ssh/authorized_keys
chown -R hermes:hermes /home/hermes/.ssh
usermod -aG hermes hermes
chown -R hermes:hermes /www/wwwroot/blog-source

⚠️ AAAA_PUBLIC_KEY_DUMMY_SUDAH_DIGANTI di atas hanyalah contoh format — jangan pernah pakai key asli di contoh publik. Ganti dengan public key milikmu.

Ganti PUBLIC_KEY_HERMES dengan public key dari mesin Hermes. Cara dapatnya:

# di sisi mesin Hermes (kalau belum punya key)
ssh-keygen -t ed25519 -C "hermes@mesin" -f ~/.ssh/id_ed25519 -N ""
# lalu tampilkan public key-nya
cat ~/.ssh/id_ed25519.pub

Tempel hasil cat itu ke file authorized_keys di VPS.

Langkah 3: Buat Script Deploy (dengan rsync)

Script inilah “satu-satunya tombol” yang Hermes boleh tekan. Buat file di /www/wwwroot/blog-source/deploy.sh:

#!/bin/bash
set -e
cd /www/wwwroot/blog-source
hugo --minify
rsync -a --delete public/ /www/wwwroot/blog.example.com/
chown -R www:www /www/wwwroot/blog.example.com

Lalu jadikan executable dan milik user hermes:

chmod +x /www/wwwroot/blog-source/deploy.sh
chown hermes:hermes /www/wwwroot/blog-source/deploy.sh

Kenapa rsync --delete? Karena lebih aman daripada rm -rf manual. Dia otomatis:

• Menyalin file baru/berubah
• Menghapus file lama yang sudah dihapus di source
• Melakukannya dengan cara transaksional, jadi tidak ada momen “folder jadi kosong” saat proses berjalan

Ini menghindari kejadian tidak menyenangkan seperti website “hilang” gara-gara deploy yang salah urut.

Langkah 4: Alur Kerja Hermes Setiap Kali Publish Artikel

Sekarang, dari mesin Hermes, ini saja yang perlu dijalankan tiap kali mau publish artikel baru:

# 1) upload file artikel markdown ke folder source website blog
scp artikel-baru.md hermes@203.0.113.55:/www/wwwroot/blog-source/content/posts/

# 2) trigger deploy (build hugo + rsync ke website)
ssh hermes@203.0.113.55 '/www/wwwroot/blog-source/deploy.sh'

203.0.113.55 adalah contoh alamat IP fiktif dari blok dokumentasi (TEST-NET) — ganti dengan IP server asli kamu.

Hanya dua baris itu. Hermes meng-upload konten, lalu menyuruh script deploy di server menjalankan build & publish. Tidak ada akses ke server lain, tidak ada shell bebas (kalau dikunci), dan folder website lain (webhook.example.com, depotes.example.com) tidak pernah tersentuh.

Untuk kenyamanan, di mesin Hermes kamu bisa tambahkan alias SSH:

# ~/.ssh/config
Host blog
    HostName 203.0.113.55
    User hermes
    IdentityFile ~/.ssh/id_ed25519

Lalu cukup ssh blog untuk terhubung.

Langkah 5: (Opsional) Kunci Lebih Ketat — Batasi ke Satu Perintah

Sejauh ini Hermes punya akses SSH biasa. Kalau kamu mau super ketat, batasi key tersebut supaya hanya bisa menjalankan deploy.sh dan tidak bisa membuka shell bebas. Caranya, edit baris di authorized_keys:

command="/www/wwwroot/blog-source/deploy.sh",no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA_PUBLIC_KEY_DUMMY

Artinya: setiap kali key ini dipakai, SSH hanya mengeksekusi deploy.sh — Hermes tidak bisa mengetik command lain di server. Ini mengunci Hermes pada satu fungsi saja.

⚠️ Catatan: dengan pembatasan ini, upload file markdown lewat scp biasa tidak lagi bisa (karena scp butuh shell bebas). Solusinya: gunakan dua key terpisah:

• Satu key khusus rsync/upload → unrestricted tapi hanya bisa menulis ke folder tertentu
• Satu key khusus trigger deploy → restricted ke deploy.sh

Ini opsi hardening lanjutan. Untuk setup awal, langkah 2-4 sudah jauh lebih aman dari biasanya. Tambahkan pembatasan ini nanti kalau Hermes sudah publish rutin.

Menyambungkan dengan Webhook/Website Lain

Di VPS-mu bisa saja ada juga webhook.example.com/ yang berisi file PHP (billing, recharge, registrasi, dll). Jangan hubungkan Hermes ke sana kecuali memang diperlukan — karena:

• File PHP itu bisa punya akses ke database & layanan sensitif
• Menambahkan Hermes di situ menambah risiko

Fokuskan Hermes hanya pada satu website blog yang memang dia kelola. Ini justru keunggulan pendekatan ini: isolasi per direktori membuat satu bagian jika bermasalah tidak menular ke bagian lain.

Verifikasi: Pindah Folder yang Tidak Boleh Disentuh

Setelah semua beres, uji keamanannya:

1. Login sebagai hermes di VPS.
2. Coba ls /www/wwwroot/webhook.example.com/ → ini harusnya tidak bisa (permission denied) karena webhook.example.com bukan milik hermes.
3. Coba cat /www/wwwroot/depotes/* → juga harusnya ditolak.

Kalau keduanya ditolak, berarti isolasi berhasil: Hermes hanya “hidup” di blog-source/ dan blog.example.com/.

$ ls /www/wwwroot/webhook.example.com/
ls: cannot open directory: Permission denied   ← BENAR (terkunci)

Ringkasan Arsitektur

FAQ

Apakah perlu membuat API/webhook sendiri untuk Hermes?

Tidak untuk kasus ini. SSH key + script deploy sudah cukup, lebih aman (tidak menambah endpoint publik), dan lebih mudah di-maintain.

Apa bedanya dengan CI/CD?

CI/CD (misal GitHub Actions) cocok kalau kamu mau pipeline otomatis dari repository. Tapi kalau dirimu (manusia) atau Hermes yang langsung memicu publish, SSH + script deploy jauh lebih ringan dan tidak butuh infrastruktur tambahan.

Apakah Hermes bisa merusak website lain?

Tidak, selama user hermes hanya punya izin di folder blog-nya. Ini prinsip least privilege yang mencegah “satu titik bocor merusak semuanya”.

Bagaimana kalau saya punya banyak user Hermes?

Buat user & key terpisah per “identitas” atau per website. Setiap user dikunci di direktori masing-masing.

Kesimpulan

Mengatur Hermes Agent untuk mengontrol satu website di VPS yang berisi banyak website itu mudah dan aman apabila mengikuti prinsip isolasi:

1. SSH key + script deploy — bukan API/webhook baru
2. User khusus hermes dengan least privilege — bukan root/www
3. rsync --delete — deploy transaksional, aman dari file tertinggal
4. Hanya folder blog yang bisa diakses — website lain terkunci
5. (Opsional) restricted key — Hermes hanya bisa trigger deploy.sh

Hasilnya: Hermes bisa publish konten blog kapan saja secara otomatis, sementara webhook.example.com, depotes, dan website lain tetap aman di kotak mereka masing-masing. Kontrol penuh, risiko minimal.

Artikel Terkait

• Setup Hermes Agent di VPS: AI Assistant yang Selalu Online
• VPS untuk AI: Spesifikasi yang Benar-Benar Dibutuhkan

Sumber & Referensi

• OpenSSH Authorized Keys (membatasi command)
• rsync Manual
• Hermes Agent (Nous Research)

Ditulis original oleh tim Ajeng Media berdasarkan praktik nyata pengelolaan VPS multi-website. Semua contoh alamat, IP, username, dan key adalah data dummy/fiktif demi keamanan.