เหตุใดการลงชื่อเข้าใช้อัตโนมัติผ่าน ssh ด้วย authorized

12

ฉันสร้าง dsa-keypair ส่วนตัว / สาธารณะ ฉันได้ใส่กุญแจสาธารณะบนเซิร์ฟเวอร์แล้ว

~/.ssh/authorized_keys

ทุกอย่างถูกตั้งค่าเหมือนกับเซิร์ฟเวอร์อื่น ๆ ของฉัน แต่ดูเหมือนว่าเซิร์ฟเวอร์จะเพิกเฉยต่อความพยายามของฉัน

security ssh login

— Magnar
แหล่งที่มา

ตรวจสอบ/etc/ssh/ssh_configและ/etc/ssh/sshd_configยืนยันว่าไม่มีสิ่งใดที่คุณต้องการถูกปิดใช้งาน

— Kristopher Johnson

คุณจะต้องตรวจสอบ sshd_config ด้วย

— Vagnerr

ขอบคุณ ฉันอัปเดตคำตอบ (ซึ่ง แต่เดิมพูดถึง ssh_config เท่านั้น)

— Kristopher Johnson

การสนทนาทั้งหมดที่กล่าวมานั้นสมบูรณ์แบบสำหรับถ้าคุณใช้สไตล์ openssh ของ ssh หากคุณใช้ระบบ ssh2 ระบบจะมีวิธีที่แตกต่างกันอย่างสิ้นเชิงในการจัดการคีย์ บทความนี้กล่าวถึงชำนาญและอะไร burnz.wordpress.com/2007/12/14/…

— chris

1

โดยปกติแล้วการตรวจสอบ/var/log/auth.logในระบบ Debian หรือ/var/log/secureกับคน RedHat ควรให้คำแนะนำที่ชัดเจนของสิ่งที่ misconfidured (โดยปกติปัญหาสิทธิ์)

— จิโอวานนี่ Toraldo

15

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

อย่าตัดการเชื่อมต่อ ssh ที่ใช้งานอยู่จนกว่าการทดสอบหลังจากที่ได้รับการตรวจสอบพฤติกรรมเป็นไปตามที่คุณคาดหวัง

ตรวจสอบสิ่งที่คุณคิดว่า sshd ควรจะทำ

ข ตรวจสอบการกำหนดค่าที่ถูกต้องโดยใช้ "-t"

ค. เริ่มต้นเซิร์ฟเวอร์ verbose รุ่น 'test' ที่คุณสามารถตรวจสอบได้

d เริ่มการเชื่อมต่อไคลเอนต์ 'ทดสอบ' verbose คุณสามารถตรวจสอบสด

ตรวจสอบสิ่งที่คุณคิดว่า sshd ควรจะทำ

ตรวจทานไฟล์การกำหนดค่า sshd โดยไม่ต้องมีคำอธิบายทั้งหมดที่มีลักษณะดังนี้ (สมมติว่า sshd_config เป็นไฟล์ที่ถูกต้องและใน / etc / ssh)

$ grep -v "^ #" / etc / ssh / sshd_config | grep -v "^ $"

สิ่งนี้จะล้างสิ่งต่าง ๆ ออกไปเพื่อให้เราตรวจสอบสิ่งที่เราคิดว่าเรากำลังเปลี่ยนแปลง (ไม่จำเป็นว่าจะถูกต้องหรือไม่ก็ตาม)

ข ตรวจสอบการกำหนดค่าที่ถูกต้องโดยใช้ "-t"

จากหน้า man ของ sshd ที่ฉันใช้

โหมดการทดสอบ -t ตรวจสอบความถูกต้องของไฟล์กำหนดค่าและความถูกต้องของกุญแจเท่านั้น สิ่งนี้มีประโยชน์สำหรับการอัพเดต sshd ที่เชื่อถือได้เนื่องจากตัวเลือกการกำหนดค่าอาจเปลี่ยนแปลงได้

การเปลี่ยนแปลงอื่น ๆ อาจมีสถานการณ์ที่ลึกซึ้งยิ่งขึ้น ตัวอย่างเช่นอย่าปิดใช้งานการรับรองความถูกต้องของรหัสผ่านจนกว่าคุณจะแน่ใจว่าการรับรองความถูกต้องของรหัสสาธารณะทำงานอย่างถูกต้อง

ค. เริ่มต้นเซิร์ฟเวอร์ verbose รุ่น 'test' ที่คุณสามารถตรวจสอบได้

$ sudo / usr / sbin / sshd -ddd -p 9999

สิ่งนี้จะช่วยให้เซสชันการทำงานที่มีอยู่ของคุณมีอยู่ แต่ให้อินสแตนซ์อื่นของ sshd เพื่อยืนยันการเปลี่ยนแปลงการกำหนดค่าใหม่ SSHD กำลังทำงานในเบื้องหน้าไปยังพอร์ตที่ผู้ใช้กำหนด (9999 ในตัวอย่างของเรา) และผลักดันข้อมูลการดีบักที่มีเสียงดังมากมายคุณสามารถติดตามใน / var / log / authlog (หรืออาจเป็น /var/log/auth.log ขึ้นอยู่กับ บนระบบปฏิบัติการของคุณ)

