Haruskah saya membuat kunci ssh pribadi baru di setiap sistem?


10

Saya perlu terhubung ke beberapa server dari beberapa perangkat melalui SSH. Saya bertanya-tanya apakah saya harus membuat file id_dsa baru di setiap perangkat yang saya hubungkan, atau jika tidak ada masalah menyalin file id_dsa yang sama ke setiap perangkat.

Sebagai contoh, saya memiliki sistem desktop berbasis Ubuntu utama saya dan MacBook Pro dengan ssh. Dan saya memiliki Netbook berbasis Windows dengan Putty diinstal. Dan saya punya ponsel Android dengan ConnectBot. Dari salah satu perangkat ini, saya mungkin perlu SSH ke puluhan server fisik dan virtual yang berbeda.

Setiap server perlu kunci publik saya diinstal. Selain itu, akun GitHub dan Codaset saya memerlukan kunci publik saya.

Untuk menyederhanakan manajemen kunci, saya berpikir untuk menggunakan kunci privat yang sama pada semua sistem ini. Apakah ini praktik umum, atau lebih baik memiliki kunci pribadi pada setiap sistem?

Jawaban:


3

Jika Anda menggunakan kunci publik yang sama pada setiap sistem dan kunci privat dikompromikan, maka setiap sistem yang menggunakan kunci itu, kecuali pembatasan lainnya, akan dapat diakses.

Saya percaya Anda menggunakan kunci pribadi yang dilindungi kata sandi?

Dalam praktik manajemen kami, kami memiliki "peran" keamanan yang rendah, sedang dan tinggi. Setiap peran menggunakan kunci yang berbeda. Kunci privat dengan keamanan tinggi tidak boleh ditransmisikan ke aset eksternal, digunakan pada laptop yang bisa hilang / dicuri, dll. Kunci keamanan menengah dan rendah dapat digunakan dalam skenario yang lebih luas.

Saya sarankan untuk memeriksa pola penggunaan Anda dan lihat apa yang membuatnya karena dalam hal peran keamanan. Apa kerusakan yang dilakukan dengan mendapatkan kunci pribadi Anda?

Sudahkah Anda mempertimbangkan untuk meletakkan kunci pribadi SSH ke perangkat perangkat yang tidak dapat dicuri, menghilangkan kemungkinan kompromi kunci tersebut menjadi masalah?

Baik modul keamanan perangkat keras dan kartu pintar dapat digunakan untuk menyimpan kunci pribadi SSH dengan cara yang aman, memungkinkan semua operasi kriptografis dilakukan pada perangkat, bukan pada sistem operasi Anda. Namun, mereka bukan obat mujarab, karena ini memerlukan perangkat keras cadangan juga, jika terjadi kegagalan perangkat keras.


Ya, kunci saya dilindungi kata sandi. Terima kasih atas jawaban anda. Anda telah membantu mengonfirmasi kekhawatiran saya bahwa jika saya menggunakan kunci yang sama pada semua perangkat saya, itu dapat mengakibatkan masalah yang lebih besar di jalan.
Tauren

2

Tentu kamu harus. Anda selalu dapat menambahkan semua kunci ke file otor_keys2 Anda. Saya suka saran jeffatrackaid. Namun, saya akan menggunakan kunci pribadi yang berbeda untuk setiap perangkat - mengapa tidak. Kalah Android Anda. Sederhana, hapus kunci dari daftar kunci yang diotorisasi. Jika tidak, Anda harus membuat ulang level kunci itu lagi.

Yang mengatakan, itu tergantung pada bagaimana Anda memandang risiko dari aset-aset ini. Jelas Anda tidak ingin kehilangan kunci tetapi beberapa Anda dapat mengekspos risiko yang lebih besar, misalnya github vs root ke vps Anda, misalnya.


FYI, authorized_keys2sudah usang sejak 2001 - OpenSSH sekarang menggunakan authorized_keys(meskipun masih membaca kedua file untuk kompatibilitas)
user1686

Ah oke terima kasih. Saya selalu membuat titik untuk menonaktifkan SSHv1 dan cipher berkekuatan rendah, dll.

2

Apakah Anda ingat ketika Debian memiliki sedikit masalah entropi saat membuat kunci SSH? Saat itulah saya belajar pelajaran saya dengan baik.

Saya memiliki kunci pribadi saya sendiri untuk barang-barang saya sendiri, seperti masuk ke server pribadi saya. Saya memiliki kunci "Semua Tujuan" yang membawa saya ke sebagian besar kotak pengembangan saya, lalu memotong kunci per klien yang saya layani.

Saya juga menyimpan daftar kunci apa saja yang ada pada mesin apa, hanya untuk berjaga-jaga jika saya harus mengganti atau melepasnya dengan tergesa-gesa.

Untuk semua hal lain yang serius, saya hanya menggunakan LDAP / PAM, kalau-kalau saya harus menghapus orang lain dengan tergesa-gesa.

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.