it-swarm-id.com

Kunci ECDSA Berubah, SSH tidak aman sekarang?

Saya menjalankan beberapa server Ubuntu yang tidak penting di kamar asrama saya di kampus. Matikan sebelum jeda, kembali, masuk SSH, dan dapatkan peringatan bahwa kunci ECDSA telah berubah.

Itu terlihat seperti ini

Warning: the ECDSA Host key for '<snip>' differs from the key for the IP address '<snip>'
Offending key for IP in /home/<snip>/.ssh/known_hosts:14
Matching Host key in /home/<snip>/.ssh/known_hosts:12
Are you sure you want to continue connecting (yes/no)?

Ini terlihat jauh lebih menakutkan daripada kesalahan identitas server berubah jadi saya tidak terlalu khawatir tapi tetap saja, apa yang akan menyebabkan ini berubah? Apakah ini sesuatu yang harus saya khawatirkan?

29
TheLQ

Saat Anda terhubung pertama kali ke server SSH yang diberikan, Anda mendapatkan pertanyaan yang biasa dengan sidik jari kunci; setelah itu, klien SSH menyimpan salinan kunci publik server dalam file .ssh/known_hosts. Tetapi klien SSH sebenarnya menyimpan dua kunci: satu untuk server nama , dan satu untuk server [~ # ~] ip [~ # ~] .

Sebagai contoh, asumsikan server foo.example.com memiliki IP 10.0.0.8. Setelah koneksi pertama Anda (ssh foo.example.com), klien SSH akan mendapatkan kunci publik server, menampilkan sidik jari (hash kunci publik), meminta konfirmasi, dan kemudian menyimpan dalam file known_hosts dua pemetaan, satu untuk foo.example.com, yang lain untuk 10.0.0.8, keduanya menunjuk ke kunci publik yang sama.

Saat Anda terhubung kembali ke server yang sama, SSH memverifikasi dua pemetaan. Jika pemetaan pertama (satu untuk nama) menghasilkan kunci publik yang berbeda dari yang direkam dalam known_hosts, Anda mendapatkan pesan galat menakutkan dengan SURAT UPPERCASE (begitulah cara mengaturnya menjadi menakutkan), dan klien menolak untuk terhubung lebih jauh (jadi pesannya tidak hanya menakutkan, juga cukup merepotkan).

Situasi lain adalah ketika pemetaan pertama cocok:

  • Jenis pengguna: ssh foo.example.com.
  • Sistem DNS menyelesaikan nama itu menjadi IP 10.0.0.8.
  • Klien SSH terhubung ke mesin itu, dan memperoleh kunci publik server SSH.
  • Kunci publik yang diperoleh cocok dengan yang ditemukan di .ssh/known_hosts di bawah entri foo.example.com.
  • [~ # ~] tetapi [~ # ~] kunci publik yang diperoleh tidak [~ # ~] bukan [ ~ # ~] cocok dengan yang ditemukan di .ssh/known_hosts di bawah entri 10.0.0.8.

Dalam hal ini, Anda mendapatkan pesan persis yang Anda tampilkan di pertanyaan Anda. Klien SSH memiliki kepastian bahwa Anda berbicara dengan server yang dimaksud - kunci publik cocok dengan yang direkam untuk server yang sama nama - tetapi sesuatu masih salah, maka peringatan, dan konfirmasi Prompt.

Ini bisa terjadi ketika IP server telah berubah. Dengan contoh di atas, anggaplah bahwa, minggu lalu, foo.example.com memiliki IP 10.0.0.7, tetapi bar.example.com memiliki IP 10.0.0.8. Saat itu, Anda terhubung ke keduanya. Tapi akhir pekan lalu, seorang sysadmin dengan sedikit gangguan obsesif obsesif memutuskan bahwa beberapa IP harus diubah, sehingga ia dapat membuat aturan jaringan yang lebih efisien, teratur, dan matematis. Jadi dia "memindahkan server", dan mengatur bar.example.com ke IP 10.0.0.16 dan foo.example.com ke 10.0.0.8. Teman kami sysadmin dengan patuh mengkonfigurasi DNS untuk melaporkan IP baru. Sekarang, kami berada di hari Senin, dan Anda ingin terhubung lagi. Klien SSH Anda berbicara dengan DNS, mendapatkan IP baru untuk foo.example.com, dan semuanya baik-baik saja, kecuali bahwa kunci yang direkam untuk 10.0.0.8 tidak cocok dengan kunci publik foo.example.com: memang, file known_hosts Anda berisi salinan kunci publik dari bar.example.com, yang tercantum di bawah IP 10.0.0.8, yang , hingga minggu lalu, adalah IP bar, bukan IP foo.

Sysadmin dengan OCD tidak sepenuhnya diperlukan untuk skenario ini; itu juga bisa terjadi dengan pengaturan IP dinamis, atau dengan beberapa kasus load-balancing.

Solusi: gunakan editor teks dan hapus entri yang menyinggung dari known_hosts Anda (baris 14, dalam kasus Anda). Anda juga dapat menggunakan perintah ssh-keygen -R <Host> untuk menghapus entri tertentu. Lain kali Anda akan terhubung, klien akan menampilkan peringatan lain (kali ini mengeluh tentang tidak adanya dari setiap kunci publik yang direkam untuk IP target), tetapi yang ini akan terbang hampir tanpa disadari, karena tidak akan ada Prompt sama sekali. Klien SSH kemudian akan merekam kunci publik lagi di known_hosts, dan mengatur semuanya dengan benar, setidaknya sampai sysadmin mendengar suara lagi .

Sebagai alternatif, nonaktifkan pemeriksaan Host IP di klien SSH, dengan mengatur opsi CheckHostIP ke no (dalam sistem /etc/ssh/ssh_config, atau .ssh/config Anda, atau secara langsung pada baris perintah: ssh -o CheckHostIP=no foo.example.com). Pemeriksaan host-IP berguna untuk mendeteksi situasi abnormal dari nama server yang berkeliaran, tetapi untuk beberapa sysadmin, server IP jugglery sangat "normal".

41
Tom Leek

Dengan asumsi saya menebak <snip> bagian dengan benar, terlihat seperti nama host (example.com) sekarang memutuskan untuk IP yang berbeda dari sebelumnya.

Apakah Anda perlu khawatir atau tidak sulit untuk mengetahui tanpa informasi lebih lanjut. Apa nama hostnya? Apakah ini FQDN? Apakah ini diselesaikan menggunakan DNS? Apakah Anda melakukan perubahan DNS? Informasi seperti itu.

Mungkin lebih baik jika Anda mengganti nama host dan IP Anda dengan contoh (example.com, example.net, example.org dan anything-you-want.test baik untuk nama host, IP pribadi seperti 192.168.foo.bar atau 10.foo.bar.baz bagus untuk IP), dengan cara itu output perintah lebih mudah diinterpretasikan. Anda juga dapat menggunakan ini untuk menunjukkan apakah dua domain berada dalam TLD yang sama, apakah dua IP berada di subnet yang sama, dll. Sehingga sangat berguna.

10
Jerome Baum

Jika IP tidak dipindahkan dan paket openssh-server tidak ditingkatkan dan kunci Host baru dibuat, lalu apa yang terjadi?

Meskipun Anda dapat menonaktifkan pemeriksaan kunci Host, ini bukan praktik yang akan saya mulai.

Apa yang tampaknya telah terjadi adalah bahwa ssh sekarang menggunakan sistem kunci Host yang berbeda (ECDSA vs DSA atau RSA) dan peringatan tersebut membuat kita sadar akan hal itu.

5
Lars Nordin