Sertifikat SSH: Pengalaman SSH yang Lebih Baik

 (jpmens.net)
6 poin oleh GN⁺ 18 hari lalu | 1 komentar | Bagikan ke WhatsApp
  • Sertifikat SSH mengatasi kerumitan autentikasi SSH berbasis kunci publik yang ada, serta menyediakan kepercayaan otomatis antara klien dan server
  • Didukung mulai OpenSSH 5.4, dan CA (otoritas sertifikat) menandatangani kunci pengguna maupun host sehingga autentikasi dimungkinkan tanpa perlu mengubah authorized_keys
  • Sertifikat dapat memuat masa berlaku, pengguna yang diizinkan (principal), IP akses, perintah paksa (force-command), dan lain-lain untuk mendukung kontrol akses yang rinci
  • Prosedur TOFU (Trust on First Use) dihilangkan, sehingga saat kunci host berubah, koneksi tetap bisa dilakukan dengan aman tanpa peringatan
  • Dengan memanfaatkan server atau alat penandatanganan otomatis, otomatisasi pengelolaan SSH di lingkungan server skala besar dan peningkatan keamanan menjadi mungkin

Ikhtisar sertifikat SSH dan keterbatasan autentikasi SSH berbasis kunci yang ada

  • Saat membuat koneksi SSH, kita perlu memeriksa fingerprint kunci host dari server yang pertama kali diakses, tetapi kebanyakan pengguna tidak memverifikasinya dan memakai pendekatan TOFU (Trust on First Use) dengan mengetik yes
    • Administrator dapat memverifikasi fingerprint server secara langsung atau dengan perintah ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key
  • Autentikasi berbasis kunci publik memungkinkan login tanpa kata sandi, tetapi kunci publik harus didistribusikan ke file authorized_keys di setiap server
  • Dengan SSH agent (ssh-agent), kunci privat dapat disimpan di memori sehingga autentikasi bisa dilakukan berulang kali tanpa input berulang
  • Keterbatasan pendekatan yang ada
    • Perlu menyalin kunci publik ke server untuk setiap pengguna
    • Saat kunci host berubah, pesan peringatan muncul di sisi klien
    • Pengelolaan kepercayaan menjadi tidak praktis karena TOFU

Sertifikat SSH dan CA (otoritas sertifikat)

  • Sertifikat SSH (Certificate) didukung mulai OpenSSH 5.4 (Maret 2010), dengan struktur yang memperluas format kunci SSH yang ada
  • SSH CA terdiri dari pasangan kunci SSH, dan kunci publiknya berperan sebagai root of trust
  • Keunggulan utama
    • Tidak perlu mengubah file authorized_keys di server
    • Tidak ada peringatan saat kunci host diganti
    • Kepercayaan otomatis terwujud dengan menghilangkan prosedur TOFU
    • Sertifikat dapat memuat pengguna yang diizinkan (principal), IP yang diizinkan, masa berlaku, perintah paksa (force-command), dan lain-lain
    • Akses diblokir otomatis saat sertifikat kedaluwarsa

Membangun SSH CA dan prosedur penandatanganan

  • Di sistem CA, buat pasangan kunci CA dengan algoritme ECDSA
    • ssh-keygen -t ecdsa -C "SSH CA" -f CA/ssh-ca
  • Pengguna mengirimkan kunci publiknya (*.pub) ke CA, lalu CA menandatanganinya (sign) dan menerbitkan sertifikat (*-cert.pub)
    • Contoh: ssh-keygen -s CA/ssh-ca -I "Jane Jolie" -n jane -z 001 -V +1w jane.pub
  • Konfigurasi server
    • Simpan kunci publik CA di /etc/ssh/ssh-ca.pub lalu tambahkan pengaturan TrustedUserCAKeys
    • Tanda tangani kunci host server dengan CA (ssh-keygen -h -s CA/ssh-ca ...) lalu daftarkan pada entri HostCertificate
  • Konfigurasi klien
    • Tambahkan satu baris @cert-authority ke file known_hosts
    • Contoh: @cert-authority *.example.com $(cat CA/ssh-ca.pub)

Koneksi dan verifikasi berbasis sertifikat SSH

  • Pengguna terhubung dengan memakai sertifikat yang sudah ditandatangani bersama kunci privat (ssh -i jane -l jane alice.example.com)
  • Log server mencatat ID, serial number, fingerprint CA dari sertifikat
  • Beberapa nama host atau IP dapat ditambahkan sebagai principal dalam sertifikat
  • Jika mencoba login sebagai pengguna selain principal yang ditentukan di sertifikat, akan muncul galat “Certificate invalid: name is not a listed principal”
  • Dengan menetapkan perintah paksa (force-command) atau IP yang diizinkan (source-address) di sertifikat, kontrol akses yang rinci dapat diterapkan

