ssh: Keaslian 'hostname' host tidak dapat ditetapkan


153

Ketika saya ssh ke mesin, kadang-kadang saya mendapatkan peringatan kesalahan ini dan itu meminta untuk mengatakan "ya" atau "tidak". Ini menyebabkan beberapa masalah saat menjalankan dari skrip yang secara otomatis ssh ke mesin lain.

Pesan peringatan:

The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is    SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.

Apakah ada cara untuk secara otomatis mengatakan "ya" atau mengabaikan ini?


27
Saya akan menyarankan hal ini. Anda perlu mencari tahu mengapa Anda mendapatkan kesalahan ini, jika tidak, Anda membuka diri terhadap seorang pria di tengah serangan, yang mana kesalahan ini mencoba melindungi Anda dari.
Peter Bagnall

3
Ini bisa disebabkan oleh perubahan di server menggunakan kunci ssh itu, atau itu bisa disebabkan oleh seseorang yang duduk di antara Anda dan server mendengarkan semua yang Anda kirim / terima.
derekdreery

apa yang bisa menjadi alasan untuk kesalahan ini?
AiU

Saya tidak setuju dengan poin Peter. Dalam sebuah organisasi besar berusaha membuat orang lain untuk memperbaiki masalah seperti itu ketika Anda hanya berusaha menyelesaikan pekerjaan Anda tidak realistis.
Sridhar Sarnobat

Banyak organisasi besar justru kebalikan dari apa yang disarankan @SridharSarnobat. Anda harus memastikan orang yang tepat memecahkan masalah semacam itu, dan berusaha mengatasi masalah itu hanya akan memperburuk keadaan.
James Moore

Jawaban:


135

Bergantung pada klien ssh Anda, Anda dapat mengatur opsi StrictHostKeyChecking ke no pada baris perintah, dan / atau mengirim kunci ke file null known_hosts. Anda juga dapat mengatur opsi ini dalam file konfigurasi Anda, baik untuk semua host atau untuk set alamat IP atau nama host yang diberikan.

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

EDIT

Seperti yang dicatat @IanDunn, ada risiko keamanan untuk melakukan ini. Jika sumber daya yang Anda hubungkan telah dipalsukan oleh penyerang, mereka berpotensi dapat memutar ulang tantangan server tujuan kembali kepada Anda, membodohi Anda dengan berpikir bahwa Anda terhubung ke sumber daya jarak jauh sementara pada kenyataannya mereka terhubung ke sumber daya dengan kredensial Anda. Anda harus hati-hati mempertimbangkan apakah itu risiko yang pantas diambil sebelum mengubah mekanisme koneksi Anda untuk melewati HostKeyChecking.

Referensi .


40
Saya pikir tidak bertanggung jawab untuk merekomendasikan ini tanpa peringatan tentang implikasi keamanan. superuser.com/a/421084/121091 adalah jawaban IMO yang lebih baik.
Ian Dunn

5
@IanDunn Saya setuju dengan Anda dalam situasi klien SSH umum, tetapi mengingat bahwa OP dengan jelas menyatakan bahwa ia menghadapi masalah ini saat menjalankan skrip, alternatifnya adalah memecahkan skrip setiap kali kunci host berubah (dan ada sejumlah alasan mengapa mungkin itu masalahnya) yang jawabannya tidak Anda selesaikan. Yang mengatakan, ini adalah kritik yang valid, jadi saya telah memperbarui jawaban saya untuk menunjukkan risikonya.
cori

6
Saya tidak percaya begitu banyak orang yang telah mengangkat jawaban ini dan juga diterima oleh si penanya. Pendekatan ini memintas pemeriksaan keamanan dan menghubungkannya ke host jarak jauh. Periksa apakah file known_hosts di folder ~ / .ssh / memiliki izin menulis. Jika tidak, gunakan jawaban ini stackoverflow.com/a/35045005/2809294
ARK

Selama Anda tahu apa yang Anda lakukan, ini adalah solusi terbaik. Saya memiliki situs web internal yang secara otomatis terhubung ke kami yang memiliki BANYAK, memperbarui (secara acak) alamat IP. Saya menambahkan ini ke ~ / .ssh / config dan hanya berfungsi. Pikiran Anda, saya TAHU bahwa situs ini adalah apa yang saya pikirkan dan jika tidak, orang jahat tidak memiliki keuntungan, karena saya tahu data apa yang sedang ditransfer.
user1683793

