GitHub akan mengubah sejumlah aturan SSH untuk mengurangi ketergantungan pada algoritma lama. Mulai 14 Oktober 2026, semua kunci SSH RSA baru yang diunggah ke GitHub harus berukuran minimal 3072 bit. GitHub juga menjadwalkan penghapusan tanda tangan RSA berbasis SHA-1 dan mekanisme pertukaran kunci `diffie-hellman-group-exchange-sha256`, dengan masa uji gangguan layanan pada November dan Desember.

Pengumuman ini terutama menyasar pengguna yang mengakses repository GitHub melalui SSH. Jika remote repository Anda memakai alamat `https://`, perubahan tersebut tidak memengaruhi jalur Git itu. Sebaliknya, pengguna dengan remote `[email protected]:...`, sistem CI lama, library SSH yang tertanam di aplikasi, atau perangkat build yang jarang diperbarui perlu memeriksa kompatibilitasnya.

## Yang berubah pada 14 Oktober

Perubahan paling mudah dipahami adalah ukuran kunci RSA baru. Setelah 14 Oktober, GitHub mensyaratkan RSA minimal 3072 bit untuk kunci yang baru diunggah, baik untuk penandatanganan maupun autentikasi. Kebijakan ini tidak berarti semua kunci RSA lama harus langsung diganti. GitHub menjelaskan bahwa kunci RSA yang sudah ada tetap dapat digunakan selama client dan library SSH memilih algoritma tanda tangan RSA dengan SHA-2, yaitu `rsa-sha2-256` atau `rsa-sha2-512`.

Perbedaan antara nama kunci dan algoritma tanda tangan penting di sini. `ssh-rsa` dapat dipakai untuk menyebut tipe kunci RSA secara umum, tetapi pada konteks tanda tangan ia juga merujuk pada penggunaan SHA-1. GitHub sedang menghapus penggunaan SHA-1 tersebut karena dianggap terlalu lemah untuk kebutuhan keamanan saat ini. Jadi, memiliki berkas kunci RSA tidak otomatis berarti koneksi akan gagal; yang menentukan adalah algoritma tanda tangan yang dinegosiasikan oleh client.

GitHub menyebut OpenSSH 7.2p1 sebagai versi minimum yang mendukung RSA dengan SHA-2 secara memadai dalam konfigurasi default. Daftar yang sama mencantumkan JSch 0.1.66 dari fork tertentu, TeamCity 2021.2.3, Go SSH 0.16.0, libssh2 1.11.0, dan PuTTY 0.82. Angka-angka ini bukan rekomendasi untuk menahan upgrade sampai batas minimum. Untuk mesin build dan server yang penting, versi terbaru dari sistem operasi, Git, OpenSSH, dan library terkait tetap pilihan yang lebih aman.

## Brownout akan menjadi peringatan sebelum penghapusan

Sebelum algoritma lama dihapus, GitHub menjadwalkan brownout—periode ketika dukungan sengaja dimatikan sementara untuk memperlihatkan client yang masih bergantung padanya. Brownout pertama dijadwalkan pada 4 November 2026, lalu yang kedua pada 9 Desember 2026. Keduanya berkaitan dengan `ssh-rsa` berbasis SHA-1 dan `diffie-hellman-group-exchange-sha256`.

GitHub tidak menampilkan jadwal ini sebagai masalah untuk semua pengguna. Dokumen resminya menyebut hanya koneksi Git melalui SSH dan beberapa penggunaan protokol Git tanpa autentikasi di GitHub Enterprise Server yang terdampak. Namun, kegagalan biasanya muncul di tempat yang tidak terlihat oleh pengembang sehari-hari: job CI yang menggunakan image lama, runner internal yang tidak pernah di-upgrade, plugin Java yang membawa JSch versi lawas, atau perangkat yang masih memakai libssh2 lama.

Halaman pengumuman GitHub juga memuat satu tanggal yang tidak konsisten: baris terakhir jadwal mencantumkan 13 Januari 2026 sebagai tanggal penghapusan, padahal pengumuman diterbitkan pada 22 September 2026 dan tanggal tersebut sudah lewat. Karena itu, tanggal penghapusan final tidak sebaiknya dijadikan dasar perencanaan sebelum GitHub memperjelasnya. Dua tanggal brownout dan batas 14 Oktober adalah bagian jadwal yang masih dapat diverifikasi langsung dari pengumuman yang sama.

## Ada dukungan pertukaran kunci pascakuantum

Perubahan ini bukan hanya penghapusan algoritma lama. GitHub juga mengatakan akan mendukung metode pertukaran kunci `mlkem768x25519-sha256` untuk sesi SSH di github.com dan GitHub Enterprise Cloud dengan Data Residency, kecuali region Amerika Serikat. ML-KEM dirancang untuk membantu menghadapi ancaman komputer kuantum terhadap mekanisme kriptografi yang lebih lama.

Bagi kebanyakan pengguna, penambahan ini tidak membutuhkan konfigurasi manual. GitHub mengatakan client SSH akan memilih algoritma baru bila dikonfigurasi untuk memprioritaskannya, sementara client yang lebih lama dapat turun ke algoritma lain yang masih didukung. Artinya, manfaatnya akan bergantung pada kemampuan client, library, dan kebijakan server—bukan hanya pada perubahan di sisi GitHub.

## Apa yang perlu dilakukan sekarang

Langkah pertama adalah memeriksa remote repository dan versi perangkat yang dipakai dalam alur kerja. Remote dengan awalan `https://` berada di luar perubahan SSH ini, sedangkan remote `[email protected]:` perlu diuji pada semua lingkungan, bukan hanya laptop pengembang. Periksa runner CI, image Docker, plugin build, server deployment, serta tool yang mengakses GitHub melalui library SSH sendiri.

Jika menggunakan RSA lama, jangan langsung menghapus kunci. Pastikan client memakai `rsa-sha2-256` atau `rsa-sha2-512`. Untuk kunci baru, GitHub merekomendasikan Ed25519 bila kompatibilitas sistem memungkinkan. RSA tetap dapat dipilih untuk sistem legacy, tetapi ukurannya harus minimal 3072 bit setelah kebijakan baru berlaku.

Perubahan ini sebaiknya diperlakukan sebagai pekerjaan inventarisasi, bukan sekadar perintah membuat kunci baru. Mengganti kunci di laptop tetapi melupakan deploy key, secret CI, atau akun service hanya memindahkan masalah ke jalur lain. Tim juga perlu mencatat fingerprint, pemilik, lokasi penggunaan, dan cara pemulihan setiap kredensial SSH sebelum melakukan rotasi.

GitHub sedang mendorong ekosistemnya menjauh dari SHA-1 dan pertukaran kunci lama, sambil membuka jalan untuk algoritma yang lebih tahan terhadap perkembangan komputasi. Dampak langsungnya mungkin kecil bagi repository yang memakai tool modern. Namun, brownout pada November dan Desember akan menjadi tes nyata bagi sistem lama yang selama ini bekerja tanpa pernah diperiksa ulang.

Sumber utama: - GitHub Changelog, “Security improvements for SSH” (22 September 2026): https://github.blog/changelog/2026-09-22-security-improvements-for-ssh/

Sumber tambahan: - GitHub Docs, “Checking for existing SSH keys”: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/checking-for-existing-ssh-keys?platform=linux - GitHub Docs, “Generating a new SSH key and adding it to the ssh-agent”: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent?platform=windows