Sertifikat User SSH Mengikat Kepercayaan CA ke Principal

Mengelola akses SSH dengan public key individual cukup sederhana pada skala kecil. Setiap server dapat menyimpan daftar key yang diterima dalam authorized_keys. Ketika jumlah orang dan host bertambah, kontrol akses juga menjadi persoalan distribusi key: penambahan, rotasi, dan penghapusan identitas membutuhkan perubahan pada mesin yang mempercayainya.

Sertifikat user OpenSSH menawarkan model kepercayaan yang berbeda. Server dapat mempercayai user certification authority (CA), lalu menerima sertifikat user yang ditandatangani CA tersebut ketika sertifikat juga memenuhi policy autentikasi server. Tanda tangan CA hanya menjawab sebagian keputusan. Principal, validity interval, opsi sertifikat, dan konfigurasi server menentukan di mana serta bagaimana key yang ditandatangani dapat digunakan.

Tanda tangan CA bukan pemetaan akun

Sertifikat user OpenSSH memuat public key, metadata identitas, nama principal, validity interval, serta restriction atau permission opsional. CA menandatangani struktur tersebut. Server yang dikonfigurasi dengan TrustedUserCAKeys dapat memverifikasi tanda tangan terhadap public key CA tepercaya.

Verifikasi tersebut menetapkan bahwa sertifikat diterbitkan signer tepercaya dan tidak diubah tanpa membatalkan tanda tangan. Namun, hasil itu sendiri tidak berarti setiap sertifikat dari CA tersebut boleh melakukan autentikasi sebagai setiap akun lokal.

Principal menyediakan ikatan antara identitas sertifikat dan policy akun yang diterapkan sshd. Sertifikat dapat diterbitkan dengan principal eksplisit:

ssh-keygen -s user_ca -I alice-prod -n alice -V +8h alice.pub

Di sini, alice-prod adalah key identifier dan alice adalah principal sertifikat. Identifier berguna untuk identifikasi dan logging; principal ikut menentukan otorisasi.

Policy server menentukan principal yang diterima

Dengan CA yang dikonfigurasi melalui TrustedUserCAKeys, OpenSSH dapat memakai AuthorizedPrincipalsFile untuk mencantumkan nama principal yang diterima bagi akun lokal. Sertifikat harus memuat principal yang cocok ketika mekanisme tersebut dikonfigurasi.

Bentuk konfigurasi server minimal dapat terlihat seperti ini:

TrustedUserCAKeys /etc/ssh/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Untuk akun lokal bernama deploy, file principal dapat memuat:

release-bot
platform-operator

Sertifikat yang membawa release-bot kemudian dapat dipertimbangkan untuk autentikasi ke akun tersebut, tetap tunduk pada policy SSH lainnya. Pola ini memisahkan namespace identitas yang dikodekan dalam sertifikat dari nama akun Unix lokal.

Jika authorized-principals file atau command tidak dikonfigurasi untuk sertifikat yang dipercaya melalui TrustedUserCAKeys, pemeriksaan principal default OpenSSH mengharuskan username target muncul dalam daftar principal sertifikat. Pemetaan principal eksplisit berguna ketika nama identitas dan nama akun tidak seharusnya sama.

Masa berlaku pendek mengurangi ketergantungan pada penghapusan key

Sertifikat dapat membawa validity interval terbatas. Opsi -V pada ssh-keygen menetapkan rentang waktu sertifikat yang ditandatangani dapat diterima. Issuer dapat membuat credential yang dirancang kedaluwarsa setelah periode terbatas, alih-alih memperlakukan setiap public key yang diterbitkan sebagai entri server tanpa batas waktu.

Kedaluwarsa tidak menghilangkan kebutuhan revocation. Sertifikat yang terkompromi mungkin tetap perlu ditolak sebelum validity interval berakhir, sedangkan kompromi private key CA merupakan kejadian terpisah dengan dampak lebih besar. Masa berlaku pendek mempersempit jendela waktu credential yang telah diterbitkan; mekanisme itu tidak membuat revocation atau perlindungan CA menjadi tidak diperlukan.