75

Pertanyaan lama yang pantas dijawab.

Anda dapat mencegah prompt interaktif tanpa menonaktifkan StrictHostKeyChecking(yang tidak aman).

Masukkan logika berikut ke dalam skrip Anda:

if [ -z "$(ssh-keygen -F $IP)" ]; then
  ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi

Ia memeriksa apakah kunci publik dari server masuk known_hosts. Jika tidak, ia meminta kunci publik dari server dan menambahkannya ke known_hosts.

Dengan cara ini Anda terkena serangan Man-In-The-Middle hanya sekali, yang dapat dikurangi dengan:

  • memastikan bahwa skrip terhubung pertama kali melalui saluran aman
  • memeriksa log atau diketahui_host untuk memeriksa sidik jari secara manual (hanya dilakukan sekali)

4
Atau hanya mengelola file known_hosts untuk semua mesin sebagai bagian dari pengaturan konfigurasi infrastruktur Anda.
Thilo

1
perhatikan bahwa ssh-keyscan tidak berfungsi dengan ProxyCommand: marc.info/?l=openssh-unix-dev&m=108446567718763&w=2
Richlv

1
itu tidak akan berfungsi seperti yang diharapkan. `ssh-keygen -F $IP`seharusnya "`ssh-keygen -F $IP`"(dalam tanda kutip), dalam kasus lain itu tidak akan ditafsirkan sebagai string
avtomaton

Atau sebagai oneliner menggunakan nilai pengembalian ssh-kegen:ssh-keygen -F $IP >/dev/null || ssh-keyscan -H $IP >> ~/.ssh/known_hosts
Gohu

38

Untuk menonaktifkan (atau mengontrol penonaktifan), tambahkan baris berikut ke awal /etc/ssh/ssh_config...

Host 192.168.0.*
   StrictHostKeyChecking=no
   UserKnownHostsFile=/dev/null

Pilihan:

  • Subnet Host dapat *memungkinkan akses tidak terbatas ke semua IP.
  • Edit /etc/ssh/ssh_configuntuk konfigurasi global atau ~/.ssh/configuntuk konfigurasi khusus pengguna.

Lihat http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

Pertanyaan serupa di superuser.com - lihat https://superuser.com/a/628801/55163


19

Pastikan ~/.ssh/known_hostsbisa ditulisi. Itu memperbaikinya bagi saya.


4
apakah aman untuk mengizinkan semua orang menulis ke known_hosts?
akaRem

2
@akaRem jelas tidak. Biasanya Anda ingin hanya dapat ditulisi oleh pengguna yang memiliki .sshfolder itu.
2rs2ts

izinnya 0400optimal (tolong perbaiki saya siapa saja) namun dalam kasus saya masalahnya hanyalah bahwa .sshfolder untuk pengguna saya telah berubah kepemilikannya - sehingga membatalkan izin saya sendiri 0400. sudomengubah kepemilikan kembali kepada saya menyelesaikan masalah saya.
Charney Kaye

Yang ini memperbaiki masalah bagi saya.
Sivaji

14

Cara terbaik untuk melakukannya adalah dengan menggunakan 'BatchMode' di samping 'StrictHostKeyChecking'. Dengan cara ini, skrip Anda akan menerima nama host baru dan menulisnya ke file known_hosts, tetapi tidak akan memerlukan intervensi ya / tidak.

ssh -o BatchMode=yes -o StrictHostKeyChecking=no user@server.example.com "uptime"

10

Edit file konfigurasi Anda yang biasanya terletak di '~ / .ssh / config', dan pada awal file, tambahkan baris di bawah ini

Host *
    User                   your_login_user
    StrictHostKeyChecking  no
    IdentityFile          ~/my_path/id_rsa.pub

Set pengguna untuk your_login_usermengatakan bahwa pengaturan ini milik your_login_user
StrictHostKeyChecking Anda setel ke tidak akan menghindari prompt
IdentityFile adalah jalur ke kunci RSA

Ini bekerja untuk saya dan skrip saya, semoga sukses untuk Anda.


Terima kasih hari ini benar-benar menyelamatkan. Tapi untuk apa baris terakhir IdentityFile? Tampaknya bekerja tanpa itu juga ..
supersan

7

Peringatan ini dikeluarkan karena fitur keamanan, jangan menonaktifkan fitur ini.

Hanya ditampilkan sekali.

