risiko menggunakan kunci publik ssh

Saya memiliki server A dan server B (cadangan), dan saya bertanya-tanya, jika seseorang membobol server A, dapatkah ini berpotensi berbahaya untuk masuk ke server B jika saya telah mengkonfigurasi login tanpa kata sandi menggunakan kunci publik ssh?

Saya mencoba mengatur rsnapshot.

Terima kasih

Ya, ini adalah salah satu masalah dengan kunci SSH tanpa kata sandi. Jika Anda menyimpan kunci pribadi di server A yang memungkinkan Anda terhubung ke server B, mendapatkan akses ke server A secara efektif mendapatkan akses ke server B. (Bukan sebaliknya tidak benar - mendapatkan akses ke server B tidak akan menghasilkan kompromi langsung dari server A, dengan anggapan Anda tidak memiliki kunci SSH yang diatur untuk mengizinkan login tanpa kata sandi ke arah itu.

Ada beberapa hal yang dapat Anda lakukan untuk mengurangi ini:

• Jika proses tidak perlu sepenuhnya otomatis, tambahkan kata sandi ke kunci SSH Anda. (Ini mungkin tidak akan berhasil untuk Anda, karena Anda perhatikan itu untuk cadangan)
• Untuk login tanpa kata sandi di bawah akun Anda sendiri ke beberapa mesin, saya sarankan membuat kunci kata sandi untuk setiap mesin yang Anda ketik secara fisik, dan menggunakan agen SSH untuk menyimpan kunci dalam memori saat Anda menggunakannya. Penerusan agen harus memungkinkan Anda untuk "melompat" dari host ke host tanpa membuat kunci pada setiap host jarak jauh.
• Untuk kunci SSH otomatis dan tanpa kata sandi, saya sarankan untuk membatasi perintah yang dapat dijalankan oleh kunci tersebut. Di authorized_keysfile Anda , awali setiap kunci Anda dengan:
  command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

8-9 tahun yang lalu saya bekerja di lingkungan pengguna bersama dengan ratusan pengguna lokal, dan login berbasis kunci SSH dinonaktifkan karena tidak ada cara untuk menegakkan kebijakan kata sandi pada kunci. Selama Anda mengendalikan skenario sepenuhnya, saat ini kunci SSH jelas lebih baik daripada hanya menggunakan kata sandi.

Ya, sebagian besar panduan di internet berhenti membuat ssh tanpa kata sandi berfungsi, daripada membuatnya berfungsi dengan aman. Panduan ini melakukan pekerjaan yang baik untuk menunjukkan apa yang dapat dilakukan untuk mengurangi risiko. Pada dasarnya (mengutip artikel):

• buat akun peran tujuan tunggal untuk pekerjaan: yaitu pengguna dnssyncdi setiap mesin
• jika memungkinkan, buat file-file tersebut dapat ditulis oleh pengguna itu, alih-alih mengandalkan sebagai root
• untuk bit yang benar-benar membutuhkan akses istimewa, buat skrip untuk melakukannya, dan gunakan sudo
• gunakan command=dan from=opsi dalam authorized_keysfile untuk membatasi kunci frasa sandi
• untuk melakukan transfer file, tulis skrip untuk melakukannya menggunakan rsync, pada mesin penerima , sehingga akses jarak jauh dapat hanya-baca
• jika ini berarti bahwa akses kembali ke mesin penggerak diperlukan dari mesin jarak jauh, gunakan ssh-agentdaripada membuat kunci frasa-frasa kedua

Ada beberapa masalah dengan kunci ssh:

Tidak ada cara terpusat untuk mencabut kunci.

Tidak ada cara untuk menerapkan kebijakan kata sandi pada kunci (apakah kunci pribadi Anda dienkripsi, dan jika demikian dienkripsi dengan kata sandi yang baik?).

Ini adalah masalah yang diselesaikan kerberos. Ini memperkenalkan yang lain, meskipun, yaitu lebih kompleks untuk diterapkan dan membutuhkan infrastruktur manajemen pengguna nyata untuk digunakan dan dikelola.

Bagaimanapun, meskipun ssh berwenang_kunci memungkinkan untuk serangan tipe morris-worm , itu masih lebih baik daripada .r layanan dan telnet oleh mil (tahun cahaya)

Dalam lingkungan apa pun yang telah saya kendalikan, saya selalu menjadi pengikat nyata untuk hak istimewa minimum yang mungkin untuk akun layanan.

Dalam hal ini, saya sarankan memastikan bahwa akun pengguna pada server jarak jauh hanya diizinkan untuk menjalankan serangkaian kecil executable yang didefinisikan dengan ketat. Anda dapat menggunakan beberapa akun di sisi jarak jauh dan sudo untuk mencapai ini.

Bahkan dalam kasus ini, Anda masih tunduk pada bug eskalasi hak istimewa setempat, jadi berhati-hatilah dan melacak bug keamanan dengan ketat.