Kunci SSH dengan passphrase menempatkan satu pagar di depan pintu terakhir: berkas kunci privat terenkripsi, dan setiap kali ssh memakainya, passphrase ditanyakan. Pagar itu sehat — sampai push kesepuluh di hari yang sama menuntut ketikan yang sama untuk kesepuluh kalinya. Membuat dan Menggunakan SSH Key menutup dengan janji bahwa ssh-agent bisa menyingkirkan ketikan berulang itu; chapter ini membayar janjinya. Agen adalah proses kecil yang memegang kunci privat dalam keadaan terbuka di memori, sehingga passphrase cukup ditanyakan sekali per sesi.

Peran Agent: Kunci Terbuka di Memori #

Mekanismenya sederhana dan tidak pernah melanggar aturan dasarnya: kunci privat tidak meninggalkan mesin. Saat dijalankan, ssh-agent membuka satu socket dan menunggu; ssh yang membutuhkan tanda tangan mengirim permintaan ke socket itu; agent — yang memegang kunci terbuka di memorinya — menandatangani dan mengembalikan hasilnya. Platform tetap memverifikasi dengan kunci publik; yang berubah hanyalah siapa yang menahan kunci privat saat transaksi: agent, bukan prompt interaktif.

Dua konsekuensi mengikuti. Pertama, agent hanya memegang kunci dalam memori — tidak menulis kunci terbuka ke disk — sehingga mematikan agent berarti menghapus satu-satunya salinan kunci terbuka. Kedua, siapa pun yang bisa berbicara ke socket agent bisa meminta tanda tangan; karena itu socket berada di direktori sementara dengan izin ketat milik akun kita.

Menjalankan Agent dengan eval #

Perintah ssh-agent mencetak bukan teks biasa, melainkan perintah shell siap jalan — itulah sebabnya idiom lazimnya membungkusnya dengan eval. Keluaran mentahnya di sandbox:

bash
ssh-agent -s

Output yang Dihasilkan:

text
SSH_AUTH_SOCK=/tmp/ssh-sTaeQcprVr7M/agent.5975; export SSH_AUTH_SOCK;
SSH_AGENT_PID=5976; export SSH_AGENT_PID;
echo Agent pid 5976;

Bedah tiga barisnya: dua baris pertama mengekspor variabel lingkungan — SSH_AUTH_SOCK menunjuk ke socket agent, SSH_AGENT_PID ke nomor prosesnya — dan baris ketiga sekadar mencetak laporan. Jalur socket dan nomor proses selalu berbeda setiap agent dijalankan; dua baris itu adalah konfigurasi, bukan pesan untuk dibaca. Membungkus dengan eval menjalankan ketiganya:

bash
eval "$(ssh-agent)"

Output yang Dihasilkan:

text
Agent pid 5982

Satu baris itulah satu-satunya yang terlihat — variabel terpasang diam-diam di sesi shell. Setelah itu, setiap ssh (dan setiap git push lewat alamat git@host) otomatis tahu ke mana mengirim permintaan tanda tangan.

ssh-add: Mendaftarkan Kunci #

Agent yang baru lahir masih kosong — kuncinya belum ada di memori:

bash
ssh-add -l

Output yang Dihasilkan:

text
The agent has no identities.

Kunci didaftarkan dengan ssh-add:

bash
ssh-add ~/.ssh/id_ed25519

Output yang Dihasilkan:

text
Identity added: /home/z/my-project/tutorial-extracted/work/sandbox/keamanan-dan-akses/part-a/latihan-agent/id_ed25519 ([email protected])

Jalur panjang itu adalah lokasi kunci di sandbox; di mesin kita cukup ~/.ssh/id_ed25519. Bila kunci ber-passphrase, ssh-add menanyakannya tepat di titik ini — sekali — lalu agent menyimpan versi terbukanya. Kunci sandbox sengaja dibuat tanpa passphrase agar latihan berjalan otomatis; pada kunci sungguhan, inilah satu-satunya ketikan passphrase sesi ini.

Daftar isi agent bisa diperiksa ulang:

bash
ssh-add -l

Output yang Dihasilkan:

text
256 SHA256:pGaxcvHADOGew+M01aqUoQJgLQn5C2GcjIrTXJaoQ1k [email protected] (ED25519)

Fingerprint SHA256:pGax... identik dengan keluaran ssh-keygen -lf ~/.ssh/id_ed25519.pub dari chapter pembuatan kunci — agent memang memegang kunci yang sama, dan kunci ed25519 selalu acak per pembuatan sehingga fingerprint di mesin kita berbeda dari contoh. Push demi push berikutnya berlangsung tanpa satu ketikan pun.

Mematikan Agent dan Batasannya #

Sesi selesai — agent dimatikan agar kunci terbuka tidak menetap di memori:

bash
ssh-agent -k

Output yang Dihasilkan:

text
unset SSH_AUTH_SOCK;
unset SSH_AGENT_PID;
echo Agent pid 5976 killed;

Bentuknya sama dengan kelahirannya: tiga perintah shell yang mengosongkan variabel lingkungan lalu mematikan proses agent. Batasannya juga terbaca dari bentuk itu: variabel hidup di satu sesi shell, jadi agent mati saat terminal ditutup, dan pasti mati saat mesin reboot. Passphrase ditanyakan lagi esok hari — kompromi yang disengaja: kunci terbuka tidak pernah menginap di memori lebih lama dari sesi pemiliknya.

AddKeysToAgent: Praktik Modern #

Idiom eval + ssh-add manual punya penerus yang lebih ramping. OpenSSH menyediakan opsi AddKeysToAgent yes di ~/.ssh/config:

ini
Host github-budi
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519
  AddKeysToAgent yes

Maknanya: saat kunci itu pertama kali dipakai — ssh meminta passphrase, kita menjawab sekali — ssh otomatis mendaftarkan kunci ke agent yang sedang hidup. Esok hari, kapan pun agent berjalan dan kunci dipakai, pendaftaran terjadi sendiri tanpa ssh-add manual. Resolusinya bisa diperiksa tanpa koneksi, dengan ssh -G:

bash
ssh -G github-budi | grep -E '^(hostname|user|identityfile|addkeystoagent) '

Output yang Dihasilkan:

text
user git
hostname github.com
identityfile ~/.ssh/id_ed25519
addkeystoagent true

Baris terakhir membuktikan opsi terbaca — yes dinormalkan OpenSSH menjadi true. Sandbox memakai ssh -G -F <berkas> agar konfigurasi latihan tidak menyentuh ~/.ssh/config sungguhan; di mesin kita ssh -G github-budi polos sudah cukup.

Agent Forwarding: Kenyamanan dengan Harga #

Satu fitur pelengkap perlu dipahami sebelum dipakai: forwarding (ForwardAgent yes). Dengan opsi itu, ssh ke server jauh membawa koneksi ke agent lokal — sehingga dari server jauh, git pull ke platform tetap bisa menandatangani tanpa menyalin kunci privat ke sana. Kunci tetap tidak pernah meninggalkan mesin lokal; yang diteruskan hanyalah akses ke socket agent.

Harganya serius dan perlu dinyatakan apa adanya:

Agent menuntaskan jalur SSH: kunci ber-passphrase, diketik sekali, dipakai seharian. Jalur HTTPS menyimpan tantangan yang berbeda — kredensialnya bukan kunci yang tinggal di satu berkas, melainkan token yang harus diberi nama, dibatasi cakupannya, dirotasi, dan dicabut. Pengelolaan siklus hidup token itu pokok bahasan chapter berikutnya.