git pull GitHub di laptop yang tidak diubah tiba-tiba gagal, tetapi setelah membuat file .pub yang berpasangan dengan kunci privat, autentikasi kembali berhasil
- Jika ada file
.pub, OpenSSH lebih dulu mengajukan kunci publik, mendapat persetujuan, lalu menandatangani; jika tidak ada, OpenSSH langsung mengirim permintaan autentikasi yang telah ditandatangani
- Kedua alur ini sama-sama sesuai dengan RFC 4252 dan
sshd biasa juga mengizinkannya, tetapi frontend SSH GitHub saat itu tampaknya tidak menerima permintaan bertanda tangan langsung
- Dalam 12 uji terkontrol, 6 percobaan tanpa file
.pub semuanya ditolak, dan 6 percobaan dengan file tersebut semuanya berhasil
- Dari perubahan banner server dapat diduga ada kemungkinan perubahan perangkat lunak di sisi server, tetapi karena penyebab pastinya tidak terkonfirmasi, lebih aman untuk tetap menyimpan file kunci publik pasangannya
Kegagalan autentikasi mendadak dan solusinya
- Di laptop utama,
git pull terhenti dengan error Permission denied (publickey)
- Kunci tersebut masih terdaftar di GitHub
- Di laptop lain yang memakai kunci berbeda, repository yang sama masih bisa diambil dengan normal
- Tidak ditemukan kejanggalan pada kunci maupun konfigurasi klien
openssl rsa -check mengembalikan RSA key ok
- Sedang menggunakan algoritme tanda tangan terbaru,
rsa-sha2-512
- Tidak ada masalah di
~/.ssh/config dan halaman status GitHub juga normal
- Setelah instal ulang, file kunci publik yang berpasangan dengan
~/.ssh/github_rsa hilang, dan setelah dibuat dengan perintah berikut autentikasi pun berhasil
ssh-keygen -y -f ~/.ssh/github_rsa > ~/.ssh/github_rsa.pub
- Dalam uji terkontrol, 6 percobaan tanpa file
.pub semuanya gagal, sedangkan 6 percobaan dengan file tersebut semuanya berhasil
Alur autentikasi yang berubah tergantung file .pub
- OpenSSH memakai alur autentikasi kunci publik yang berbeda tergantung ada atau tidaknya file
.pub
- Jika file ada, kunci publik diajukan lebih dulu lalu menunggu persetujuan server sebelum menandatangani
- Jika hanya ada kunci privat, pemeriksaan awal dilewati dan permintaan autentikasi bertanda tangan lengkap langsung dikirim
- Kedua cara ini sama-sama diizinkan oleh RFC 4252, dan
sshd biasa menerima keduanya
- Di GitHub saat itu, permintaan kunci publik bertanda tangan langsung ditolak, tetapi apakah benar ada perubahan di pihak GitHub belum dapat dipastikan
- Banner server di log debug tidak lagi memakai format
babeld-<hash>, melainkan muncul sebagai 6a2c000
- Kemungkinan perangkat lunak server baru menolak permintaan bertanda tangan langsung masih sebatas dugaan
- Untuk menghindari masalah yang sama, sebaiknya tetap simpan file
.pub yang berpasangan dengan kunci privat
1 komentar
Pendapat di Lobste.rs
Saya mengalami masalah yang sama selama 4 jam terakhir, dan ini sudah tercatat di https://www.githubstatus.com/incidents/g40zcbvchny4
Beberapa minggu lalu saat mengganti kunci SSH, saya tidak menghapus file
.publama yang diabaikan Git, dan meski terhubung dengan kunci baru tetap terus gagalBaru setelah menyalakan beberapa opsi debug saya menyadari klien SSH mengirim fingerprint lama, dan saya bahkan tidak tahu OpenSSH membaca file
.pub; selama ini saya menganggapnya file yang sepenuhnya tidak perluHari ini server CI saya tampaknya mengalami gangguan yang sama dan tiba-tiba tidak bisa terhubung ke github.com
Setelah mengganti kunci ke kunci ed25519 yang benar, semuanya berfungsi lagi, tetapi kunci ini juga tidak punya file
.pubpasangannya jadi saya tidak tahu kenapa itu memperbaikinyaSaya mengalami masalah yang sama hari ini, dan setahu saya tidak ada pengumuman dari GitHub bahwa mereka berencana mengubah perilaku autentikasi SSH
Saya kehilangan password dan recovery key, lalu menjalani prosedur pemulihan akun berbasis kunci SSH, tetapi GitHub membuat kunci SSH itu kedaluwarsa sehingga saya kehilangan akses ke akun sepenuhnya
Selama 7~8 tahun saya rasa saya tidak pernah menyimpan file
.pub, jadi semoga masalah ini sudah diperbaiki sebelum saya memakai GitHub lagi nantiJika kedua alur autentikasi sama-sama sah, saya jadi bertanya-tanya kenapa alur penemuan kunci itu ada
Sepertinya hanya memicu perilaku aneh seperti ini, dan kalau kunci publik memang bisa dibuat dari kunci privat, rasanya SSH bisa menanganinya otomatis
SSH lebih dulu memeriksa kunci mana yang akan diterima server, agar pengguna tidak perlu mendekripsi kunci yang pasti gagal untuk autentikasi
Perilaku ini juga punya efek samping aneh seperti https://github.com/FiloSottile/whoami.filippo.io, jadi perlu juga mengizinkan cara autentikasi yang hanya bisa dicoba jika server sudah mengetahui kunci publik klien sebelumnya, untuk berjaga-jaga saat pengguna tanpa sengaja terhubung ke server yang salah
Akun Office 365 kantor saya juga tiba-tiba berhenti bekerja hari ini, pertama kalinya dalam 5 tahun
Saya jadi penasaran apakah Microsoft mengalami insiden kompromi lalu melakukan salting ulang untuk semuanya, atau ini hanya terjadi pada pengguna Eropa karena pemungutan suara Chat Control 1.0 baru-baru ini
Saya juga cukup berhak menyatakan itu dengan tegas, sebagai satu dari dua orang yang saya tahu pernah bekerja baik di Git Systems GitHub maupun di lini produk Office/M365 Microsoft
Bahkan jika penyebabnya adalah perubahan kebijakan atau teknologi yang berlaku sama pada kedua layanan, sistemnya terpisah sehingga kemungkinan dirilis pada hari yang sama sangat kecil