Checklist pemeriksaan dan pemecahan masalah

  • Hal yang perlu diperiksa di sisi server

    • Pengaturan TrustedUserCAKeys dan keberadaan kunci publik CA
    • Penandatanganan kunci host dan penetapan HostCertificate
    • Perlu me-restart sshd

  • Hal yang perlu diperiksa di sisi klien

    • Kunci pengguna harus sudah ditandatangani oleh CA
    • Entri @cert-authority di known_hosts harus cocok dengan principal
    • Jika sertifikat kedaluwarsa, pesan “Certificate invalid: expired” akan ditampilkan
    • Jika batasan sertifikat tidak cocok, permintaan kata sandi akan muncul
    • Saat sertifikat ditambahkan ke SSH agent, kunci dan sertifikat sama-sama terdaftar (ssh-add jane)
    • Fitur dapat dikendalikan dengan opsi (-O) saat penandatanganan
    • Contoh: gunakan -O clear untuk menghapus semua izin lalu izinkan hanya permit-agent-forwarding dan permit-port-forwarding

Otomatisasi sertifikat kunci host

  • Membangun server penandatanganan otomatis (hkbot) dengan modul Python sshkey-tools dan BottlePy
    • Jalankan hkbot.py di server CA, lalu unggah kunci publik host melalui permintaan HTTP untuk penandatanganan otomatis
    • Di klien, instal otomatis dengan perintah curl -F hostkey=@/etc/ssh/ssh_host_ed25519_key.pub http://CA:8870 | sh
    • Terapkan dengan mengubah /etc/ssh/sshd_config, memverifikasi, lalu menjalankan systemctl restart sshd
  • Setelah itu, koneksi SSH dapat dilakukan dengan kepercayaan otomatis dan login berbasis sertifikat

Ringkasan keunggulan sertifikat SSH

  • Tidak memerlukan TOFU, ada kepercayaan otomatis antara klien dan server
  • Dengan penerbitan sertifikat berumur pendek, kontrol akses sementara dapat diterapkan
  • Saat sertifikat kedaluwarsa, akses diblokir otomatis tanpa perlu merapikan authorized_keys
  • Kebijakan rinci dapat diatur, seperti perintah paksa, pembatasan PTY, kontrol IP akses
  • Dengan alat otomatisasi, pengelolaan lingkungan server skala besar dapat disederhanakan
  • Smallstep SSH diperkenalkan sebagai proyek terkait

Referensi tambahan

Pembaruan

  • SSH CA sangat berguna terutama di lingkungan yang memiliki server sendiri dan akses root
  • Pada sistem multi-pengguna, pendekatan known_hosts dan authorized_keys yang ada masih tetap diperlukan
  • Draf standardisasi format sertifikat SSH: draft-miller-ssh-cert-06

Bacaan terkait