Private key CA memerlukan kontrol lebih kuat daripada user key biasa karena komprominya dapat memungkinkan penerbitan sertifikat yang mungkin diterima server yang mempercayai CA tersebut. Desain operasional dapat memisahkan signing authority dari host target sehingga host hanya memerlukan public key CA.

Opsi sertifikat membatasi kemampuan sesi

Sertifikat user OpenSSH dapat memuat critical option dan extension. Proses penerbitan, misalnya, dapat memaksa command tertentu atau menghapus kemampuan seperti port forwarding, agent forwarding, alokasi PTY, pemrosesan user RC, atau X11 forwarding.

Sertifikat untuk tugas otomatis dapat dibuat lebih sempit daripada credential operator interaktif:

ssh-keygen -s user_ca \
  -I backup-job \
  -n backup \
  -V +2h \
  -O clear \
  -O force-command=/usr/local/bin/run-backup \
  backup.pub

-O clear menghapus permission default sertifikat sebelum properti terpilih ditambahkan. Forced command mengubah apa yang dapat dijalankan sesi terautentikasi. Restriction yang tepat tetap harus sesuai dengan desain layanan; forced command bukan pengganti pengamanan program yang dipanggil beserta input-nya.

Critical option dan extension juga memiliki semantik kompatibilitas berbeda. Implementasi yang tidak mengenali critical option harus menolak sertifikat, sedangkan extension yang tidak dikenali dapat diabaikan. Perbedaan ini penting saat menetapkan policy sertifikat kustom.

Cakupan principal berada pada boundary penerbitan

CA dengan kewenangan penerbitan terlalu luas dapat menyatukan beberapa trust boundary yang semula terpisah. Jika signer yang sama dapat menerbitkan principal apa pun untuk production, development, automation, dan akun administratif, penguasaan signing authority tersebut membawa gabungan jangkauan namespace itu.

Format sertifikat tidak dapat mengimbangi issuer yang memberikan principal terlalu luas. Signing service harus mengautentikasi pemohon, menentukan principal yang boleh diterima pemohon, memilih validity interval yang sesuai, dan menerapkan opsi wajib sebelum penandatanganan.

Dengan demikian, policy CA merupakan bagian dari sistem kontrol akses, bukan sekadar langkah mekanis untuk menandatangani key. Permintaan sertifikat yang mewakili release-bot perlu dinilai sebagai permintaan atas identitas tersebut, bukan sekadar permintaan menandatangani public key.

Host certificate menangani arah autentikasi yang berbeda

OpenSSH juga mendukung host certificate. Host certificate memungkinkan client mengautentikasi host server melalui host CA tepercaya. Sertifikat user bekerja ke arah sebaliknya: server mengautentikasi user yang terhubung melalui user CA tepercaya.

Pemisahan kedua peran itu membuat analisis trust lebih jelas. Key yang dipercaya untuk mengesahkan host tidak otomatis memerlukan kewenangan untuk mengesahkan user, dan deployment dapat memakai CA key terpisah untuk kedua tujuan.

Boundary yang berguna adalah CA beserta policy

Sertifikat SSH mengurangi kebutuhan menyalin public key user individual ke setiap server, tetapi sentralisasi mengubah failure model. CA menjadi authority bernilai tinggi, penerbitan principal menjadi keputusan otorisasi, dan pemetaan di sisi server tetap menjadi bagian enforcement.

Deployment yang kuat menjaga tanggung jawab tersebut tetap eksplisit: lindungi private key CA, terbitkan hanya principal yang diizinkan, gunakan validity interval terbatas yang sesuai dengan jalur akses, batasi kemampuan sertifikat ketika diperlukan, dan konfigurasikan server agar hanya menerima pemetaan principal yang dituju. Hasil akhirnya bukan kepercayaan pada tanda tangan semata, melainkan kepercayaan pada identitas bertanda tangan yang dibatasi oleh policy SSH lokal.

References

Cybersecurity OpenSSH SSH Sertifikat