SSH: Keaslian host <host> tidak dapat dibuat

83

apa maksud dari pesan ini? Apakah ini masalah potensial? Apakah salurannya tidak aman?

Atau apakah ini sekadar pesan default yang selalu ditampilkan saat menghubungkan ke server baru?

Saya terbiasa melihat pesan ini ketika menggunakan SSH di masa lalu: Saya selalu memasukkan login saya dengan kata sandi seperti biasa, dan saya merasa baik-baik saja tentang hal itu karena saya tidak menggunakan kunci pribadi / publik (yang jauh lebih aman selain kata sandi singkat). Tapi kali ini saya telah menyiapkan kunci publik dengan ssh untuk koneksi saya ke bitbucket tapi saya masih menerima pesan itu. Saya sadar bahwa prompt frasa sandi di akhir adalah tindakan pengamanan tambahan yang berbeda untuk dekripsi kunci pribadi.

Saya berharap seseorang dapat memberikan penjelasan yang bagus untuk apa yang dimaksud dengan pesan "keaslian ini tidak dapat dipastikan".

The authenticity of host 'bitbucket.org (207.223.240.181)' can't be established.

RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'bitbucket.org,207.223.240.181' (RSA) to the list of
known hosts.
Enter passphrase for key '/c/Users/Steven/.ssh/id_rsa':

ssh security encryption

— Steven Lu
sumber

2

Ini benar-benar salah satu dari pesan-pesan "persis seperti yang dikatakan". Artinya sshtidak ada cara untuk mengatakan bahwa Anda benar-benar berbicara bitbucket.org. Jika Anda mengonfigurasi beberapa cara untuk mengetahuinya, maka itu tidak berfungsi. Jika tidak, berarti Anda tidak melakukannya.

— David Schwartz

71

Ia memberi tahu Anda bahwa Anda belum pernah terhubung ke server ini sebelumnya. Jika Anda mengharapkan itu, itu sangat normal. Jika Anda paranoid, verifikasi checksum / sidik jari kunci menggunakan saluran alternatif. (Tetapi perhatikan bahwa seseorang yang dapat mengalihkan koneksi ssh Anda juga dapat mengalihkan sesi browser web.)

Jika Anda telah terhubung ke server ini sebelumnya dari pemasangan ssh ini, maka server telah dikonfigurasi ulang dengan kunci baru, atau seseorang menipu identitas server. Karena keseriusan serangan pria-di-tengah, itu memperingatkan Anda tentang kemungkinan.

Apa pun itu, Anda memiliki saluran terenkripsi yang aman untuk seseorang . Tidak seorang pun tanpa kunci pribadi yang terkait dengan sidik jari 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40dapat memecahkan kode yang Anda kirim.

Kunci yang Anda gunakan untuk mengautentikasi diri sendiri tidak terkait ... Anda tidak ingin mengirim informasi otentikasi ke server palsu yang mungkin mencurinya, jadi Anda tidak boleh mengharapkan perubahan apa pun tergantung pada apakah Anda akan menggunakan kata sandi atau kunci pribadi untuk login. Anda belum sampai sejauh itu dalam proses.

— Ben Voigt
sumber

Jadi, bahkan jika ada pihak ketiga yang berbahaya, dan saya menolak pesan itu, yang akan saya lakukan adalah mengirimnya kunci publik saya, dan dia masih tidak dapat mendekripsi data saya? Jadi sekarang satu-satunya cara data saya dapat dikompromikan adalah jika (1) kunci pribadi saya dikompromikan atau (2) server bitbucket terganggu atau (3) akun bitbucket saya dikompromikan. Selama mereka membatasi upaya login (yang saya akan sangat terkejut jika mereka tidak melakukannya) sebenarnya tidak ada banyak alasan untuk menjadi paranoid pada saat ini, eh?

— Steven Lu

10

@ Seven: Anda tidak mengirimnya kunci publik Anda, dia sudah memilikinya. Apa yang Anda lakukan adalah menggunakan kunci pribadi Anda untuk mengotentikasi sebuah tantangan ... jika dia terhubung dengan bitbucket.org yang sebenarnya mengaku sebagai Anda, menerima tantangan nyata, dan menggunakan tantangan itu ketika menantang Anda, ia kemudian dapat membodohi Anda menjadi mengirimkan kepadanya respons yang valid yang kemudian ia gunakan untuk mendapatkan akses ke akun Anda di bitbucket.org yang sebenarnya. Dia masih tidak memiliki kunci pribadi Anda, jadi dia tidak bisa masuk di waktu mendatang, atau ke sumber daya lain apa saja yang dibuka kunci, tetapi dia memang memiliki satu sesi masuk.

