Bagaimana cara menghapus kunci RSA yang ketat memeriksa SSH dan apa masalahnya di sini?


42

Saya memiliki server Linux yang setiap kali saya hubungkan menunjukkan kepada saya pesan yang mengubah kunci host SSH:

$ ssh root @ host1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@ @ PERINGATAN: IDENTIFIKASI HOST REMAJA TELAH BERUBAH! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@ ITU MUNGKIN BAHWA SESEORANG YANG MELAKUKAN SESUATU NASTY! Seseorang bisa menguping kamu sekarang (serangan man-in-the-middle)! Mungkin juga kunci host RSA baru saja diubah. Sidik jari untuk kunci RSA yang dikirim oleh host jarak jauh adalah 93: a2: 1b: 1c: 5f: 3e: 68: 47: bf: 79: 56: 52: f0: ec0: ec: 03: 6b. Silakan hubungi administrator sistem Anda. Tambahkan kunci host yang benar di /home/emerson/.ssh/known_hosts untuk menyingkirkan pesan ini. Masukkan kunci di /home/emerson/.ssh/known_hosts:377

Kunci host RSA untuk host1 telah berubah dan Anda telah meminta pemeriksaan ketat. Verifikasi kunci host gagal.

Itu membuat saya selama beberapa detik masuk dan kemudian menutup koneksi.

host1: ~ / .ssh # Baca dari host jarak jauh host1: Koneksi diatur ulang oleh rekan Koneksi ke host1 ditutup.

Adakah yang tahu apa yang terjadi dan apa yang bisa saya lakukan untuk menyelesaikan masalah ini?


1
Ini dupes pertanyaan sebelumnya: serverfault.com/questions/2988/…
Drew Stephens

Jawaban:


68

Tolong jangan hapus seluruh file known_hosts seperti yang direkomendasikan oleh beberapa orang, ini benar-benar mengosongkan titik peringatan. Ini adalah fitur keamanan untuk memperingatkan Anda bahwa seorang pria dalam serangan tengah mungkin telah terjadi.

Saya sarankan Anda mengidentifikasi mengapa ia berpikir sesuatu telah berubah, kemungkinan besar peningkatan SSH mengubah kunci enkripsi karena kemungkinan celah keamanan. Anda kemudian dapat membersihkan baris tertentu dari file known_hosts Anda:

sed -i 377d ~/.ssh/known_hosts

Ini d eletes baris 377 seperti yang ditunjukkan setelah usus besar dalam peringatan:

/home/emerson/.ssh/known_hosts:377

Atau Anda dapat menghapus kunci yang relevan dengan melakukan hal berikut

