ssh แฮงค์โดยไม่ต้องใส่รหัสผ่าน - ทำงานในรูทหรือบัญชีอื่น ๆ

ฉันใช้การเข้าสู่ระบบตามคีย์ ssh ทำงานได้ดี จากนั้นฉันเปลี่ยนชื่อโฮสต์บนคอมพิวเตอร์ของฉันและการลงชื่อเข้าใช้ด้วยรหัสหลักหยุดทำงาน ดูเหมือนจะทำให้รู้สึก กุญแจอาจอาศัยชื่อโฮสต์เดิมของฉัน ดังนั้นฉันจึงลบกุญแจทั้งหมดของฉันและไฟล์ทั้งหมดใน ~ / .ssh / และสร้างใหม่ (และเปลี่ยนที่ได้รับอนุญาตบนเซิร์ฟเวอร์ที่ฉันเชื่อมต่อ)

ตอนนี้ทุกครั้งที่ฉันพยายามที่จะ ssh มันก็แค่แฮงค์โดยไม่ถามรหัสผ่านไม่ว่าฉันจะพยายามที่จะ ssh แม้แต่เซิร์ฟเวอร์ที่ฉันไม่ได้ตั้งค่าการเข้าสู่ระบบตามคีย์ ไม่มีอะไรใน. ssh / config

นอกจากนี้เมื่อฉัน 's -' เพื่อรูต, ssh ทำงานได้อย่างสมบูรณ์แบบ ไม่มีปัญหาเลย สิ่งนี้จะเกิดขึ้นกับบัญชีผู้ใช้ของฉันเท่านั้น

ด้านล่างนี้คือข้อมูลการดีบักจาก ssh

ssh -vv mylogin@myremoteserver.com
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 มีนาคม 2552
debug1: การอ่านข้อมูลการกำหนดค่า /Users/myname/.ssh/config
debug1: กำลังอ่านข้อมูลการกำหนดค่า / usr / etc / ssh_config
......
debug1: โฮสต์ 'myremoteserver.com' เป็นที่รู้จักและตรงกับคีย์โฮสต์ RSA
debug1: พบคีย์ใน /Users/myname/.ssh/known_hosts:1
debug2: bits set: 512/1024
debug1: ssh_rsa_verify: ลายเซ็นถูกต้อง
debug2: kex_derive_keys
debug2: set_newkeys: โหมด 1
debug1: SSH2_MSG_NEWKEYS ส่งแล้ว
debug1: ต้องการ SSH2_MSG_NEWKEYS
debug2: set_newkeys: โหมด 0
debug1: ได้รับ SSH2_MSG_NEWKEYS แล้ว
debug1: SSH2_MSG_SERVICE_REQUEST ส่งแล้ว
debug2: service_accept: ssh-userauth
debug1: ได้รับ SSH2_MSG_SERVICE_ACCEPT

และจากนั้นมันก็แขวนอยู่ที่นี่ .....

นี่คือเอาต์พุต dtruss (เช่น strace แต่สำหรับ OSX) เอาต์พุตใกล้กับส่วนท้ายที่แฮง: sudo dtruss ssh -vv mylogin@myremoteserver.com

เลือก (0x4, 0x508200, 0x0, 0x0, 0x0) = 1 0
อ่าน (0x3, "$ \ 222 \ 351 {L \ 363 \ 261 \ 25063sN \ 216 \ 300 @ q7 \ 203 \ 276b \ 257 \ 354 \ 337 \ 356 \ 260! {\ 342 \ 017 \ 271 = \ 222, \ 245 \ 347t \ 006 \ 225 \ 257 \ 333; \ 204 \ 020] \ 242 \ 005z # \ 0 ", 0x2000) = 48 0
เขียน (0x2, "debug2: service_accept: ssh-userauth \ r \ n \ 0", 0x26) = 38 0
เชื่อมต่อ (0x4, 0xBFFFEEA2, 0x6A) = 0 0
เขียน (0x4, "\ 0", 0x4) = 4 0
เขียน (0x4, "\ v5 \ 004 \ 0", 0x1) = 1 0
อ่าน (0x4, "\ 0", 0x4) = -1 Err # 4

ดูเหมือนว่าจะพยายามอ่านอะไรซักอย่าง หากใครมีข้อเสนอแนะหรือความคิดฉันจะขอบคุณมาก!

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

หากต้องการรับการยืนยันคุณสามารถลองดังต่อไปนี้:

unset SSH_AUTH_SOCK
ssh mylogin@myremoteserver.com

