รอเวลานานในการเข้าสู่ระบบ

เมื่อฉันลงชื่อเข้าใช้บนเซิร์ฟเวอร์ฉันจะได้รับสิ่งนี้:

No mail.
Last login: Fri Nov  5 14:22:45 2010...

ถ้าอย่างนั้นฉันต้องรอ 5 วินาทีแล้วก็พร้อม ...

wolfy@ubuntu-server:~$

เวลารอนี้ปกติหรือฉันควรทำ "ซ่อมแซม" สิ่งนี้หรือไม่

ซึ่งมักเป็นผลมาจากpam_motdการสร้าง/etc/motdไฟล์ใหม่ คุณสามารถตรวจสอบสคริปต์แต่ละตัว/etc/update-motd.dเพื่อดูว่ามีบางสิ่งที่ช้าเป็นพิเศษหรือไม่

ฉันมีปัญหาเดียวกันกับ 10.04 (LTS)

เมื่อฉันใช้ ssh ของฉัน-vvvมันจะตายที่:

debug1: Entering interactive session.

ขยายคำตอบนี้

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

บนเซิร์ฟเวอร์รายการกระบวนการแสดงสิ่งนี้:

root       835  0.0  0.1  11476  3348 ?        Ss   13:39   0:00 sshd: till [priv]
root       840  0.0  0.0   4804  1124 ?        S    13:39   0:00 /bin/sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/run-parts --lsbsysinit /etc/update-motd.d
root       841  0.0  0.0   4728  1108 ?        S    13:39   0:00 /bin/run-parts --lsbsysinit /etc/update-motd.d
root       854  0.0  0.0   4804  1144 ?        S    13:39   0:00 /bin/sh /etc/update-motd.d/50-landscape-sysinfo
root       861  0.2  0.5  15388  9248 ?        S    13:39   0:00 /usr/bin/python /usr/bin/landscape-sysinfo
root       863  0.0  0.0      0     0 ?        Z    13:39   0:00 [who] <defunct>

ฉันสามารถดำเนินการได้/usr/bin/python /usr/bin/landscape-sysinfoดีในขณะที่ฉันเข้าสู่ระบบ แต่ด้วยเหตุผลบางอย่างฉันไม่สามารถหาสาเหตุที่ทำให้กระบวนการเข้าสู่ระบบล่าช้า เมื่อฉันฆ่ากระบวนการเข้าสู่ระบบอย่างต่อเนื่องไปอย่างรวดเร็วและเป็นที่ประสบความสำเร็จ

ดูเหมือนจะไม่เป็นปัญหา ssh (d) แต่เกี่ยวข้องกับupdate-motdและแนวนอนมากกว่า ฉันถอนการติดตั้งupdate-motdแพคเกจ แต่ดูเหมือนว่า/etc/update-motdไดเรกทอรียังคงอยู่และสคริปต์ยังคงดำเนินการ - ทำให้กระบวนการหยุดทำงาน

แก้ไขข้อบกพร่องนี้เพิ่มเติม:

ปรากฎว่า/etc/update-motd.d/ไดเรกทอรีไม่ได้เป็นของแพ็คเกจupdate-motdดูเหมือนว่าจะถูกทริกเกอร์โดยการพิสูจน์ตัวตนของ pam ผ่าน sshd

ฉันดูเหมือนจะถูกจับ!

ปิดการใช้งาน pam_motd ในไฟล์ต่อไปนี้:

• /etc/pam.d/sshd
• /etc/pam.d/login

อีกหนึ่ง:

apt-get purge landscape-client landscape-common

สิ่งเหล่านี้ดูเหมือนจะช่วยยืดระยะเวลาออกไป แม้ว่าจะลบสคริปต์ที่ละเมิดออกเท่านั้น/etc/update-motd.d/และไม่ลบสคริปต์ทั้งหมดในไดเรกทอรีนั้นและจะไม่ลบออกpam_motdเช่นกัน

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

รายงานข้อผิดพลาดเกี่ยวกับปัญหานี้:

• https://bugs.launchpad.net/ubuntu/+source/pam/+bug/805423

วิธีแก้ปัญหาจากตรงนั้น:

คุณถูกที่ความสามารถในการเข้าสู่ระบบมีความสำคัญมากกว่าการนำเสนอ motd หากพฤติกรรมนี้เป็นปัญหาสำหรับคุณมีหลายวิธีที่คุณสามารถปิดใช้งานได้:

• แสดงความคิดเห็นในบรรทัด 'pam_motd' /etc/pam.d/sshdหากคุณไม่ต้องการแสดง motd
• ลบเนื้อหาของ/etc/update-motd.dไดเรกทอรี
• chmod -x สคริปต์/etc/update-motd.dที่คุณไม่ต้องการเรียกใช้

พบทางออกด้วยตนเองในที่สุด:

1. sudo apt-get remove landscape-client landscape-common
2. บรรทัดความคิดเห็น session optional pam_motd.so ใน/etc/pam.d/loginและ/etc/pam.d/sshd

ตอนนี้เข้าสู่ระบบทันที!

จากคำอธิบายของคุณฟังดูเหมือนปัญหาเครือข่าย ในการวินิจฉัย:

• รัน ssh ด้วยพารามิเตอร์ -v เพื่อให้เป็น verbose
• ลองเรียกใช้ ping ไปยังเซิร์ฟเวอร์ SSH ที่คุณกำลังเชื่อมต่อและดูว่าสิ่งนี้แฮงค์ในเวลาเดียวกันหรือไม่
• ลองถ่ายโอนประเภทอื่นไปยังเซิร์ฟเวอร์เดียวกัน ตัวอย่างเช่น wget ด้วยพารามิเตอร์ --limit-rate เพื่อดึงไฟล์ผ่าน HTTP และใช้เวลานานพอที่อาจทริกเกอร์พฤติกรรม "หยุด"
• ดูว่ามันแฮงค์เฉพาะเมื่อไม่ได้ใช้งานหรือแม้ว่าคุณจะทำอะไรบางอย่างในขณะนี้ หากแฮงค์ขณะที่ไม่ได้ใช้งานการวินิจฉัย -v อาจจะบอกคุณในกรณีนี้คำแนะนำในการใช้ keepalive อาจช่วยได้ (ssh -o "TCPKeepAlive ใช่")

หากคุณสามารถเชื่อมต่อตกลงกับ Windows และ PuTTY อาจเป็นปัญหาที่ด้านเซิร์ฟเวอร์

ถ้าPermitEmptyPasswordและUsePAMเปิดใช้งานทั้งคู่แล้วเซิร์ฟเวอร์ OpenSSH จะพยายามรับรองความถูกต้องด้วยรหัสผ่าน null ซึ่งจะเป็นสัญญาณว่าไม่จำเป็นต้องมีการตรวจสอบสิทธิ์สำหรับบัญชีที่สงสัย มันทำสิ่งนี้ทันทีที่กระบวนการพิสูจน์ตัวตนเริ่มต้นขึ้นในทั้งสองโปรโตคอลและไม่ตอบสนองคำขอการรับรองความถูกต้อง "ของจริง" ใด ๆ จากไคลเอ็นต์ OpenSSH จะอนุญาตเฉพาะการเข้าถึงดังกล่าวหากPermitEmptyPasswordตั้งค่าสถานะ sshd_config แต่น่าเสียดายที่วิธีการเขียนโค้ดนั้นจะทำการทดสอบรหัสผ่านในทุกกรณีและแสดงให้เห็นถึง PAM ว่าเป็นความล้มเหลว

ดังนั้น: ปิดการใช้งานPermitEmptyPasswordหรือUsePAMแต่จำไว้ว่า: หากไม่มี PAM คุณจะไม่สามารถเข้าสู่ระบบได้หากไม่มีรหัส

การอ้างอิง: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG-c

ฉันคิดว่าเมื่อคุณเข้าสู่ระบบ Ubuntu จะเรียกใช้ไฟล์เหล่านี้อย่างน้อยหนึ่งไฟล์:

/etc/bash.bashrc
~/.bash_profile
~/.bashrc

คุณสามารถเห็นสิ่งที่อยู่ในพวกเขาและอาจลองดำเนินการเพื่อดูสิ่งที่ใช้เวลานาน

จากประสบการณ์ที่ จำกัด ของฉันเมื่อ putty ใช้งานได้ แต่ Linux, Ubuntu ในกรณีนี้ไม่ได้เป็นปกติ ปัญหาเครือข่ายหรือเซิร์ฟเวอร์จะส่งผลกระทบต่อทั้งระบบปฏิบัติการไคลเอ็นต์

คุณสามารถใช้ตัวเลือก Keep keep alive ด้านบนในบรรทัดคำสั่ง แต่มันน่าเบื่อที่จะพิมพ์

แก้ไขไฟล์กำหนดค่าได้ง่ายขึ้น

หากคุณมีroot accessและต้องการเปิดใช้งานโดยอัตโนมัติสำหรับผู้ใช้ทั้งหมดให้แก้ไข/etc/ssh/ssh_configเพิ่ม

KeepAlive yes
ServerAliveInterval 120

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

ตรวจสอบบันทึกระบบของคุณที่ / var / log คุณอาจพบข้อความที่มีข้อผิดพลาด / หมดเวลาที่เกี่ยวข้อง

หากคุณมีเวลารอก่อน

แก้ไข /etc/sshd_config

และตั้งค่า (หรือเพิ่ม)

UseDNS no

หรือเพิ่ม ip ของคุณ/etc/hostsถ้ามันคงที่ท้องถิ่น

คุณอาจต้องการลองตรวจสอบกระบวนการทำงานในขณะที่คุณกำลังเข้าสู่เซิร์ฟเวอร์จากการเชื่อมต่อเข้าสู่ระบบแล้ว (หรือคอนโซลอื่น) มีโอกาสที่จะตรวจสอบว่ากระบวนการใดมีการใช้งานมากที่สุดหรือใช้ CPU มากที่สุดในเวลานั้น

ด้านล่างเป็นวิธีหนึ่งที่เป็นไปได้:

1. ลองเข้าสู่ระบบในคอนโซลอื่น
2. วิ่งtopไปที่นั่นเพื่อดูว่าเกิดอะไรขึ้น
3. เข้าสู่ระบบบนคอนโซลที่ 1

โปรดทราบว่าหากการหน่วงเวลาไม่ได้เกิดจากการคำนวณที่ใช้ CPU มากคุณจะไม่พบสิ่งผิดปกติ กรณีนี้ปัญหาอาจถูกผูกไว้กับ I / O (กำลังรอการอ่าน / เขียนหรือการตอบสนองของเครือข่ายดิสก์)