ssh: ความถูกต้องของโฮสต์ 'ชื่อโฮสต์' ไม่สามารถสร้างได้

เมื่อฉัน ssh ไปยังเครื่องบางครั้งฉันได้รับคำเตือนข้อผิดพลาดนี้และจะแจ้งให้ "ใช่" หรือ "ไม่" สิ่งนี้ทำให้เกิดปัญหาเมื่อเรียกใช้จากสคริปต์ที่ ssh ไปยังเครื่องอื่นโดยอัตโนมัติ

ข้อความเตือน:

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.

มีวิธีที่จะพูดว่า "ใช่" หรือเพิกเฉยต่อสิ่งนี้โดยอัตโนมัติหรือไม่?

ขึ้นอยู่กับไคลเอ็นต์ ssh ของคุณคุณสามารถตั้งค่าตัวเลือก StrictHostKeyChecking เป็น no บนบรรทัดคำสั่งและ / หรือส่งคีย์ไปยังไฟล์ null known_hosts คุณยังสามารถตั้งค่าตัวเลือกเหล่านี้ในไฟล์ปรับแต่งของคุณไม่ว่าจะสำหรับโฮสต์ทั้งหมดหรือชุดที่อยู่ IP หรือชื่อโฮสต์ที่กำหนด

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

แก้ไข

ตามที่ @IanDunn มีความเสี่ยงด้านความปลอดภัยในการทำเช่นนี้ หากทรัพยากรที่คุณกำลังเชื่อมต่อถูกโจมตีโดยผู้โจมตีพวกเขาอาจเล่นความท้าทายของเซิร์ฟเวอร์ปลายทางกลับมาที่คุณหลอกคุณให้คิดว่าคุณกำลังเชื่อมต่อกับทรัพยากรระยะไกลในขณะที่พวกเขากำลังเชื่อมต่อกับทรัพยากรนั้นด้วย ข้อมูลประจำตัวของคุณ คุณควรพิจารณาอย่างรอบคอบว่าเป็นความเสี่ยงที่เหมาะสมหรือไม่ก่อนเปลี่ยนกลไกการเชื่อมต่อเพื่อข้าม HostKeyChecking

การอ้างอิง

คำถามเก่าที่ควรได้รับคำตอบที่ดีกว่า

คุณสามารถป้องกันพรอมต์แบบโต้ตอบโดยไม่ต้องปิดการใช้งานStrictHostKeyChecking(ซึ่งไม่ปลอดภัย)

รวมตรรกะดังต่อไปนี้ลงในสคริปต์ของคุณ:

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

จะตรวจสอบว่ากุญแจสาธารณะของเซิร์ฟเวอร์อยู่known_hostsหรือไม่ known_hostsถ้าไม่ได้ก็ขอคีย์สาธารณะจากเซิร์ฟเวอร์และเพิ่มการ

ด้วยวิธีนี้คุณจะได้สัมผัสกับการโจมตี Man-In-The-Middle เพียงครั้งเดียวซึ่งอาจบรรเทาได้โดย:

• ตรวจสอบให้แน่ใจว่าสคริปต์เชื่อมต่อเป็นครั้งแรกผ่านช่องทางที่ปลอดภัย
• การตรวจสอบบันทึกหรือ known_hosts เพื่อตรวจสอบลายนิ้วมือด้วยตนเอง (ต้องทำเพียงครั้งเดียวเท่านั้น)

หากต้องการปิดใช้งาน (หรือปิดใช้งานการควบคุม) ให้เพิ่มบรรทัดต่อไปนี้ที่จุดเริ่มต้นของ/etc/ssh/ssh_config...

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

ตัวเลือก:

• ซับเน็ตโฮสต์สามารถ*อนุญาตให้เข้าถึง IP ทั้งหมดได้ไม่ จำกัด
• แก้ไข/etc/ssh/ssh_configสำหรับการกำหนดค่าทั่วโลกหรือ~/.ssh/configการกำหนดค่าเฉพาะผู้ใช้

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

คำถามที่คล้ายกันใน superuser.com - ดูhttps://superuser.com/a/628801/55163

ตรวจสอบให้แน่ใจว่า~/.ssh/known_hostsสามารถเขียนได้ นั่นแก้ไขให้ฉัน

วิธีที่ดีที่สุดในการทำเช่นนี้คือการใช้ 'BatchMode' นอกเหนือจาก 'StrictHostKeyChecking' ด้วยวิธีนี้สคริปต์ของคุณจะยอมรับชื่อโฮสต์ใหม่และเขียนลงในไฟล์ known_hosts แต่ไม่จำเป็นต้องมีการแทรกแซงใช่ / ไม่

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

แก้ไขไฟล์กำหนดค่าของคุณตามปกติอยู่ที่ '~ / .ssh / config' และเมื่อเริ่มต้นไฟล์ให้เพิ่มบรรทัดด้านล่าง

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

ผู้ใช้ตั้งค่าให้your_login_userบอกว่าการตั้งค่านี้เป็นของ your_login_user
StrictHostKeyChecking ตั้งค่าเป็นไม่จะหลีกเลี่ยงพรอมต์
IdentityFile คือพา ธ ไปยังคีย์ RSA

สิ่งนี้ใช้ได้กับฉันและสคริปต์ของฉันโชคดีสำหรับคุณ

คำเตือนนี้ออกเนื่องจากคุณสมบัติความปลอดภัยห้ามปิดใช้งานคุณสมบัตินี้