— Ben Voigt

Itulah yang saya maksud dalam jawaban saya ketika saya berkata "Anda tidak ingin mengirim informasi otentikasi ke server penipuan".

— Ben Voigt

2

"Jika Anda paranoid, verifikasi checksum / sidik jari kunci menggunakan saluran alternatif." Untuk paranoid (dan sebagai catatan), sidik jari github ada di help.github.com/articles/generating-ssh-keys dan bitbucket disebutkan dalam confluence.atlassian.com/display/BITBUCKET/…

— sundar

1

@ BenVoigt Ya, saya mengerti bahwa, paranoid yang benar-benar tentu saja akan sampai ke halaman-halaman itu melalui jaringan yang tidak berhubungan yang berbeda, atau mungkin terbang ke markas github dan mendapatkan sidik jari secara langsung :)

— sundar

21

Katakanlah Anda bertemu seseorang untuk bertukar rahasia bisnis. Penasihat Anda memberi tahu Anda bahwa Anda belum pernah bertemu orang itu sebelumnya, dan itu bisa menjadi penipu. Selanjutnya, untuk pertemuan berikutnya dengannya, penasihat Anda tidak akan memperingatkan Anda lagi. Itulah arti pesan itu. Orang itu adalah server jarak jauh, dan penasihat Anda adalah klien ssh.

Saya tidak berpikir itu paranoid untuk memeriksa ulang identitas orang tersebut sebelum berbagi rahasia dengannya. Misalnya Anda bisa membuka halaman web dengan foto dirinya dan membandingkannya dengan wajah di depan Anda. Atau periksa kartu identitasnya.

Untuk server bitbucket, Anda bisa menggunakan komputer lain yang lebih tepercaya dan mengambil gambar wajahnya , lalu membandingkannya dengan yang Anda dapatkan di komputer yang Anda gunakan sekarang. Menggunakan:

 ssh-keyscan -t rsa bitbucket.org | ssh-keygen -lv -f -

Jika wajah - wajah cocok, Anda dapat menambahkan kunci ke file misalnya ~/.ssh/known_hosts(lokasi standar di banyak distribusi Linux) dengan:

ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts

dan klien ssh tidak akan memperingatkan Anda karena sudah tahu wajahnya . Ini akan membandingkan wajah kapan pun Anda terhubung. Itu sangat penting. Dalam kasus seorang penipu (misalnya serangan orang-di-tengah), klien ssh akan menolak koneksi karena wajah akan berubah.

— Ivan Ogai
sumber

Jawaban ini sangat membantu

— 010110110101

4

Ini harus menjadi jawaban yang diterima: ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts Terima kasih Ivan!

— Rod

1

@Rod: Anda akan memilih jawaban yang diterima berdasarkan pada perintah yang sama sekali tidak perlu (Anda dapat memodifikasi known_hostshanya dengan mengetikkan "ya" ke peringatan asli, seperti yang telah ditunjukkan dalam pertanyaan) dan berbahaya (kunci yang Anda tambahkan ke Anda file tidak harus sama dengan yang Anda lihat, karena Anda mengambilnya dua kali!)?

— Ben Voigt

@ BenVoigt apa solusi ini menyediakan bahwa mengetik "ya" tidak adalah bahwa solusi ini sepenuhnya skrip. Saya berasumsi sebagian besar orang dapat mengetahui bagaimana menanggapi "(ya / tidak)?" cepat. Saya menemukan T&J ini ketika mencoba mencari cara untuk menyelesaikan masalah ini tanpa campur tangan manusia (untuk skrip pengaturan server). Dalam kegembiraan saya, saya kira saya tidak memperhatikan bahwa pertanyaan OP sedikit berbeda dari pertanyaan saya, tetapi IMO ini masih merupakan jawaban yang paling berguna / tidak jelas di utasnya.

— Rod

1

@Rod: Tidak, ini tidak berguna. Menurunkan keamanan Anda buruk. Menemukan cara yang lebih cepat untuk menurunkan keamanan Anda adalah kebalikan dari manfaat.

— Ben Voigt

5

Saya hanya harus membuat known_hostsfile teks dalam~/.ssh

sudo vim ~/.ssh/known_hosts
sudo chmod 777 ~/.ssh/known_hosts

