Mengapa saya harus menggunakan Otentikasi Kunci Publik untuk SSH?

Saya menjalankan server SSH dan saya masih menggunakan otentikasi kata sandi sederhana. Di mana-mana saya membaca tentang keamanan saya disarankan untuk menggunakan Otentikasi Publik-Kunci. Tapi saya tidak mendapatkan keuntungannya. Menggunakannya, menurut saya, tidak aman atau banyak pekerjaan praktis.

Tentu saja, jika seseorang mencoba memaksa masuk ke server SSH Public-Key saya jauh lebih kuat daripada kata sandi apa pun. Tapi selain itu, itu sama sekali tidak aman.

Sebagian besar penasihat berpendapat bahwa Anda tidak perlu mengingat kata sandi. Bagaimana tidak amannya itu? Jadi jika seseorang meretas komputer saya, ia tidak hanya mendapatkan komputer saya, tetapi server saya juga? Jika saya menggunakan SSH dari berbagai klien yang berbeda, saya harus menyimpan kunci publik masing-masing, yang mengalikan kemungkinan bahwa mereka jatuh ke tangan yang salah. Saya bisa menyimpannya di usb-stick yang saya bawa, tetapi bisa hilang dan finder memiliki akses ke server saya.

Mungkin saya lebih baik dilayani dengan Otentikasi Dua Faktor.

Apakah ada argumen yang saya lewatkan? Apa cara terbaik untuk saya?

jika seseorang meretas komputer saya, ia tidak hanya mendapatkan komputer saya, tetapi server saya juga?

Lagipula ini berpotensi benar dengan keyloggers: segera setelah Anda masuk ke server Anda dari komputer yang dikompromikan, mereka mendapatkan kata sandi.

Tetapi ada 3 keuntungan untuk kunci:

1) Otentikasi dapat di-cache. Masukkan frasa sandi Anda sekali, lakukan beberapa perintah ssh. Ini sangat berguna jika Anda menggunakan sesuatu yang menggunakan ssh sebagai transportasi, seperti scp, rsync atau git.

2) Otentikasi yang Dapat Diperbesar. Masukkan frasa sandi Anda sekali, masuk ke beberapa mesin . Semakin banyak mesin yang Anda miliki, semakin berguna ini. Jika Anda memiliki 100 mesin, apa yang Anda lakukan? Anda tidak dapat menggunakan kata sandi yang sama (kecuali itu adalah kloning pertanian), dan Anda tidak dapat mengingat sebanyak itu. Jadi Anda harus menggunakan pengelola kata sandi, dan Anda kembali ke satu titik kompromi. Secara efektif frasa sandi utama adalah pengelola kata sandi Anda.

2b) Ini berskala dengan cara lain jika Anda memiliki beberapa admin menggunakan sistem yang sama, karena Anda dapat mencabut kunci dari pengguna A tanpa harus memberi tahu B, C, D, E, F ... bahwa kata sandi telah berubah.

(Ini juga dapat dilakukan dengan masing-masing akun dan sudo, tetapi kemudian Anda harus menyediakan akun tersebut entah bagaimana)

3) Otomatisasi dan delegasi parsial. Anda dapat mengatur SSH untuk menjalankan perintah tertentu ketika kunci terhubung . Ini memungkinkan proses otomatis pada sistem A untuk melakukan sesuatu pada sistem B tanpa memiliki kepercayaan penuh tanpa kata sandi di antara keduanya.

(Ini pengganti rlogin / rsh, yang sangat tidak aman)

Sunting: keuntungan lain untuk kunci publik daripada kata sandi adalah skenario umum di mana server dikompromikan melalui kerentanan. Dalam hal ini, masuk dengan kata sandi akan segera mengganggu kata sandi. Masuk dengan kunci tidak! Saya akan mengatakan ini lebih umum daripada desktop yang berasal admin dikompromikan.

Jika Anda menggunakan kata sandi yang baik, ini bisa cukup aman. Saya biasanya membatasi jumlah server yang dapat diakses publik hingga minimum dan memungkinkan SSH dari IP tertentu bila memungkinkan.

Anda juga dapat melindungi kunci Anda dengan frasa sandi (kata sandi). Jadi, frasa sandi ini harus dimasukkan kapan pun Anda harus masuk ke server Anda. Tidak ada yang dapat menggunakan kunci Anda kecuali frasa sandi yang tepat diberikan.

Ada posting serupa:

1. Posting dari kesalahan server .
2. Posting dari pertukaran stackex keamanan .
3. Poskan dari superuser .

Salah satu cara di mana otorisasi kunci publik lebih aman adalah ketika penyerang berhasil menjadi man-in-the-middle (MitM) antara komputer klien Anda dan server, dan Anda tidak melihat perubahan kunci host (mungkin karena Anda tidak dapat memiliki kunci lama, mis. karena ini adalah pertama kalinya menggunakan komputer klien khusus ini).