มันจะแสดงเพียงครั้งเดียว

หากยังคงปรากฏขึ้นหลังจากเชื่อมต่อครั้งที่สองแสดงว่าอาจมีปัญหาในการเขียนลงknown_hostsไฟล์ ในกรณีนี้คุณจะได้รับข้อความต่อไปนี้:

Failed to add the host to the list of known hosts 

คุณสามารถแก้ไขได้โดยเปลี่ยนเจ้าของการเปลี่ยนการอนุญาตของไฟล์ที่ผู้ใช้ของคุณสามารถเขียนได้

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

จากการอ้างอิงถึงคำตอบของ Cori ฉันได้แก้ไขและใช้คำสั่งด้านล่างซึ่งใช้งานได้ หากไม่มีexitคำสั่งที่เหลือก็เข้าสู่ระบบเครื่องระยะไกลซึ่งฉันไม่ต้องการในสคริปต์

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

ทำเช่นนี้ chmod +w ~/.ssh/known_hosts-> ~/.ssh/known_hostsนี้จะเพิ่มสิทธิ์ในการเขียนไปยังแฟ้มที่ หลังจากนั้นโฮสต์ระยะไกลจะถูกเพิ่มลงในknown_hostsไฟล์เมื่อคุณเชื่อมต่อในครั้งต่อไป

คุณควรสร้างหน่วยงานออกใบรับรองที่จัดการด้วยตนเอง เริ่มต้นด้วยการสร้างคู่ที่สำคัญ: ssh-keygen -f cert_signer

จากนั้นลงชื่อคีย์สาธารณะของแต่ละเซิร์ฟเวอร์: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

สิ่งนี้สร้างรหัสโฮสต์สาธารณะที่ลงนามแล้ว: /etc/ssh/ssh_host_rsa_key-cert.pub

ใน/etc/ssh/sshd_configชี้HostCertificateไปที่ไฟล์นี้: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

เริ่มบริการ sshd: service sshd restart

จากนั้นในไคลเอนต์ SSH เพิ่มต่อไปนี้เพื่อ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

ข้างต้นประกอบด้วย:

• @cert-authority
• โดเมน *.example.com
• เนื้อหาทั้งหมดของกุญแจสาธารณะ cert_signer.pub

รหัสcert_signerสาธารณะจะเชื่อถือเซิร์ฟเวอร์ใด ๆ ที่มีรหัสโฮสต์สาธารณะที่ลงนามโดยcert_signerรหัสส่วนตัว

แม้ว่าสิ่งนี้ต้องการการกำหนดค่าแบบครั้งเดียวที่ฝั่งไคลเอ็นต์ แต่คุณสามารถเชื่อถือเซิร์ฟเวอร์ได้หลายเครื่องรวมถึงเซิร์ฟเวอร์ที่ยังไม่ได้รับการจัดเตรียม (ตราบใดที่คุณลงชื่อในแต่ละเซิร์ฟเวอร์นั่นคือ)

สำหรับรายละเอียดเพิ่มเติมโปรดดูที่หน้าวิกินี้

โดยทั่วไปปัญหานี้เกิดขึ้นเมื่อคุณแก้ไขคีย์บ่อยครั้งมาก อาจต้องใช้เวลาสักครู่ในการอัปเดตคีย์ใหม่ที่คุณสร้างและวางในเซิร์ฟเวอร์โดยใช้เซิร์ฟเวอร์ ดังนั้นหลังจากสร้างรหัสและวางในเซิร์ฟเวอร์แล้วรอ 3 ถึง 4 ชั่วโมงแล้วลอง ปัญหาควรได้รับการแก้ไข มันเกิดขึ้นกับฉัน

เพิ่มสิ่งเหล่านี้ใน / etc / ssh / ssh_config ของคุณ

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

เรียกใช้สิ่งนี้ในเซิร์ฟเวอร์โฮสต์ซึ่งเป็นปัญหาลางสังหรณ์

chmod -R 700 ~/.ssh

ฉันมีข้อผิดพลาดเดียวกันและต้องการที่จะดึงความสนใจไปที่ความจริงที่เกิดขึ้นกับฉัน - คุณอาจมีสิทธิ์ผิด
คุณได้ตั้งค่า.sshไดเรกทอรีของคุณเป็นแบบปกติหรือแบบrootผู้ใช้และคุณต้องเป็นผู้ใช้ที่ถูกต้อง เมื่อข้อผิดพลาดนี้ปรากฏขึ้นฉันเป็นrootแต่ฉันกำหนดค่า.sshเป็นผู้ใช้ปกติ ออกจากการrootแก้ไขแล้ว

ฉันแก้ปัญหาข้อผิดพลาดที่เขียนด้านล่าง:
ข้อผิดพลาด:
ไม่สามารถสร้างความถูกต้องของโฮสต์ 'XXX.XXX.XXX' ได้
ลายนิ้วมือคีย์ RSA คือ 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89

การแก้ไข:
1. ติดตั้งเครื่องมือ openSSH ใด ๆ
2. รันคำสั่ง ssh
3. มันจะขอให้คุณเพิ่มโฮสต์นี้เช่น ยอมรับใช่
4. โฮสต์นี้จะเพิ่มในรายการโฮสต์ที่รู้จัก
5. ตอนนี้คุณสามารถเชื่อมต่อกับโฮสต์นี้ได้แล้ว

โซลูชันนี้ใช้งานได้ในขณะนี้ ......