หากคุณถูกขอให้ป้อนวลีรหัสผ่านไปยัง ssh_key ของคุณหมายความว่าคุณมีปัญหากับ ssh-agent ของคุณ

ดูโพสต์ของฉันในคำถามที่เกี่ยวข้องนี้

ฉันสนใจ DNS แบบย้อนกลับได้ไหม

โดยพื้นฐานแล้วไคลเอ็นต์กำลังทำ DNS ย้อนกลับบนเซิร์ฟเวอร์หรือในทางกลับกัน

ฉันเสนอการทดสอบ:

ปิดใช้งานการค้นหา DNS บนเซิร์ฟเวอร์โดยแก้ไข / etc / ssh / sshd_config และตรวจสอบให้แน่ใจว่า "UseDNS" ถูกตั้งค่าเป็น "ไม่"

เรียกใช้ "service ssh reload" (หรืออะไรก็ตามที่ทำให้ ssh daemon ของคุณทำการอ่านการกำหนดค่าใหม่) จากนั้นลองอีกครั้ง

บังเอิญไม่มีความสุขที่จะเตือนคุณหลังจากผ่านไปนานนานใช่ไหม?

อีกสิ่งที่คุณอาจตรวจสอบคือดูเนื้อหาของ / etc / hosts บนเซิร์ฟเวอร์เพื่อให้แน่ใจว่าไม่มีอะไรผิดปกติ

ตรวจสอบการอนุญาตในไดเรกทอรี ~ / .ssh และไฟล์ในนั้น umask เริ่มต้นของคุณอาจได้รับอนุญาตมากเกินไป & เมื่อคุณสร้างไฟล์ใหม่คุณอาจได้รับสิทธิ์ผิดโดยไม่ตั้งใจ ฉันถูกเผาโดยตัวเองสองสามครั้งนี้ ไม่มีไคลเอ็นต์ ssh (หรือเซิร์ฟเวอร์) ที่ฉันเคยใช้ให้ข้อความแสดงข้อผิดพลาดที่เป็นประโยชน์เกี่ยวกับเรื่องนี้ ...

คุณมีพื้นที่ว่างดิสก์บนไคลเอนต์ของคุณ (และบนเซิร์ฟเวอร์ของคุณ)?

df -h

ฉันมีปัญหาที่คล้ายกัน

ssh domain.ip:user.name

ดูเหมือนว่าฉันจะสามารถหลีกเลี่ยงปัญหานี้ได้ด้วยการบังคับให้ชื่อเข้าสู่ระบบเป็นเช่นนั้น

ssh -v domain.ip -l user.name

สำหรับฉันการอัพเกรดเป็น Snow Leopard แก้ปัญหาได้แล้ว ดังนั้นฉันคิดว่ามันเกี่ยวข้องกับบั๊กใน OSX

หากเป็นเพราะคีย์ที่บันทึกไว้คุณควรจะสามารถลบมันออกจากไดเรกทอรี ~ / .ssh ของคุณในไฟล์ known_hosts เพียงค้นหารายการและลบออกจากนั้นควรแจ้งให้คุณอีกครั้ง

ในทางกลับกันควรให้คำเตือนเมื่อโฮสต์ไม่ตรงกับสิ่งที่บันทึกไว้

ฉันมีปัญหาที่ OS X การค้นหาชื่อโฮสต์ทำหน้าที่เหมือนล้มเหลว การเชื่อมต่อหมดเวลาจากการรอนานหรือเมื่อพรอมต์เกิดขึ้นการรอคอยนานจะทำให้คุณป้อนรหัสผ่านประมาณสิบวินาทีก่อนที่จะปล่อยการเชื่อมต่อ ฉันไม่สามารถติดตามได้แม้จะมีคนแนะนำให้เพิ่มโฮสต์ดังกล่าวลงในไฟล์โฮสต์ ฉันเดาว่ามันเป็นเพียง "ความผิดพลาดกับการค้นหา DNS ของ OS X" และคาดว่าจะสามารถทนได้ ... ถ้ามีคนอื่นมีปัญหานี้และแก้ไขได้ฉันอยากรู้เกี่ยวกับมัน

ตรวจสอบบันทึกบนเซิร์ฟเวอร์ โดยปกติจะเป็น/var/log/auth.log(Debian / Ubuntu) หรือ/var/log/secure(RedHat / CentOS) ปัญหาใด ๆ กับการเชื่อมต่อมักจะถูกบันทึกไว้ที่นั่น

ตรวจสอบให้แน่ใจว่า / etc / ชื่อโฮสต์ถูกขึ้นบรรทัดใหม่