d เริ่มการเชื่อมต่อไคลเอนต์ 'ทดสอบ' verbose คุณสามารถตรวจสอบสด

เรียกใช้การเชื่อมต่อไคลเอ็นต์ ssh ในโหมด verbose เพื่อแสดงข้อมูลเพิ่มเติมบนหน้าจอของคุณซึ่งอาจทำให้คุณดีขึ้นการดีบักข้อผิดพลาดของคุณ

$ ssh -vvv -p 9999 ชื่อเซิร์ฟเวอร์

ตอนนี้คุณควรมีข้อมูลเพียงพอในแฟ้มบันทึกของเซิร์ฟเวอร์หรือหน้าจอการเชื่อมต่อของไคลเอ็นต์เพื่อแยกปัญหาของคุณ

วิธีการแก้ปัญหาโดยทั่วไปจะมาลงในการอนุญาตไฟล์ (ดังที่แสดงโดย Magnar และ setatakahashi)

ขอให้โชคดี

— samt
แหล่งที่มา

ฉันเดาว่าคุณควรตรวจสอบไฟล์ ssh_config ที่ปลายไคลเอนต์เพื่อให้แน่ใจว่ามันทำในสิ่งที่คุณคาดหวัง ใช้สิ่งที่ต้องการด้านล่างเพื่อ grep out ความคิดเห็น:> grep -v "^ #" / etc / ssh / ssh_config | grep -v "^ $"

— samt

ดีการกำหนดค่า SSH ของลูกค้าสามารถแก้ไขได้ตลอดเวลามันเป็นเซิร์ฟเวอร์ที่คุณถูกล็อคหากคุณกำหนดค่าผิด

— Soviero

33

เซิร์ฟเวอร์จะเพิกเฉยต่อไฟล์ authorized_keys ของคุณหากคุณสมบัติของเจ้าของไม่ถูกต้อง การเปลี่ยนเป็นการแก้ไขนี้:

chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys

— Magnar
แหล่งที่มา

6

SSH -vvv -l ชื่อผู้ใช้ server.domain จะบอกคุณว่าการส่งคีย์ที่ถูกต้องของคุณ

— เดฟเชนีย์

บางครั้งฉันเห็น sshd บ่นเกี่ยวกับการอนุญาตที่ไม่ถูกต้องในไดเรกทอรีบ้าน - ดังนั้นฉันจึงเพิ่ม "chmod o-rwx ~" (หรืออย่างน้อย "chmod ow ~") ลงในรายการตามที่ setatakahashi ทำ ซึ่งมักจะเห็นได้ชัดเมื่อมีการตรวจสอบล็อกไฟล์ - ข้อความแสดงข้อผิดพลาดที่ฉันเห็นมีชี้ไปในทิศทางที่ถูกต้องเสมอ

— Olaf

คำตอบนี้ดูเหมือนจะเป็นไปได้มากที่สุด แต่ความคิดเห็นของ Dave Cheney เป็นวิธีเดียวที่จะเห็นสิ่งที่เกิดขึ้นจริง ตรวจสอบบันทึกเซิร์ฟเวอร์

— dwc

นี่เป็นปัญหาของฉัน ฉันตีหัวของฉันเกี่ยวกับเรื่องนี้เป็นเวลาหลายชั่วโมง ขอบคุณมาก!

— Sam Soffes

1

นี่เป็นการหลอกลวง แต่การอนุญาตก่อนหน้าของฉันคือ0775และ0644ตามลำดับ เหตุใดการลดการอนุญาตจึงช่วยได้ นี่เป็นข้อควรระวังด้านความปลอดภัยที่กำหนดไว้ที่อื่นหรือไม่

— คณบดี

11

$ chmod 700 ~

$ chmod 700 ~ / .ssh

$ chmod 600 ~ / .ssh / authorized_keys

ตรวจสอบแอตทริบิวต์เหล่านี้ใน / etc / ssh / sshd_config

$ sudo grep PubkeyAuthentication / etc / ssh / sshd_config

$ sudo grep Protocol / etc / ssh / sshd_config

— setatakahashi
แหล่งที่มา

2

จุดที่ดีเกี่ยวกับ ~ คุณต้องตรวจสอบให้แน่ใจว่าไม่มีใครอื่นที่ไม่ใช่ตัวเองสามารถเขียนไปยังไดเรกทอรีบ้านของคุณมิฉะนั้นพวกเขาสามารถเปลี่ยนชื่อของคุณ ~ / .ssh ไดเรกทอรี

— เดฟเชนีย์

chmod ครั้งสุดท้ายที่ควรจะเป็น: $ chmod 600 ~/.ssh/authorized_keysไม่$ chmod 600 ~/.sHh/authorized_keys

— SooDesuNe

3

ค่าคุณลักษณะควรเป็นอย่างไร

— ไมเคิล

0

ข้อผิดพลาดที่สำคัญอีกอย่าง ..

หากโฮมไดเร็กตอรี่ของคุณถูกเข้ารหัส sshd จะไม่สามารถเข้าถึง ~ / .ssh / authorized_keys ..

ดูคำตอบนี้

— apriori
แหล่งที่มา

เหตุใดการลงชื่อเข้าใช้อัตโนมัติผ่าน ssh ด้วย authorized_keys จึงไม่ทำงาน