SSH Signing

GPG menyelesaikan pekerjaannya, tetapi harganya terasa: keyring, trustdb, subkey, dan sekumpulan istilah yang hanya hidup di dunia GPG. Sejak Git 2.34, ada alternatif yang jauh lebih ramping: kunci SSH yang sudah kita pakai untuk mengakses repository bisa dipakai untuk menandatangani commit. Satu jenis kunci yang sudah dikenal, dua kegunaan. Chapter ini mengonfigurasi penandatanganan SSH secara nyata, menjawab pertanyaan “bagaimana orang lain memverifikasinya” lewat berkas allowed_signers, lalu membandingkan kedua jalur supaya kita bisa memilih.

Mengalihkan Format ke SSH #

Kuncinya dibuat seperti kunci SSH biasa — sandbox memakai ed25519 tanpa passphrase:

cd work/sandbox/keamanan-dan-akses/part-b/latihan-ssh
ssh-keygen -t ed25519 -C "[email protected]" -f id_ed25519 -N ""

Dua konfigurasi mengalihkan Git dari GPG ke SSH. Yang pertama, gpg.format ssh — Git menyimpan format tanda tangan di keluarga konfigurasi gpg.* karena memang satu kerangka yang sama, meski pekerjaannya kini diberikan ke ssh-keygen (program bawaan untuk format ssh):

git config gpg.format ssh
git config user.signingkey "$(pwd)/id_ed25519.pub"
git config --get gpg.format && git config --get user.signingkey

ssh
/home/z/my-project/tutorial-extracted/work/sandbox/keamanan-dan-akses/part-b/latihan-ssh/id_ed25519.pub

user.signingkey menerima path berkas kunci — privat, atau publik seperti di sandbox ini, dengan pasangan privatnya berada di berkas tanpa akhiran .pub pada direktori yang sama (id_ed25519). Di mesin kita, path yang lazim cukup ~/.ssh/id_ed25519.pub. Konfigurasi gpg.format dan kawan-kawannya didokumentasikan di git-config dan format tanda tangannya di gitformat-signature . Commit ditandatangani seperti biasa:

git commit -S -m "Commit awal via tanda tangan SSH"

Isi tanda tangannya terlihat di objek commit — fieldnya masih bernama gpgsig, tetapi bloknya kini SSH:

git cat-file -p HEAD

tree e1c8f2b8309c44d426f98df8a8a8d7d2f02377a1
author Budi Santoso <[email protected]> 1791902072 +0700
committer Budi Santoso <[email protected]> 1791902072 +0700
gpgsig -----BEGIN SSH SIGNATURE-----

 U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAg8ESjfxb5bAhMMzE6lLeO8GIq52
 7rXQ5TSUREA1ajWtcAAAADZ2l0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5
 AAAAQIUEsWoPIGLM09uOyc9RTOq5Xpo3VWkAatW9r1kMjdMGfMZyNxqIOoP9wBpdrOicKE
 VCanob4ZgYKk3WeiJsXwk=
 -----END SSH SIGNATURE-----

Commit awal via tanda tangan SSH

Hash dan waktu commit bertanda tangan selalu berbeda per pembuatan. Blok SSH SIGNATURE adalah tanda tangan ssh-keygen atas isi commit — prinsip identitas dan integritasnya sama dengan GPG; yang berubah hanyalah jenis kunci dan program yang menandatangani.

allowedSignersFile: Daftar Kunci Terpercaya #

Coba verifikasi commit kita sendiri:

git log --show-signature -1

error: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification
commit 0b72e3674f66d8c6fe75f14dd99fd68ad29f424b
No signature
Author: Budi Santoso <[email protected]>
Date:   Tue Oct 13 21:34:32 2026 +0700

    Commit awal via tanda tangan SSH

