ปัญหา SSH แปลก ๆ ssh ทำงานกับ -t แต่ค้างโดยไม่มีมัน

เมื่อฉันsshเข้าสู่เซิร์ฟเวอร์ใดเซิร์ฟเวอร์หนึ่งของฉันดูเหมือนว่าจะเข้าสู่ระบบ แต่จากนั้นก็หยุดทำงานก่อนที่จะให้พรอมต์ ( message debug2: shell request accepted on channel 0 is the last log entry)

แม้ว่าสิ่งแปลกจะใช้ssh -t "/bin/bash"งานได้เมื่อsshไม่ได้

สิ่งที่ฉันได้ค้นพบจนถึงขณะนี้

• ฉันสามารถเข้าสู่ระบบได้ดีจากเซิร์ฟเวอร์ในตำแหน่งทางภูมิศาสตร์เดียวกันตามปกติ
• ถ้าฉันssh -t '/bin/bash'- ฉันสามารถเข้าสู่ระบบได้อย่างสมบูรณ์แบบจากที่ใดก็ได้
• ถ้าฉันใช้rsync กับเซิร์ฟเวอร์ดูเหมือนว่าจะทำงานแล้วล็อค
• ถ้าฉันใช้rsync จากเซิร์ฟเวอร์มันทำงานได้โดยไม่มีปัญหา

สิ่งที่ฉันได้ลอง

• การลบหรือแก้ไขตัวเลือกการเข้าสู่ระบบทั้งหมด.profile,.bashrc /etc/profile
• การเปลี่ยนssh_config และ / หรือ sshd_configหนึ่งจากเซิร์ฟเวอร์ที่เหมือนกันที่ทำงานได้ดี
• ฉันตรวจสอบเส้นทางแล้ว
• ฉันเคยมีผู้เชี่ยวชาญด้านเครือข่ายตรวจสอบtcpdumpว่าไม่มีประโยชน์ (แม้ว่าจะมีการส่งสัญญาณซ้ำหลายครั้ง)

ฉันไม่สามารถคิดอย่างอื่นได้อีก

นอกเหนือจากไดรเวอร์ / เฟิร์มแวร์การ์ดเครือข่ายซึ่งหลบ

ที่อาจมาจากปัญหาในโพรไฟล์
เมื่อคุณเชื่อมต่อกับssh -t /bin/bash เปลือกของคุณจะไม่ได้ 'เข้าสู่ระบบ' มันจะไม่แหล่ง/etc/profileหรือ~/.profileและ ~/.bashrc...

ดังนั้นหลังจากเชื่อมต่อให้วางเชลล์ในโหมดดีบั๊กจากนั้นให้ไฟล์แต่ละไฟล์เพื่อค้นหาสิ่งที่บล็อกอยู่ภายใน:

set -x 
. /etc/profile 
...and so on

แก้ไข

โปรดทราบว่าฉันผิดไฟล์. bashrc จะมีแหล่งที่มาจากเชลล์แบบโต้ตอบใด ๆ (ดังนั้นเฉพาะโปรไฟล์, ไฟล์ profile.d ที่มีความสำคัญที่นี่)

ลองทำรายการของขั้นตอนต่าง ๆ ของกระบวนการเชื่อมต่อ บางสิ่งเช่นนี้

1) การเชื่อมต่อ ssh (config, ... )
2) การเข้าสู่ระบบ (PAM, tty, wtmp, ... )
3) เริ่มต้นเชลล์ (โปรไฟล์, การเข้าถึง home dir, ... )

ในการตรวจสอบ (1) คุณสามารถเริ่ม sshd daemon ในโหมดแก้ไขข้อบกพร่อง เพื่อที่คุณจะต้องเริ่มต้น sshd อื่นให้ฟังพอร์ตเฉพาะ (ไม่ใช่ที่พอร์ต 22 ดังนั้นไม่จำเป็นต้องหยุด sshd daemon ปกติ)

# /usr/sbin/sshd -p 2222 -ddd 

sshd นั้นจะยอมรับการเชื่อมต่อเดียวเท่านั้นและจะไม่เข้าสู่พื้นหลัง เปิดเทอร์มินัลอื่นและเชื่อมต่อกับเซสชัน ssh นั้น

# ssh -vvv -p 2222 user@host

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

(-ddd และ -vvv เป็นระดับการดีบักสูงสุดที่คุณสามารถปรับได้)

ฉันได้รับลิงค์นั้นมีรายละเอียดมากขึ้น

คำตอบสำหรับปัญหาของฉัน ปรากฎว่าเป็นปัญหาเครือข่าย ในที่สุดฉันก็พบว่าโดยการลด MTU ของการ์ดเครือข่ายทั้งหมดลงเล็กน้อยปัญหาก็หายไป

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

โปรดทราบว่านี่เป็นทางเลือกสุดท้าย ความผิดปกติที่ฉันมีคือเซิร์ฟเวอร์ ssh ทำงานจากซับเน็ตเดียวกัน แต่ไม่ได้อยู่ข้างนอกและ ssh -t '/ bin / bash' ทำงานได้จากทุกที่

ฉันยังมี rsyncs ที่จะเริ่มต้นได้ดี แต่ในบางจุดเพียงแค่แขวนหรือลดลงการเชื่อมต่อ

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

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

ขอบคุณทุกคนที่ช่วย

เมื่อคุณทำssh some_user@some_host /bin/bashสิ่งที่คุณกำลังทำคือการเปิดตัวsome_userเปลือก 's (ตามที่กำหนดไว้ใน/etc/passwdบนsome_host ) แล้วรันคำสั่งที่กำหนด/bin/bashจากภายในเชลล์ที่

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

ในตัวอย่าง/bin/bashคำสั่งที่ร้องขอถูกเรียกใช้ แต่ดูเหมือนจะหยุด

คุณสามารถแก้ไขได้โดยขอsshให้สร้าง pty อยู่แล้วเพื่อให้มีหนึ่งที่พร้อมใช้งานสำหรับเชลล์และกระบวนการลูก นี่คือสิ่งที่-tไม่

    $ ssh -t some_user@some_host bash

คุณสามารถแก้ไขได้โดยการบังคับให้คำสั่งสร้าง pty สำหรับbashคุณทำได้โดยผ่านการ-iโต้แย้ง บรรทัดคำสั่งต่อไปนี้ควรทำงานเช่นกัน:

$ ssh some_user@some_host bash -i

โปรดทราบว่าในกรณีหลังนี้เชลล์ไม่สามารถเข้าถึง/dev/ttyและผลลัพธ์นี้จะเป็นการเตือน:

bash: no job control in this shell

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

(โปรดทราบว่าคุณสามารถส่งผ่านbashเป็นคำสั่งได้เนื่องจากควรอยู่บนเส้นทางของเชลล์เริ่มต้นของผู้ใช้อยู่ดี)

ฉันมีปัญหาเดียวกันเมื่อฉันใช้แพลตฟอร์มการจำลองเสมือนที่ซ้อนกันเมื่อเร็ว ๆ นี้

ทำงานหลังจากลด MTU จาก 1500 เป็น 1400 บนเซิร์ฟเวอร์ต้นทางหรือเซิร์ฟเวอร์ปลายทาง

/sbin/ip link set dev eth0 mtu 1400