(Hal yang sama berlaku ketika penyerang berhasil mengambil kendali server, dan ada server lain di mana kredensial yang sama bekerja.)

Dengan otentikasi berbasis kata sandi standar, Anda mengirimkan kata sandi Anda (di dalam koneksi terenkripsi) dalam teks biasa, server asli biasanya akan meng-hash-nya dan membandingkan hasilnya dengan hash yang disimpan dalam basis data kata sandi. Seorang penyerang MitM malah bisa mengambil kata sandi ini, membuka koneksi ke server nyata, dan login di sana ... dan meneruskan konten kepada Anda (sehingga Anda tidak melihat apa-apa), atau hanya melakukan hal-hal jahat sendiri di server Anda .

Dengan otentikasi kunci publik, klien pada dasarnya menandatangani beberapa data yang diketahui oleh server dan klien untuk membuktikan bahwa ia memiliki kunci pribadi, dan mengirimkan tanda tangan ke server. Data yang ditandatangani ini mencakup pengidentifikasi sesi, yang tergantung pada angka acak yang dipilih oleh klien dan server, dan karenanya berbeda untuk setiap sesi. Jika MitM membuka koneksi SSH-nya sendiri ke server sebenarnya, yang satu itu akan memiliki ID sesi yang berbeda, dan dengan demikian tanda tangan yang disediakan oleh klien tidak akan berfungsi di sana.

Tentu saja, seperti yang sudah dijawab oleh jawaban lain, Anda perlu menjaga keamanan kunci pribadi Anda, misalnya dienkripsi dengan frasa sandi, atau mungkin pada perangkat terpisah yang hanya membuat tanda tangan setelah memasukkan PIN.

OpenSSH dapat menyimpan CA-nya sendiri untuk mengelola host SSH dan kunci klien dan dapat menggunakan daftar pencabutan pada mereka. Ini dapat menambah keamanan yang disediakan oleh otentikasi berbasis kunci.

Anda benar tentang klaim "Anda tidak perlu kata sandi". Itu benar-benar tidak aman di sisi klien.

Apa yang membuat hanya mengizinkan kunci publik untuk masuk jauh lebih aman adalah kenyataan bahwa tidak ada cara untuk memaksa akses ke server Anda. Semua yang bisa dicapai oleh penyerang adalah menaruh beban pada server Anda - Anda dapat menggunakan fail2ban untuk memastikannya.

Untuk keamanan di sisi klien Anda harus melindungi kunci pribadi dengan frase lulus yang baik. Tentu saja sekarang terhubung ke server lebih rumit daripada dengan kata sandi. Untuk mengatasinya, Anda dapat menggunakan ssh agent untuk menyimpan kunci pribadi dalam memori jika Anda bermaksud untuk terhubung ke server beberapa kali berturut-turut. Ini adalah praktik yang baik untuk membatasi waktu berapa lama kunci harus disimpan dalam memori.

Mungkin saya lebih baik dilayani dengan Otentikasi Dua Faktor.

Satu kemungkinan untuk 2FA untuk SSH (dan yang membutuhkan pengaturan / kompleksitas yang relatif sedikit) sebenarnya menggunakan kunci publik dan kata sandi.

Saya percaya sesuatu di sepanjang baris AuthenticationMethods publickey,keyboard-interactivedapat ditambahkan /etc/ssh/sshd_configuntuk membuat itu berhasil.

Secara umum, masalahnya lebih pada kata sandi (sendiri) bukan metode yang bagus untuk otentikasi karena sering kali kualitasnya meragukan. 'Argumen' yang sangat sederhana untuk kunci vs kata sandi adalah bahwa suatu kunci umumnya akan setidaknya 2048 bit, dan seringkali lebih (untuk kunci EC, ini akan menjadi kekuatan yang efektif, bukan ukuran sebenarnya). Bit-bit itu juga dihasilkan oleh mekanisme yang aman secara kriptologis (atau sesuai).

Kata sandi seringkali kurang dari 2048 bit, dan seringkali tidak berasal dari sumber yang aman secara kriptografis.

Anda juga dapat mengamankan kunci Anda dengan kata sandi, untuk mencegah masalah terkait kehilangannya (meskipun seseorang dapat mencoba dan memaksa paksa kata sandi itu).

Jadi pada dasarnya, perbedaan dapat dibuat cukup transparan antara kunci dan kata sandi, dan menggunakan kunci memberi Anda kata sandi yang lebih baik daripada yang bisa dihadapi manusia. Ini bukan untuk mengatakan bahwa mereka adalah obat mujarab, tetapi rata-rata, mereka memberikan keamanan lebih dari kata sandi.