Tanpa gpg.ssh.allowedSignersFile, Git menolak memverifikasi tanda tangan SSH. Ini desain, bukan kekurangan: GPG punya tingkat kepercayaan bawaan, SSH tidak — jadi Git hanya menganggap tanda tangan terpercaya bila kuncinya tercantum dalam berkas yang kita kelola sendiri. Formatnya satu baris per kunci: email penandatangan, jenis kunci, lalu kunci publiknya:

printf '[email protected] %s\n' "$(cat id_ed25519.pub)" > allowed_signers
cat allowed_signers

[email protected] ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPBEo38W+WwITDMxOpS3jvBiKudu610OU0lERANWo1rX [email protected]

Bentuknya mirip authorized_keys — hanya kini perannya memverifikasi tanda tangan. Email di awal baris adalah principal: penanda siapa pemilik kunci; pencocokan verifikasi dilakukan terhadap kuncinya, dan principal itulah yang tampil pada keluaran verifikasi, jadi sebaiknya sama dengan email komitter agar hasilnya terbaca wajar. Daftarkan berkasnya:

git config gpg.ssh.allowedSignersFile "$(pwd)/allowed_signers"
git verify-commit HEAD

Good "git" signature for [email protected] with ED25519 key SHA256:BiEFDP5pWAlTuugNXE+8vvdLd145LJGN8TWpMn1GSGg

git log --show-signature kini juga menampilkan verifikasi yang sama. Tag ikut ditandatangani dengan -s dan diverifikasi dengan -v — objeknya sama, verifikasinya lewat berkas yang sama:

git tag -s v1.0.0 -m "Rilis bertanda tangan SSH"
git tag -v v1.0.0

Good "git" signature for [email protected] with ED25519 key SHA256:BiEFDP5pWAlTuugNXE+8vvdLd145LJGN8TWpMn1GSGg
object 0b72e3674f66d8c6fe75f14dd99fd68ad29f424b
type commit
tag v1.0.0
tagger Budi Santoso <[email protected]> 1791902072 +0700

Rilis bertanda tangan SSH

Kunci dan fingerprint pada keluaran di atas berbeda di mesin pembaca — kunci ed25519 selalu baru per pembuatan. Karena tiap orang memelihara berkas kepercayaan sendiri, tim bisa menyimpannya di luar repository, atau repository yang mensyaratkan commit bertanda tangan bisa menyimpannya di dalam repository — sehingga hanya pemegang kunci yang sudah terverifikasi bisa menambah kunci baru.

Mendaftarkan Kunci Penandatangan ke Platform #

GitHub mendukung tanda tangan SSH dengan membedakannya dari kunci akses: di pengaturan akun ada kategori tersendiri SSH signing keys, terpisah dari authentication keys. Kunci publik yang sama bisa didaftarkan ke keduanya, tetapi praktik yang lebih rapi adalah satu kunci khusus penandatanganan — rotasinya tidak mengganggu akses, dan sebaliknya. Setelah kunci terdaftar, platform memverifikasi tanda tangan setiap commit dan tag yang kita dorong serta menampilkan lencana Verified — alur konfigurasinya di dokumentasi penandatanganan SSH GitHub .

GPG atau SSH? #

Pilihannya lurus. Sudah memakai SSH untuk push-pull dan tidak punya kebutuhan lain terhadap GPG? SSH signing menutup kebutuhan penandatanganan tanpa alat baru. Organisasi yang sudah memakai GPG untuk hal lain — enkripsi email, penandatanganan paket — sebaiknya tetap satu jalur di GPG. Keduanya menghasilkan lencana Verified di platform; keduanya menjawab pertanyaan identitas dan integritas dengan sama kuat.

Tanda tangan menjawab “siapa yang menulis ini dan apakah isinya utuh”. Pertanyaan berikutnya berada di ranah yang berbeda — “apa saja yang boleh dilakukan tiap identitas di repository ini” — dan jawabannya adalah prinsip hak akses minimal, pokok bahasan chapter berikutnya.