1 komentar

 
GN⁺ 18 hari lalu
Komentar Hacker News

  • Mengejutkan bahwa orang masih memakai kata sandi SSH
    Terutama di lingkungan perusahaan besar, berbagai kebijakan kata sandi saling bertumpuk sehingga hanya untuk masuk ke server saja bisa makan waktu lama
    Jadi meskipun diberi tahu untuk memakai kunci lewat ssh-keygen, kebanyakan orang hanya berpikir “nanti suatu saat harus dicoba” lalu akhirnya tidak pernah melakukannya

    • Kunci berguna ketika ada sistem pengelolaan terpusat di tingkat pribadi atau perusahaan
      Namun dalam praktiknya, satu kunci publik sering dipakai di banyak server, atau kunci dibagikan, sehingga pengelolaannya mudah berantakan
      Setidaknya kata sandi punya kelebihan karena sederhana
    • Saya sudah bertahun-tahun mengelola kunci SSH dengan HSM berbasis Yubikey
      Tidak ada kata sandi, tetapi saat login harus menyentuh Yubikey secara fisik
    • Penggunaan kunci terdistribusi seperti ssh-copy-id memudahkan peretas bergerak lateral di dalam jaringan, jadi banyak organisasi melarangnya

  • Setiap beberapa bulan, seseorang kembali menemukan sertifikat SSH lalu menulis posting blog tentang itu
    Saya juga menulis artikel terkait 15 tahun lalu, dan kalau dilihat sekarang rasanya masih kurang

    • Banyak orang bingung membedakan kunci dan sertifikat
      Bahkan engineer keamanan pun kadang lupa bahwa yang mereka pakai adalah autentikasi kunci, bukan sertifikat SSH
    • Sertifikat SSH berguna karena bisa memberi akses ke pengguna tertentu dengan masa berlaku dan izin terbatas
    • Saya juga sudah tahu soal sertifikat SSH, tetapi belum berhasil pindah dari sistem berbasis kunci
      Mengelola kunci banyak server secara manual terlalu merepotkan
      Sekarang saya sedang mempertimbangkan apakah masih layak beralih
    • Saat tempat kerja saya membuat SSH CA 10 tahun lalu, kami merujuk ke posting blog di atas

  • Pendekatan TOFU(Trust On First Use) itu sederhana, tetapi cukup efektif
    Di server saya, setelah saya memverifikasi host key secara langsung, itu sudah cukup
    Di lingkungan perusahaan besar, daftar kunci publik server internal bisa dipasang di situs internal yang ditandatangani dengan SSL
    Namun di lingkungan dengan banyak server atau server yang sering berubah, sertifikat jauh lebih baik, dan TOFU punya batasan di banyak sisi
    Saya juga berharap browser punya fitur untuk memberi tahu ketika kunci TLS server berubah

    • Saya sudah memakai SSH sejak 1996, tetapi belum pernah melihat orang benar-benar memverifikasi kunci publik secara manual
      Kebanyakan hanya mengetik “yes” dan lanjut

  • Di kantor, kami membuang sangat banyak waktu dan uang gara-gara inspeksi SSL Zscaler
    Kalau muncul error “self-signed certificate in certificate chain”, itu selalu bikin pusing

    • Saya menganalisis Zscaler yang terpasang di Windows 11 milik perusahaan teman, dan itu hampir setara malware
      Ia menanam root certificate sendiri dan mengunci pengaturan browser agar proxy tidak bisa dipakai
      Bahkan jika file konfigurasi Firefox atau Chrome diubah, perubahan itu langsung ditimpa lagi
      Bahkan untuk mematikannya lewat GUI pun perlu kata sandi IT
      Sedikit lebih baik daripada antivirus Cybereason
    • Cisco Umbrella di perusahaan kami juga sama
      Itu merusak semua protokol berbasis HTTP
      Git, RubyGems, go mod, Nix, dan banyak tool lain jadi rusak
      Vendornya bilang ini “transparan”, padahal sama sekali tidak
      Mendiagnosis masalah seperti ini butuh waktu berjam-jam, dan kebanyakan admin tidak paham seberapa destruktif dampaknya
    • Sebagai catatan, sertifikat SSH berbeda dari sertifikat X.509

  • Artikel itu hanya menyebut kelebihan sertifikat CA, tetapi jelas ada juga kekurangannya
    Saya pribadi belum pernah mengalami masalah keamanan akibat TOFU

    • Logika “tidak pernah ada insiden, jadi aman” itu sama seperti bilang tidak perlu pakai sabuk pengaman
      Kalau memang ada kekurangan sertifikat SSH, saya penasaran apa saja secara konkret
    • TOFU itu praktis, tetapi bukan keharusan
      Jika ingin memperkuat keamanan, kunci publik bisa ditukar lewat kanal aman seperti USB
      Kalaupun memakai sertifikat, pada akhirnya prosedurnya tetap sama, hanya pengelolanya berpindah dari pengguna ke admin
      Di organisasi skala besar, sertifikat bisa berguna, tetapi dari sisi keamanan umum tetap setara
    • Jika konfigurasi CA bisa disiapkan sebelumnya, TOFU dapat dihindari
      Tinggal masukkan ke skrip instalasi atau image deployment
      TOFU hanya relevan saat mengakses box yang sudah telanjur disiapkan
    • “Belum pernah ada insiden keamanan karena TOFU” hanya berarti belum terjadi sejauh ini

  • Di lingkungan dev/stg kami, setengah dari mesin diinstal ulang setiap hari
    Berkat sertifikat host SSH, kami tidak perlu lagi menghapus known_hosts atau mempertahankan kunci, jadi jauh lebih praktis

  • Sebagai proyek pribadi, saya sedang membuat tool bernama Sshifu
    Ini adalah tool yang mempermudah login berbasis sertifikat SSH dan SSO
    Cukup pasang sshifu-server di server untuk dipakai sebagai CA, lalu atur setiap server SSH agar memercayai CA tersebut
    Pengguna tinggal login dengan perintah npx sshifu
    Lihat repositori GitHub

  • Di lingkungan operasional nyata, akses berbasis sertifikat justru sering berujung pada masalah pengelolaan yang kompleks
    Ada banyak isu seperti sertifikat kedaluwarsa, penghapusan pengguna, atau login saat server bermasalah
    Userify sudah 15 tahun menangani masalah seperti ini, dan membangun infrastruktur autentikasi SSH yang stabil itu sama sekali tidak sederhana

    • Tetapi menurut saya model SaaS adalah pilihan terburuk

  • Saya menambahkan dukungan sertifikat SSH ke pico.sh, dan itu sangat berguna karena memungkinkan implementasi kontrol akses gaya RBAC
    Lihat dokumentasi

  • Di produksi, sertifikat SSH justru memusatkan kompleksitas dan memperbesar masalah
    Satu CA tunggal harus selalu tersedia, dan jika gagal maka seluruh akses ikut terblokir
    Ada juga masalah nyata seperti pengaturan TTL, pengelolaan root of trust, dan sulitnya debugging
    Pada akhirnya orang-orang memasang kembali cache atau agent
    Kami justru melakukan kebalikannya: tiap node menyinkronkan info pengguna lewat HTTPS ke authorized_keys lokal
    Dengan begitu kontrol terpusat tetap ada, tetapi kegagalan bersifat lokal
    Userify memakai pendekatan ini, dan menangani bukan hanya autentikasi tetapi juga manajemen izin
    Sertifikat saja tidak menyelesaikan masalah seperti pembuatan pengguna, peran sudo, atau pembersihan home directory

    • Ada yang bertanya bagaimana cara menangani TOFU