Jika masih muncul setelah koneksi kedua, masalahnya mungkin secara tertulis ke known_hostsfile. Dalam hal ini Anda juga akan mendapatkan pesan berikut:

Failed to add the host to the list of known hosts 

Anda dapat memperbaikinya dengan mengubah pemilik mengubah izin file agar dapat ditulis oleh pengguna Anda.

sudo chown -v $USER ~/.ssh/known_hosts

5

Dengan mengacu pada jawaban Cori, saya memodifikasinya dan menggunakan perintah di bawah ini, yang berfungsi. Tanpa exit, perintah yang tersisa sebenarnya masuk ke mesin jarak jauh, yang tidak saya inginkan dalam skrip

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"

5

Lakukan ini -> chmod +w ~/.ssh/known_hosts. Ini menambahkan izin menulis ke file di ~/.ssh/known_hosts. Setelah itu host jarak jauh akan ditambahkan ke known_hostsfile ketika Anda terhubung ke waktu berikutnya.


4

Idealnya, Anda harus membuat otoritas sertifikat yang dikelola sendiri. Mulai dengan membuat pasangan kunci: ssh-keygen -f cert_signer

Kemudian tandatangani kunci host publik setiap server: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Ini menghasilkan kunci host publik yang ditandatangani: /etc/ssh/ssh_host_rsa_key-cert.pub

Di /etc/ssh/sshd_config, arahkan HostCertificateke file ini: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Mulai kembali layanan sshd: service sshd restart

Kemudian pada klien SSH, tambahkan berikut ini ke ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

Di atas berisi:

  • @cert-authority
  • Domain *.example.com
  • Isi lengkap kunci publik cert_signer.pub

The cert_signerkunci publik akan percaya server apapun yang kunci publik tuan rumah ditandatangani oleh cert_signerkunci pribadi.

Meskipun ini membutuhkan konfigurasi satu kali di sisi klien, Anda dapat memercayai beberapa server, termasuk yang belum ditetapkan (selama Anda menandatangani setiap server, yaitu).

Untuk lebih jelasnya, lihat halaman wiki ini .


2

Secara umum masalah ini terjadi ketika Anda sering memodifikasi tombol. Berdasarkan server, mungkin perlu waktu untuk memperbarui kunci baru yang telah Anda buat dan tempelkan di server. Jadi setelah membuat kunci dan menempel di server, tunggu selama 3 hingga 4 jam dan kemudian coba. Masalahnya harus dipecahkan. Itu terjadi pada saya.



0

Jalankan ini di server host itu masalah firasat

chmod -R 700 ~/.ssh

apakah Anda meminta orang lain untuk mengubah izin pada otor_keys dan kunci publik dari 644 menjadi 700? Dan kunci pribadi dari 600 hingga 700?
nurettin

0

Saya memiliki kesalahan yang sama dan ingin menarik perhatian pada kenyataan bahwa - seperti yang terjadi pada saya - Anda mungkin hanya memiliki hak yang salah.
Anda telah mengatur .sshdirektori Anda sebagai biasa atau rootpengguna dan dengan demikian Anda harus menjadi pengguna yang benar. Ketika kesalahan ini muncul, saya roottetapi saya dikonfigurasi .sshsebagai pengguna biasa. Keluar rootmemperbaikinya.


-3

Saya mengatasi masalah yang memberikan kesalahan tertulis di bawah ini:
Kesalahan:
Keaslian host 'XXX.XXX.XXX' tidak dapat dibuat.
Sidik jari kunci RSA adalah 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89.

Larutan:
1. instal alat openSSH apa pun.
2. jalankan perintah ssh
3. ia akan meminta Anda menambahkan host ini seperti. terima YA.
4. Host ini akan menambahkan daftar host yang dikenal.
5. Sekarang Anda dapat terhubung dengan host ini.

Solusi ini berfungsi sekarang ......


Ini tidak menjawab pertanyaan. Pertanyaan asli (sangat lama) adalah tentang kemampuan untuk secara otomatis mengkonfirmasi permintaan tersebut melalui skrip.
MasterAM

Jika itu berhasil untuknya, mungkin itu bekerja untuk orang lain. Tidak perlu
meng-

menjalankan "ssh" tidak berfungsi. Itu ditampilkan untuk penggunaan opsi: ssh [..] [..] [..] [user @] nama host [perintah]
P Satish Patro
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.