Section sebelumnya meninggalkan dua kunci di tangan kita: pasangan kunci SSH untuk jalur git@host dan personal access token untuk jalur HTTPS. Keduanya adalah kredensial — benda yang dibocorkan siapa pun bisa menyamar sebagai kita di platform. Pertanyaannya bergeser dari bagaimana mendapatkan kredensial ke di mana kredensial itu tinggal: di berkas konfigurasi, di memori, di brankas sistem operasi, atau terpahat di alamat remote. Pilihan penyimpanan menentukan luas kerusakan saat laptop hilang atau berkas terunggah. Chapter ini memetakan model kredensial Git, membuktikan pola penyimpanan mana yang nyatanya berbahaya, lalu menutup dengan prinsip pengelolaannya.

Dua Model Kredensial #

Jalur HTTPS dan SSH memakai dua model yang sama sekali berbeda. Pada HTTPS, Git mengirim pasangan username dan token setiap kali platform meminta autentikasi — kredensial berbentuk teks yang harus dijaga seperti kata sandi, sebagaimana dibahas di Personal Access Token . Pada SSH, kredensial adalah pasangan kunci kriptografi: kunci privat ~/.ssh/id_ed25519 tidak pernah dikirim ke mana pun; program ssh hanya memakainya untuk menjawab tantangan dari platform, sebagaimana dibedah di Membuat dan Menggunakan SSH Key .

Konsekuensinya pada cara bocornya pun berbeda. Token HTTPS cukup terbaca sekali — siapa pun yang melihat nilainya bisa memakainya dari mesin mana pun. Kunci SSH juga berbahaya bila berkas privatnya dicuri, tetapi berkas itu bisa dilindungi passphrase sehingga pencuri masih harus membuka enkripsinya, dan platform menampilkan fingerprint yang memudahkan pencabutan.

Token di URL Remote: Pola yang Harus Dihindari #

Ada satu pola yang tampak praktis tapi dilarang keras: menempelkan token langsung ke alamat remote. Sandbox mendemonstrasikannya dengan token tiruan:

bash 
git remote add origin \
  https://budi:[email protected]/budi/toko-buku.git
git remote -v

Output yang Dihasilkan:

text 
origin  https://budi:[email protected]/budi/toko-buku.git (fetch)
origin  https://budi:[email protected]/budi/toko-buku.git (push)

Alamat lengkap dengan token tersimpan permanen di .git/config — Git memang menyimpan URL remote di berkas itu:

ini 
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[user]
	name = Budi Santoso
	email = [email protected]
[remote "origin"]
	url = https://budi:[email protected]/budi/toko-buku.git
	fetch = +refs/heads/*:refs/remotes/origin/*

Bahaya kedua: URL itu muncul di daftar proses setiap kali Git berjalan. Sandbox membuktikannya dengan server lokal yang menggantung sehingga git ls-remote sempat dipotret ps:

bash 
ps aux | grep "[l]s-remote"

Output yang Dihasilkan:

text 
z        29292  0.0  0.0   2972  1048 ?        S    13:57   0:00 timeout 4 git ls-remote http://budi:[email protected]:38203/budi/toko.git
z        29295  0.0  0.1   7888  4308 ?        S    13:57   0:00 git ls-remote http://budi:[email protected]:38203/budi/toko.git

Baris kedua adalah proses git ls-remote sungguhan — argumennya berisi token dalam teks polos, terbaca oleh pengguna lain di mesin yang sama dan oleh alat pencatat aktivitas. Baris pertama hanyalah pembungkus timeout buatan sandbox; nomor proses, port, dan waktu selalu berbeda tiap mesin. Perbaikannya satu perintah — alamat bersih tanpa kredensial tertanam:

bash 
git remote set-url origin https://github.com/budi/toko-buku.git

Konfigurasi Git Tidak Menyimpan Kata Sandi #

Kekhawatiran yang sering muncul — “apakah git config menyimpan kata sandi saya?” — jawabannya tidak. Konfigurasi Git hanya mengatur perilaku, bukan menyimpan rahasia. Sandbox membuktikannya: kredensial disetorkan lewat mekanisme credential system, lalu konfigurasi diperiksa.

bash 
git config --list

Output yang Dihasilkan:

text 
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
user.name=Budi Santoso
[email protected]
remote.origin.url=https://github.com/budi/toko-buku.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
credential.helper=store

Tidak ada satu pun kunci password di situ. Token justru berakhir di tempat lain — berkas ~/.git-credentials milik helper store:

text 
https://budi:[email protected]

Persis di situlah risikonya: helper yang salah menyimpan kredensial dalam teks polos di berkas. Bandingkan tempat tinggal kredensial tiap metode:

MetodeKredensial tinggal diRisiko utama
HTTPS, token di URL remote.git/config + argumen prosesbocor lewat berkas konfigurasi dan daftar proses
HTTPS + helper store~/.git-credentials (teks polos)berkas terbaca bila disk atau backup jatuh
HTTPS + helper brankas OSKeychain macOS / Windows Credential Managerrelatif aman; terkunci kredensial OS
SSH + kunci privat~/.ssh/id_ed25519pencuri berkas masih harus menembus passphrase

Prinsip: Scope Minimal, Rotasi, Helper Resmi #

Tiga prinsip merangkum seluruh section ini. Scope minimal: kredensial hanya boleh membuka pintu yang benar-benar dibutuhkan — token dengan izin repository tunggal, bukan seluruh akun; pembahasan lengkapnya di Mengelola Token dan Least Privilege . Rotasi: kredensial punya masa hidup — yang pendek lebih baik daripada yang kuat tapi abadi. Rotasi punya dua pemicu di luar kalender: perangkat pemegang kredensial hilang, atau aktivitas asing muncul di repository — keduanya meminta pergantian seketika pada hari yang sama. Helper resmi: simpan kredensial di helper bawaan platform (brankas sistem operasi), bukan di rekayasa sendiri seperti URL ber-token atau berkas tempelan.

Pemilihan protokol sendiri bisa dipetakan menjadi alur keputusan singkat:

Alur itu menegaskan satu hal: jalur mana pun yang dipilih, kredensial tetap benda yang dirotasi dan dicabut. Langkah pertama setelah memilih jalur HTTPS adalah mengenal mesin penyimpanannya — credential helper — yang kita bedah di chapter berikutnya.