Setelah melakukan ini, ia menambahkan tuan rumah dan saya tidak pernah melihat pesan itu lagi.

— Brian
sumber

Saya tidak berpikir itu benar-benar mengubah apa pun. Peringatan ditampilkan ketika server itu sendiri telah berubah. Misalnya jika Anda menyediakan mesin virtual baru yang Anda sambungkan untuk pertama kalinya. Apakah Anda memiliki known_hostsfile (dengan izin yang benar) atau tidak, ia tidak menghentikannya untuk menanyakan keaslian server baru ... Kecuali Anda telah mengambil tanda tangan kunci pub untuk server ini dan memasukkannya ke dalam known_hosts, yang merupakan satu cara normal untuk melewati cek (meskipun hanya mengatakan "ya" untuk cek sering lebih cepat untuk mencapai yang sama)

— Steven Lu

Terima kasih. Saya sudah tahu host, tapi terus mendapat peringatan. Saya hanya perlu mengubah izin pada known_hosts agar peringatan berhenti.

— ArcaneDominion

6

Tolong jangan lakukan ini. Dapat menjadi bahaya keamanan yang serius. File host Anda seharusnya hanya dapat ditulis oleh Anda. Perintah kedua pada dasarnya memungkinkan siapa pun di komputer Anda melakukan spoof identitas server.

— Stolz

"Peringatan itu ditampilkan ketika server itu sendiri telah berubah." Atau ketika server belum pernah dikunjungi sebelumnya.

— Rod

2

Ada cara mudah lainnya Cukup sentuh file "config" di bawah /root/.ssh dan tambahkan parameter StrictHostKeyPeriksa tidak. Lain kali ketika Anda masuk ke server, mereka akan menambahkan kunci ke server yang dikenal dan tidak akan meminta "ya" untuk konfirmasi keaslian

— Usman
sumber

3

Ini tidak disarankan. Itu mudah tetapi bukan cara yang benar untuk menghadapi situasi tersebut.

— Vikas

1

Pesan ini hanya SSH yang memberi tahu Anda bahwa itu belum pernah melihat kunci host khusus ini sebelumnya, sehingga tidak dapat benar-benar memverifikasi bahwa Anda terhubung ke host yang Anda pikir. Ketika Anda mengatakan "Ya" itu menempatkan kunci ssh ke dalam file known_hosts Anda, dan kemudian pada koneksi berikutnya akan membandingkan kunci yang didapatnya dari host dengan yang ada di file known_hosts.

Ada artikel terkait tentang stack overflow yang menunjukkan cara menonaktifkan peringatan ini, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cname-be-established .

— Mike
sumber

10

Tetapi menonaktifkan peringatan tidak dianjurkan - itu ada untuk suatu tujuan, memberikan informasi keamanan yang sangat berguna.

— Rory Alsop

0

Terlepas dari jawaban yang telah diberikan (Anda tidak pernah terhubung ke host ini sebelumnya), ada juga kemungkinan berbeda bahwa Anda tidak pernah menghubungkan DARI host saat ini sebelumnya (ke host itu); ini hanya berbeda secara psikologis; Anda pikir Anda terhubung dari host A (ke B), sementara Anda benar-benar mencoba untuk terhubung dari host X (ke B). Misalnya ini dapat terjadi ketika Anda pertama kali ssh-ed dari A ke X dan kemudian dari terminal yang sama mencoba untuk ssh ke B berpikir Anda masih di A.

— Carlo Wood
sumber

Saya ingin tahu apakah menggunakan penerusan ssh agent juga dapat menekan peringatan jika host A tahu tentang B tetapi X tidak, tetapi penerusan agen berlangsung antara A dan X. Sebagian besar lingkungan (yang menyediakan ssh) dan aplikasi terminal mendukung penerusan agen, membantu kurangi jumlah kunci ssh yang harus Anda kelola hanya untuk perangkat akhir Anda.

— Steven Lu

0

Dalam kasus saya kata sandi lebih sedikit login tidak berfungsi karena izin direktori rumah saya karena saya mengubah pengaturan default. Akhirnya, inilah yang bekerja untuk saya. izin direktori home saya adalah

/ home / nama pengguna

drwxr----x. 18 username     groupname  4096 May 11 11:52 username

/home/username/.ssh

268823097 drwx------   2 username groupname     29 May 11 11:53 .ssh

/home/username/.ssh/authorized_keys

-rw-r----- 1 username groupname 402 May 11 11:53 authorized_keys

— Mian Asbat Ahmad
sumber