Masalah verifikasi kunci Host SSH menggunakan VIP

Kami memiliki 2 server produksi pada VIP, hanya satu yang digunakan pada satu waktu, misalnya:

myservice.mycompany.uk biasanya menunjuk ke server1, jika server1 gagal itu berubah menjadi titik di server2.

Ada beberapa server lain yang perlu mengirim file ke myservice.mycompany.uk melalui SFTP dan itu harus benar-benar transparan kepada mereka jika kita gagal ke server2.

Masalahnya adalah bahwa ketika kunci diinstal pada kedua server1 dan server2, server lain akan memiliki masalah verifikasi kunci host, karena kunci host server2 berbeda dengan kunci host server1. Ini menyebabkan kesalahan keamanan (karena pemeriksaan ketat diaktifkan), dan sebuah baris harus dihapus dari known_hosts untuk membuatnya berfungsi.

Orang IT kami telah menyarankan agar kami dapat membuat 2 entri di known_hosts, satu dengan kunci untuk server1 dan satu dengan server2, keduanya dengan host myservice.mycompany.uk.

Apakah itu mungkin berhasil? Bagaimana ini bisa dilakukan dengan dempul / psftp di windows? Karena kunci host disimpan dalam registri dan nama duplikat tidak diperbolehkan. Adakah cara yang lebih baik, bisakah kita, misalnya, memaksa server untuk memiliki kunci host yang sama?

ssh cluster sftp

— Paul Creasey
sumber

Jawaban:

Untuk memudahkan klien, saya hanya akan menggunakan kunci host yang sama di kedua mesin. Cukup salin salah satu kunci (salah satu server yang sedang digunakan) ke mesin kedua. Mereka kunci /etc/ssh/ssh_host_*.

Pilihan lain adalah untuk menonaktifkan pemeriksaan kunci host pada klien. Ini dapat dilakukan dengan menyetel mereka ssh_configuntuk menggunakan:

Host myservice.mycompany.uk
    StrictHostKeyChecking

— ℝaphink
sumber

Mematikan memeriksa kunci host agak merusak titik menggunakan SSH untuk mentransfer file-file ini, menduplikasi kunci host mungkin adalah solusi terbaik.

— James Yale

Menonaktifkan pemeriksaan kunci host tidak berarti komunikasi tidak dienkripsi dengan benar, yang merupakan poin utama SSH. Yang mengatakan, seperti yang saya katakan, saya lebih menyukai solusi pertama.

— ℝaphink

Dalam versi klien (dengan kunci server berbeda) dari solusi Anda juga perlu menambahkan UserKnownHostsFile=/dev/nulllagi kunci pertama akan masuk ke host-dikenal dan yang kedua akan mengarah ke peringatan "man in the middle".

— Nils

@Nils ini tidak perlu; pengaturan StrictHostKeyChecking yesakan membuat file UserKnownHosts diabaikan demi file host sistem yang dikenal. Jadi segala sesuatu yang memodifikasi UserKnownHosts agak tidak ada gunanya.

— Michael Lowman

Oke - Saya harus mengklarifikasi ini lebih lanjut: Saya berbicara tentang kasus di mana Anda memiliki dua kunci server yang berbeda. Di sana Anda harus menentukan StrictHostKeyChecking nodan mengatur tambahan UserKnownHostsFileke / dev / null. Dalam hal ini, semua kunci host akan diterima (membuat level keamanan ini tidak berguna, tentu saja).

— Nils

Saya mengarsipkan ini dengan cara ini, root pengguna menjalankan satu skrip pada pukul 23:00 PM yang terhubung ke alamat ip logis dari cluster Linux, jadi dalam kasus failover dari alamat ip perubahan ssh sidik jari saya

echo "StrictHostKeyChecking no" >> /root/.ssh/config 
echo "UserKnownHostsFile /dev/null" >> /root/.ssh/config

Dengan cara ini, pengaturan hanya untuk root

— c4f4t0r
sumber