known_hosts file memungkinkan klien mengotentikasi server, untuk memeriksa apakah itu tidak terhubung ke peniru. authorized_keys file memungkinkan server mengautentikasi pengguna.
Autentikasi server
Salah satu hal pertama yang terjadi ketika koneksi SSH dibuat adalah bahwa server mengirimkan kunci publiknya ke klien, dan membuktikan (berkat kriptografi kunci publik) kepada klien bahwa ia mengetahui kunci privat terkait. Ini mengautentikasi server:jika bagian protokol ini berhasil, klien tahu bahwa server adalah yang diklaimnya.
Klien dapat memeriksa apakah server tersebut adalah server yang dikenal, dan bukan server nakal yang mencoba berpura-pura sebagai server yang benar. SSH hanya menyediakan mekanisme sederhana untuk memverifikasi keabsahan server:SSH mengingat server yang telah Anda sambungkan, di ~/.ssh/known_hosts file di mesin klien (ada juga file seluruh sistem /etc/ssh/known_hosts ). Pertama kali Anda terhubung ke server, Anda perlu memeriksa dengan cara lain bahwa kunci publik yang disajikan oleh server benar-benar merupakan kunci publik dari server yang ingin Anda sambungkan. Jika Anda memiliki kunci publik dari server yang akan Anda sambungkan, Anda dapat menambahkannya ke ~/.ssh/known_hosts pada klien secara manual.
Ngomong-ngomong, known_hosts dapat berisi semua jenis kunci publik yang didukung oleh penerapan SSH, bukan hanya DSA (juga RSA dan ECDSA).
Otentikasi server harus dilakukan sebelum Anda mengirim data rahasia apa pun ke sana. Secara khusus, jika autentikasi pengguna melibatkan kata sandi, kata sandi tidak boleh dikirim ke server yang tidak diautentikasi.
Autentikasi pengguna
Server hanya mengizinkan pengguna jarak jauh untuk masuk jika pengguna tersebut dapat membuktikan bahwa mereka memiliki hak untuk mengakses akun tersebut. Bergantung pada konfigurasi server dan pilihan pengguna, pengguna dapat menunjukkan salah satu dari beberapa bentuk kredensial (daftar di bawah tidak lengkap).
- Pengguna dapat memberikan kata sandi untuk akun yang dia coba masuki; server kemudian memverifikasi bahwa kata sandi sudah benar.
- Pengguna dapat memberikan kunci publik dan membuktikan bahwa dia memiliki kunci privat yang terkait dengan kunci publik tersebut. Ini adalah metode yang persis sama yang digunakan untuk mengautentikasi server, tetapi sekarang pengguna mencoba membuktikan identitasnya dan server sedang memverifikasinya. Upaya login diterima jika pengguna membuktikan bahwa dia mengetahui kunci privat dan kunci publik ada dalam daftar otorisasi akun (
~/.ssh/authorized_keysdi server). - Jenis metode lain melibatkan pendelegasian sebagian pekerjaan mengautentikasi pengguna ke mesin klien. Ini terjadi di lingkungan yang terkendali seperti perusahaan, ketika banyak mesin berbagi akun yang sama. Server mengautentikasi mesin klien dengan mekanisme yang sama yang digunakan sebaliknya, lalu bergantung pada klien untuk mengautentikasi pengguna.
Kedua file tersebut sama-sama digunakan oleh SSH tetapi untuk tujuan yang sama sekali berbeda, yang dapat dengan mudah menjelaskan kebingungan Anda.
Kunci Resmi
Secara default SSH menggunakan akun pengguna dan kata sandi yang dikelola oleh OS host. (Yah, sebenarnya dikelola oleh PAM tetapi perbedaan itu mungkin tidak terlalu berguna di sini.) Artinya adalah ketika Anda mencoba terhubung ke SSH dengan nama pengguna 'bob' dan beberapa kata sandi, program server SSH akan menanyakan OS "I mendapatkan orang ini bernama 'bob' yang memberi tahu saya kata sandinya adalah 'wonka'. Bisakah saya membiarkan dia masuk?" Jika jawabannya adalah ya, maka SSH memungkinkan Anda untuk mengautentikasi dan melanjutkan perjalanan Anda.
Selain kata sandi, SSH juga memungkinkan Anda menggunakan apa yang disebut kriptografi kunci publik untuk mengidentifikasi Anda. Algoritme enkripsi spesifik dapat bervariasi, tetapi biasanya RSA atau DSA, atau yang lebih baru ECDSA. Bagaimanapun saat Anda menyiapkan kunci, gunakan ssh-keygen program, Anda membuat dua file. Satu itu adalah kunci pribadi Anda dan satu lagi adalah kunci publik Anda. Nama-nama itu cukup jelas. Secara desain, kunci publik dapat berserakan seperti biji dandelion yang tertiup angin tanpa membahayakan Anda. Kunci pribadi harus selalu dijaga kerahasiaannya.
Jadi yang Anda lakukan adalah menempatkan kunci publik Anda di authorized_keys mengajukan. Kemudian ketika Anda mencoba untuk terhubung ke SSH dengan nama pengguna 'bob' dan kunci pribadi Anda, OS akan menanyakan "Saya mendapat nama orang ini 'bob', bisakah ada di sini?" Jika jawabannya ya maka SSH akan memeriksa kunci pribadi Anda dan memverifikasi apakah kunci publik ada di authorized_keys file adalah pasangannya. Jika kedua jawaban adalah ya, maka Anda diperbolehkan masuk.
Host yang Dikenal
Sama seperti bagaimana authorized_keys file digunakan untuk mengotentikasi pengguna known_hosts file digunakan untuk mengotentikasi server. Setiap kali SSH dikonfigurasi di server baru, SSH selalu menghasilkan kunci publik dan pribadi untuk server, seperti yang Anda lakukan untuk pengguna Anda. Setiap kali Anda terhubung ke server SSH, itu menunjukkan kepada Anda kunci publiknya, bersama dengan bukti bahwa ia memiliki kunci pribadi yang sesuai. Jika Anda tidak memiliki kunci publiknya, maka komputer Anda akan memintanya dan menambahkannya ke dalam known_hosts mengajukan. Jika Anda memiliki kuncinya, dan itu cocok, maka Anda langsung terhubung. Jika kunci tidak cocok, maka Anda mendapat peringatan buruk yang besar. Di sinilah segalanya menjadi menarik. 3 situasi di mana ketidakcocokan kunci biasanya terjadi adalah:
- Kunci diubah di server. Ini bisa dari menginstal ulang OS atau pada beberapa OS kunci dibuat ulang saat mengupdate SSH.
- Nama host atau alamat IP yang Anda sambungkan dulu milik server yang berbeda. Ini bisa berupa penetapan ulang alamat, DHCP, atau yang serupa.
- Serangan man-in-the-middle berbahaya sedang terjadi. Ini adalah hal terbesar yang mencoba melindungi Anda dari pemeriksaan kunci.
Dalam kedua kasus, known_hosts dan authorized_keys , program SSH menggunakan kriptografi kunci publik untuk mengidentifikasi klien atau server.
Tentang File Aman yang Mengandung Kunci Publik
Untuk membantu Anda memahami bagaimana "known_hosts" dan "authorized_keys" berbeda, berikut adalah beberapa konteks yang menjelaskan bagaimana file tersebut masuk ke dalam "ssh". Ini adalah penyederhanaan yang berlebihan; ada lebih banyak kemampuan dan komplikasi untuk "ssh" daripada yang disebutkan di sini.
Asosiasi ada di Sumber Tepercaya
Meskipun telah dikatakan bahwa nilai kunci publik "dapat dengan aman berserakan seperti benih yang tertiup angin", perlu diingat bahwa tukang kebunlah, bukan polong biji, yang memutuskan benih mana yang ditanam di kebun. Meskipun kunci publik bukanlah rahasia, perlindungan ketat diperlukan untuk mempertahankan asosiasi kunci yang tepercaya dengan hal yang diautentikasi oleh kunci tersebut. Tempat yang dipercayakan untuk membuat pengaitan ini mencakup daftar "known_hosts", "authorized_keys", dan "Certificate Authority".
Sumber Tepercaya yang Digunakan oleh "ssh"
Agar kunci publik relevan dengan "ssh", kunci harus didaftarkan sebelumnya, dan disimpan dalam file aman yang sesuai. (Kebenaran umum ini memiliki satu pengecualian penting, yang akan dibahas nanti.) Server dan klien masing-masing memiliki daftar kunci publik yang disimpan dengan aman; login akan berhasil hanya jika masing-masing pihak terdaftar dengan yang lain.
- "known_hosts" berada di klien
- "authorized_keys" berada di server
File aman klien disebut "known_hosts", dan file aman server disebut "authorized_keys". File-file ini serupa karena masing-masing memiliki teks dengan satu kunci publik per baris, tetapi memiliki perbedaan kecil dalam format dan penggunaan.
Pasangan kunci Digunakan untuk Otentikasi
Pasangan kunci publik-swasta digunakan untuk melakukan "kriptografi asimetris". Program "ssh" dapat menggunakan kriptografi asimetris untuk autentikasi, di mana entitas harus menjawab tantangan untuk membuktikan identitasnya. Tantangan dibuat dengan menyandikan dengan satu kunci, dan menjawab dengan mendekodekan dengan kunci lainnya. (Perhatikan bahwa kriptografi asimetris hanya digunakan selama fase login; lalu "ssh" (TSL/SSL) beralih ke bentuk enkripsi lain untuk menangani aliran data.)
Satu Pasangan Kunci untuk Server, Satu lagi untuk Klien
Di "ssh", kedua belah pihak (klien dan server) saling curiga; ini merupakan peningkatan dari pendahulu "ssh", yang merupakan "telnet". Dengan "telnet", klien diharuskan memberikan kata sandi, tetapi server tidak diperiksa. Kurangnya pemeriksaan memungkinkan terjadinya serangan "man-in-the-middle", dengan konsekuensi bencana terhadap keamanan. Sebaliknya, dalam proses "ssh", klien tidak memberikan informasi apa pun sampai server menjawab tantangan terlebih dahulu.
Langkah-langkah dalam Autentikasi "ssh"
Sebelum membagikan informasi login apa pun, klien "ssh" terlebih dahulu menghilangkan peluang serangan man-in-the-middle dengan menantang server untuk membuktikan "Apakah Anda benar-benar seperti yang saya pikirkan?" Untuk membuat tantangan ini, klien perlu mengetahui kunci publik yang terkait dengan server target. Klien harus menemukan nama server di file "known_hosts"; kunci publik terkait berada di baris yang sama, setelah nama server. Hubungan antara nama-server dan kunci-publik harus tetap terjaga; oleh karena itu izin pada file "known_hosts" harus 600 -- tidak ada orang lain yang dapat menulis (atau membaca).
Setelah server diautentikasi, ia mendapat kesempatan untuk menantang klien. Otentikasi akan melibatkan salah satu kunci publik yang ditemukan di "authorized_keys". (Bila tidak ada kunci yang berfungsi, proses "sshd" kembali ke autentikasi gaya kata sandi.)
Format File
Jadi untuk "ssh", seperti proses login lainnya, ada daftar "teman", dan hanya mereka yang ada di daftar yang diizinkan untuk mencoba melewati tantangan. Untuk klien, file "known_hosts" adalah daftar teman yang dapat bertindak sebagai server (host); ini terdaftar dengan nama. Untuk server, daftar teman yang setara adalah file "authorized_keys"; tetapi tidak ada nama dalam file itu, karena kunci publik itu sendiri bertindak seperti pengidentifikasi. (Server tidak peduli dari mana login berasal, tetapi hanya ke mana tujuannya. Klien mencoba mengakses akun tertentu, nama akun ditentukan sebagai parameter ketika "ssh" dipanggil. Ingat bahwa "authorized_keys " file khusus untuk akun tersebut, karena file tersebut berada di direktori home akun tersebut.)
Meskipun ada banyak kemampuan yang dapat diekspresikan dalam entri konfigurasi, penggunaan dasar yang paling umum memiliki parameter berikut. Perhatikan bahwa parameter dipisahkan oleh karakter spasi.
Untuk "known_hosts":
{server-id} ssh-rsa {public-key-string} {comment}
Untuk "authorized_keys":
ssh-rsa {public-key-string} {comment}
Perhatikan bahwa token ssh-rsa menunjukkan bahwa algoritma yang digunakan untuk pengkodean adalah "rsa". Algoritme valid lainnya termasuk "dsa" dan "ecdsa". Oleh karena itu, token lain mungkin menggantikan ssh-rsa ditampilkan di sini.
Biarkan "ssh" Mengonfigurasi Otomatis Entri "known_hosts"
Dalam kedua kasus tersebut, jika kunci publik tidak ditemukan di dalam file yang aman, enkripsi asimetris tidak akan terjadi. Seperti disebutkan sebelumnya, ada satu pengecualian untuk aturan ini. Seorang pengguna diizinkan untuk secara sadar memilih untuk mengambil risiko kemungkinan serangan man-in-the-middle dengan masuk ke server yang tidak tercantum dalam file "known_hosts" pengguna. Program "ssh" memperingatkan pengguna, tetapi jika pengguna memilih untuk maju, klien "ssh" mengizinkannya "sekali ini saja". Untuk memastikan hal itu terjadi sekali saja, proses "ssh" secara otomatis mengonfigurasi file "known_hosts" dengan informasi yang diperlukan dengan meminta server untuk kunci publik, dan kemudian menuliskannya ke dalam file "known_hosts". Pengecualian ini benar-benar merongrong keamanan dengan membiarkan musuh memberikan asosiasi nama server dengan kunci publik. Risiko keamanan ini diperbolehkan karena membuat banyak hal menjadi lebih mudah bagi banyak orang. Tentu saja, metode yang benar dan aman adalah bagi pengguna untuk secara manual memasukkan baris dengan nama server dan kunci publik ke dalam file "known_hosts" sebelum mencoba masuk ke server. (Tetapi untuk situasi berisiko rendah, kerja ekstra mungkin tidak ada gunanya.)
Hubungan Satu ke Banyak
Entri dalam file "known_hosts" klien memiliki nama server dan kunci publik yang berlaku untuk mesin server. Server memiliki satu kunci privat yang digunakan untuk menjawab semua tantangan, dan entri "known_hosts" klien harus memiliki kunci publik yang cocok. Oleh karena itu, semua klien yang pernah mengakses server tertentu akan memiliki entri kunci publik yang identik dalam file "known_hosts" mereka. Relasi 1:N adalah kunci publik server dapat muncul di banyak file "known_hosts" klien.
Entri dalam file "authorized_keys" mengidentifikasi bahwa klien yang ramah diizinkan untuk mengakses akun. Teman tersebut mungkin menggunakan pasangan kunci publik-pribadi yang sama untuk mengakses beberapa server yang berbeda. Ini memungkinkan pasangan kunci tunggal untuk mengautentikasi ke semua server yang pernah dihubungi. Setiap akun server yang ditargetkan akan memiliki entri kunci publik yang identik dalam file "authorized_keys" mereka. Relasi 1:N adalah kunci publik satu klien dapat muncul di file "authorized_keys" untuk beberapa akun di beberapa server.
Terkadang, pengguna yang bekerja dari beberapa mesin klien akan mereplikasi pasangan kunci yang sama; biasanya ini dilakukan saat pengguna bekerja di desktop dan laptop. Karena mesin klien mengautentikasi dengan kunci yang identik, mereka akan cocok dengan entri yang sama di "kunci_otorisasi" server.
Lokasi Kunci Pribadi
Untuk sisi server, proses sistem, atau daemon, menangani semua permintaan login "ssh" yang masuk. Daemon tersebut bernama "sshd". Lokasi kunci pribadi bergantung pada pemasangan SSL, misalnya Apple meletakkannya di /System/Library/OpenSSL , tetapi setelah menginstal OpenSSL versi Anda sendiri, lokasinya adalah /opt/local/etc/openssl .
Untuk sisi klien, Anda memanggil "ssh" (atau "scp") saat Anda membutuhkannya. Baris perintah Anda akan menyertakan berbagai parameter, salah satunya secara opsional dapat menentukan kunci pribadi mana yang akan digunakan. Secara default, pasangan kunci sisi klien sering disebut $HOME/.ssh/id_rsa dan $HOME/.ssh/id_rsa.pub .
Ringkasan
Intinya adalah "known_hosts" dan "authorized_keys" berisi kunci publik, tetapi ...
- known_hosts -- klien memeriksa apakah host asli
- authorized_keys -- host memeriksa apakah login klien diizinkan