Otentikasi berbasis kunci SSH: known_hosts vs otor_keys

Saya membaca tentang pengaturan kunci ssh di Linux dan ada beberapa pertanyaan. Koreksi saya jika saya salah ...

Katakanlah host tr-lgto ingin terhubung ke host tr-mdm menggunakan ssh. Jika kami ingin memastikan bahwa itu adalah tr-mdm asli, kami membuat sepasang kunci pada tr-mdm dan kami menambahkan kunci publik ke known_hostspada tr-lgto. Jika tr-mdm ingin memeriksa apakah itu tr-lgto yang asli, maka tr-lgto harus membuat keypair dan menambahkan kunci publik authorized_keysdi tr-mdm.

Pertanyaan 1 : Tidak ada bidang pengguna dalam file known_hosts, hanya alamat IP dan nama host. tr-mdm mungkin memiliki banyak pengguna, masing-masing dengan .sshfoldernya sendiri . Haruskah kita menambahkan kunci publik ke masing-masing known_hostsfile?

Pertanyaan 2 : Saya menemukan bahwa ssh-keyscan -t rsa tr-mdmakan mengembalikan kunci publik dari tr-mdm. Bagaimana saya tahu pengguna milik siapa kunci ini? Selain itu, kunci publik /root/.ssh/berbeda dari apa yang dikembalikan oleh perintah itu. Bagaimana ini bisa terjadi?

Anda sedang mencampur otentikasi mesin server ke mesin klien, dan otentikasi pengguna ke mesin server.

Otentikasi server

Salah satu hal pertama yang terjadi ketika koneksi SSH sedang dibuat adalah bahwa server mengirimkan kunci publiknya ke klien, dan membuktikan (berkat kriptografi kunci publik ) kepada klien bahwa ia mengetahui kunci privat terkait. Ini mengotentikasi server: jika bagian protokol ini berhasil, klien tahu bahwa server adalah siapa yang berpura-pura.

Klien dapat memeriksa apakah server tersebut adalah server yang dikenal, dan bukan server jahat yang mencoba mengirimkannya sebagai server yang benar. SSH hanya menyediakan mekanisme sederhana untuk memverifikasi keabsahan server: ia mengingat server yang sudah Anda sambungkan, dalam ~/.ssh/known_hostsfile di mesin klien (ada juga file sistem-lebar /etc/ssh/known_hosts). Pertama kali Anda terhubung ke server, Anda perlu memeriksa dengan beberapa cara lain bahwa kunci publik yang disajikan oleh server benar-benar kunci publik dari server yang ingin Anda sambungkan. Jika Anda memiliki kunci publik dari server yang akan Anda sambungkan, Anda dapat menambahkannya ~/.ssh/known_hostsdi klien secara manual.

Otentikasi server harus dilakukan sebelum Anda mengirim data rahasia apa pun ke dalamnya. Khususnya, jika otentikasi pengguna melibatkan kata sandi, kata sandi tidak boleh dikirim ke server yang tidak diautentikasi.

Otentikasi pengguna

Server hanya mengizinkan pengguna jarak jauh masuk jika pengguna itu dapat membuktikan bahwa mereka memiliki hak untuk mengakses akun itu. Bergantung pada konfigurasi server dan pilihan pengguna, pengguna dapat menyajikan salah satu dari beberapa bentuk kredensial (daftar di bawah ini tidak lengkap).

• Pengguna dapat memberikan kata sandi untuk akun yang ia coba masuki; server kemudian memverifikasi bahwa kata sandi itu benar.
• Pengguna dapat menyajikan kunci publik dan membuktikan bahwa ia memiliki kunci pribadi yang terkait dengan kunci publik itu. Ini adalah metode yang persis sama yang digunakan untuk mengotentikasi server, tetapi sekarang pengguna mencoba membuktikan identitas mereka dan server memverifikasi mereka. Upaya login diterima jika pengguna membuktikan bahwa dia tahu kunci privat dan kunci publik ada di daftar otorisasi akun ( ~/.ssh/authorized_keysdi server).
• Jenis metode lain melibatkan pendelegasian bagian dari pekerjaan otentikasi pengguna ke mesin klien. Ini terjadi di lingkungan yang terkendali seperti perusahaan, ketika banyak mesin berbagi akun yang sama. Server mengotentikasi mesin klien dengan mekanisme yang sama yang digunakan sebaliknya, kemudian bergantung pada klien untuk mengotentikasi pengguna.

Teman-teman saya memberi saya jawabannya. Secara default, kunci mengidentifikasi mesin dan bukan pengguna. Jadi kunci disimpan di / etc / ssh /. Itu sebabnya saya mendapat kunci berbeda dari yang disimpan di /root/.ssh