ssh-keygen -R 127.0.0.1 (obviously replace with the server's IP)

Harap JANGAN bersihkan seluruh file dan pastikan ini adalah mesin yang ingin Anda sambungkan sebelum membersihkan kunci tertentu.


Tidak akan menghapus lebih dari 350 server karena satu ketidakcocokan kunci. Ada yang tahu mengapa itu terus menutup koneksi?
setatakahashi

Apakah itu tidak terpecahkan setelah Anda menghapus catatan known_hosts yang relevan? Jika tidak, bisakah Anda menjalankan ssh client dalam mode verbose dan menempelkannya di suatu tempat.
Adam Gibbins

1
Ini menutup mesin karena kunci host tidak valid, seperti yang dikatakannya. Jika Anda serius tentang keamanan, Anda perlu memeriksa dengan admin server untuk memastikan kunci host diubah untuk alasan yang sah. Jika demikian, Anda dapat menggantinya, seperti yang dijelaskan oleh Adam.
Matthew Flaschen

Saya mengikuti saran Anda tetapi $ sed -i "46 d" ~ / .ssh / known_hosts sed: 1: "/Users/myusr/.ssh ...": karakter tambahan di akhir perintah l jadi saya menghapusnya secara manual dengan vim dan itu berhasil. Terima kasih!
Luis Ramirez-Monterosa

3
Sintaks Adam hampir benar, tetapi Anda membutuhkan ruang antara "377" dan "d". Juga, di OS X, host yang dikenal terletak di ~ / .ssh / known_hosts; perhatikan kekurangan "." dalam nama file.
ktappe

27

Saya pikir meskipun beberapa jawaban di sini membahas tindakan yang direkomendasikan dalam pertanyaan OP, itu tidak sepenuhnya menjawab pertanyaan.

Pertanyaannya menyatakan "Bagaimana cara menghapus kunci RSA yang ketat memeriksa SSH dan apa masalahnya di sini?"

Masalahnya di sini adalah, seperti yang disarankan oleh beberapa orang lain, perubahan pada host mungkin karena menginstal ulang server (skenario paling umum). Dan solusi yang disarankan memang untuk menghapus kunci yang menyinggung dari file .ssh / Authorized_key dengan sed inline.

Namun saya tidak melihat jawaban apa pun menjawab bagian spesifik dari pertanyaan " Bagaimana cara menghapus kunci RSA yang ketat memeriksa SSH ".

Anda dapat menghapus pemeriksaan StrictHostKey di file konfigurasi ssh Anda, biasanya disimpan di ~/.ssh/config.

Contoh Host blok disediakan di bawah ini:

Host 101
  HostName yourip|hostname
  User youruserid
  IdentityFile /path/to/keyfile
  Port 22
  StrictHostKeyChecking no

Baris yang ditambahkan secara khusus adalah baris terakhir StrictHostKeyChecking noyang melakukan apa. Bergantung pada skenario spesifik Anda, ini mungkin berguna bagi Anda, seperti menjalankan beberapa wadah tervirtualisasi pada server khusus, hanya dalam beberapa ips, berhenti dan memulai contoh lain pada ip yang sama.


3
+1 Karena pos ini sebenarnya membahas bagian pemeriksaan ketat dari pesan kesalahan.
Shibumi

1
+1 dari saya juga untuk mengatasi konten pertanyaan. Tergantung pada faktor, mungkin ada lebih banyak yang harus dilakukan. Pendekatan ini menurunkan pemeriksaan host dari "ketat" ke "beberapa" (terminologi saya). Dalam situasi saya yang meninggalkan ssh dengan izin untuk mencegah saya masuk karena cara saya ingin masuk adalah memasukkan kata sandi, dan itu dinonaktifkan oleh pengecekan host "some". Jadi, Anda harus maju dan mengarahkan ssh untuk menggunakan / dev / null sebagai "UserKnownHostsFile". Ini membuat host memeriksa ke "tidak ada" yang berlaku dan PERINGATAN DIRE di atas berlaku, jadi jangan lakukan secara global atau permanen.
cardiff space man

Ini benar-benar solusi yang elegan. Terima kasih telah berbagi!
LeOn - Han Li

10

Cara lain untuk menghapus StrictHostKeyChecking, ketika Anda hanya perlu melakukannya untuk satu server:

ssh <server> -o StrictHostKeyChecking=no

Akan membiarkan Anda masuk tetapi tidak memperbaiki masalah secara permanen.
Andres Canella

Ketika saya melakukannya, itu memberi saya kesempatan untuk menambahkan kunci, yang kemudian memperbaiki masalah secara permanen
Greg Dougherty

Mungkin kita punya masalah berbeda? Saya terhubung ke server yang memiliki IP berbeda sebelumnya.
Andres Canella

Jika Anda memiliki server yang datanya telah berubah, maka Anda harus menghapusnya dari file host yang Anda kenal (setelah terlebih dahulu memastikan bahwa perubahan itu benar), dan menambahkan informasi baru. Jika Anda memiliki server baru, -o akan membiarkan Anda terhubung ke server dan mendapatkan informasinya ditambahkan.
Greg Dougherty

Saya pikir ini sebenarnya praktik yang baik untuk menjaga agar StrictHostKeyChecking disetel ke YA dalam konfigurasi Anda dan hanya menggunakan sakelar ini ketika Anda tahu Anda sedang terhubung ke server baru atau mengubah kunci di server lama.
mohak

5

Pertama-tama, apakah ini mesin Anda? Apakah Anda dengan sadar mengubah kunci host? Jika tidak, saya akan sangat khawatir bahwa ada sesuatu yang mengubah data itu.

Kedua, nyalakan debug ssh,

ssh -vvv user@host

dan lihat apa yang memberitahu Anda, juga coba cari, / var / log / secure dan / var / log / messages di server yang Anda coba sambungkan sebagai petunjuk, sshd memberikan pesan kesalahan yang baik.

Ketiga, apakah mesin ini terhubung ke internet? Haruskah Anda benar-benar mengizinkan login root?


1
+1 untuk komentar login root
Fahad Sadah

Yang diperlukan agar kesalahan ini terjadi adalah mesin target sedang di-reimaged. Jika Anda terhubung ke target yang ada di pihak Anda dari DMZ, serangan MitM sangat tidak mungkin.
ktappe

3

Anda mendapatkan ini karena sesuatu telah berubah (seperti NIC baru, IP baru, perubahan pada perangkat lunak server, dll). Fokus keamanan memiliki artikel yang bagus tentang perlindungan kunci host SSH .

Hapus saja kunci (menggunakan SFTP atau yang serupa) dari server, dengan mengedit $HOME/.ssh/known_hostsfile, dan menerima yang baru pada koneksi berikutnya.

Koneksi Anda mungkin terputus karena pengaturan StrictHostKeyChecking. Lihat utas ini untuk masalah serupa.


2
Tidaaaak, tolong jangan lakukan ini. Ini benar-benar mengosongkan semua keamanan yang disediakan fitur ini. Harap hapus saja kunci spesifik yang telah berubah, tidak semua host_hosting.
Adam Gibbins

5
Saya tidak merekomendasikan untuk menghapus file known_hosts, saya merekomendasikan untuk mengeditnya, dan menghapus kunci dari itu.

Aduh, maaf, salah baca.
Adam Gibbins

2
Pesan ini tentu saja tidak dapat dipicu oleh alamat IP baru, apalagi oleh NIC baru. Lihat jawaban yang benar Adam Gibbins.
bortzmeyer

1
Sebelum Anda memilih (saya menemukan orang-orang sangat senang dengan ini), lakukan riset. Baca artikel Fokus Keamanan ini, securityfocus.com/infocus/1806 . Saya mengutip sedikit dari itu: "Mengapa kunci host dapat berubah? Mesin yang ingin Anda sambungkan telah dipindahkan ke nama DNS atau alamat IP yang berbeda, atau semuanya diganti dengan yang baru sama sekali." Jika jawaban sangat salah, izinkan kesempatan untuk koreksi. Bagaimanapun, ini adalah wiki.

3

Seperti 'host' [yang didefinisikan secara luas, itu bisa berupa segalanya mulai dari instal ulang / multiboot ke komputer yang sama sekali berbeda dengan alamat IP yang telah Anda hubungkan sebelumnya, misalnya] tampaknya ssh client telah berubah, itu memberi Anda kesalahan.

Tidak perlu mematikan pemeriksaan ketat, tidak juga penghapusan grosir kunci yang disimpan masuk akal.

Sangat mungkin untuk memiliki dua kunci berbeda yang terdaftar di known_hosts untuk nama host atau alamat IP tertentu; memberi Anda 2 alternatif sesuai dengan apakah Anda berpikir Anda mungkin memerlukan kunci 'lama' yang saat ini disimpan di hosting yang dikenal

Hapus kunci tertentu yang dirujuk, di l377 dari known_hosts untuk OP, atau simpan keduanya

Cara paling sederhana untuk menjaga keduanya, menghindari penghapusan kunci di known_hosts, adalah

  1. Edit diketahui_hosts untuk menambahkan # pada awal entri 'lama' yang dirujuk di known_hosts [@ l377] untuk sementara
  2. Hubungkan [ssh ke tuan rumah], setujui permintaan untuk menambahkan kunci baru 'secara otomatis'
  3. Kemudian edit kembali host yang dikenal untuk menghapus #

lebih banyak jawaban di "Tambahkan kunci host yang benar di known_hosts" / beberapa kunci host ssh per nama host?


Saya belum tahu tentang trik dua tombol. Ini bukan perilaku yang terdokumentasi, kan?
hackerb9
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.