การเชื่อมต่อ ssh ใช้เวลาตลอดไปในการเริ่มต้นติดอยู่ที่“ การจำนำ: เครือข่าย”

43

การเชื่อมต่อกับหนึ่งในเซิร์ฟเวอร์ของฉันโดยใช้ ssh ใช้เวลามากกว่า 20 วินาทีในการเริ่มต้น

นี้ไม่เกี่ยวข้องกับเงื่อนไข LAN หรือ WAN เนื่องจากการเชื่อมต่อกับตัวเองใช้เวลาเดียวกัน (ssh localhost) ในที่สุดหลังจากการเชื่อมต่อถูกจัดตั้งขึ้นในที่สุดมันก็เร็วสุดที่จะเข้าไปแทรกแซงกับเซิร์ฟเวอร์

ใช้ -vvv แสดงว่าการเชื่อมต่อค้างหลังจากพูดว่า "pledge: network" ณ จุดนี้การรับรองความถูกต้อง (ที่นี่ใช้รหัส) เสร็จเรียบร้อยแล้วตามที่ปรากฏที่นี่:

...
debug1: Authentication succeeded (publickey).
Authenticated to myserver.mydomain.com ([xx.xx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network

(... ติดอยู่ที่นี่เป็นเวลา 15 ถึง 25 วินาที ... )

debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...

เซิร์ฟเวอร์คือ Ubuntu 16.04 มันเคยเกิดขึ้นกับฉันในอดีตกับเซิร์ฟเวอร์อื่น (เป็น Ubuntu 12.04), nerver พบวิธีแก้ปัญหาและปัญหาหายไปหลังจากที่ในขณะ ...

sshd_config เป็นโปรแกรมเริ่มต้นที่จัดทำโดย Ubuntu

จนถึงตอนนี้ฉันได้ลอง:

ใช้ -o GSSAPIAuthentication = no ในคำสั่ง ssh
ใช้รหัสผ่านแทนรหัส
ใช้ UsePrivilegeSeparation no แทนใช่ใน sshd_config

ssh

— M-แจ็ค
แหล่งที่มา

1

โดยทั่วไปแล้วสำหรับฉันการเชื่อมต่อ SSH ที่ช้านั้นเป็นปัญหา DNS นี่อาจเป็นกรณีหรือไม่ ยกตัวอย่างเช่นเซิร์ฟเวอร์อาจจะติดอยู่พยายามที่จะทำ DNS ย้อนกลับสำหรับ IP ของลูกค้าและการรอคอยเพื่อที่จะหมดเวลา

— เอริค Renouf

ไม่จริง: โดยค่าเริ่มต้น UseDNS ไม่ได้กำหนดไว้ใน sshd_config และหน้าคนบอกว่าตัวเลือกนี้คือ "ไม่" โดยค่าเริ่มต้น

— M-Jack

3

Googling บางคนแนะนำว่าสิ่งนี้อาจเกิดจากการอัพเดต systemd โดยไม่ต้องบูตเครื่องใหม่ และมีการปรับปรุง systemd สำหรับ xenial 12 systemctl restart systemd-logindแก้ไขปัญหาเฉพาะช่วงเวลาสั้น ๆ สำหรับฉัน

— Ivan Kozik

หรือหากคุณเห็นpam_systemd(sshd:session): Failed to create session: Connection timed outดังที่ได้กล่าวไว้ในคำตอบอาจเป็นgithub.com/systemd/systemd/issues/2925

— Ivan Kozik

ฉันมาที่นี่เพื่อรับปัญหานี้หลังจากการอัปเดตและข้อเสนอแนะของ @ IvanKozik แก้ไขปัญหา - เช่น systemctl รีสตาร์ท systemd-logind - ขอบคุณมากสำหรับสิ่งนั้น

— พอล M

43

นี่อาจจะเป็นปัญหากับและD-Bus systemdหากdbusบริการเริ่มต้นใหม่ด้วยเหตุผลบางอย่างคุณจะต้องเริ่มต้นใหม่systemd-logindด้วย

คุณสามารถตรวจสอบว่านี่เป็นปัญหาหรือไม่โดยการเปิดบันทึก ssh daemon (บน Ubuntu ควรเป็น/var/log/auth.log) และตรวจสอบว่ามีบรรทัดเหล่านี้หรือไม่:

sshd[2721]: pam_systemd(sshd:session): Failed to create session: Connection timed out

ถ้าใช่เพียงแค่เริ่มsystemd-logindบริการ:

systemctl restart systemd-logind

ฉันมีปัญหาเดียวกันนี้ใน CentOS 7 เพราะmessagebusเริ่มต้นใหม่ (ซึ่งเป็นวิธีที่D-Busเรียกใช้บริการบน CentOS)

— Strahinja Kustudic
แหล่งที่มา

ฉันพยายามรีสตาร์ท systemd-logind แต่หลังจากนั้นไม่นานมันบอกว่า PolicyKit daemon ถูกตัดการเชื่อมต่อจากบัส เราไม่ได้เป็นตัวแทนการรับรองความถูกต้องที่ลงทะเบียนแล้ว งานสำหรับ systemd-logind.service ล้มเหลวเนื่องจากเกินระยะหมดเวลา ดูที่ "systemctl status systemd-logind.service" และ "journalctl -xe" สำหรับรายละเอียด

— Kun Ren

@KunRen คุณอาจต้องเริ่มต้นใช้บริการpolkit systemctl restart polkit

— Strahinja Kustudic

16

พบคำตอบ:

เปลี่ยน UsePAM จาก yes เป็น no ในไฟล์ sshd_config

หลังจากรีสตาร์ทเซอร์วิส ssh ตอนนี้การเชื่อมต่อกับเซิร์ฟเวอร์ทันที บนเซิร์ฟเวอร์นี้ PAM เชื่อมโยงกับ ldap ดังนั้นอาจเป็นเหตุผลถึงแม้ว่าที่นี่ฉันกำลังเชื่อมต่อกับผู้ใช้ที่ประกาศบนเซิร์ฟเวอร์เองไม่ใช่ LDAP

นี่เป็นวิธีหลีกเลี่ยงปัญหาไม่ใช่วิธีแก้ปัญหา ... ฉันมีเซิร์ฟเวอร์อื่นตั้งค่าแบบเดียวกับที่ไม่มีปัญหานี้

หวังว่านี่จะช่วยใครซักคน ...

— M-แจ็ค
แหล่งที่มา

1

การเปลี่ยน UsePAM เป็นไม่มีผลกระทบอื่น ๆ ดูการสนทนานี้ ดังนั้นฉันต้องตั้งรหัสผ่านให้กับผู้ใช้เพราะฉันได้รับข้อผิดพลาดเช่น User nagios ไม่ได้รับอนุญาตเนื่องจากบัญชีถูกล็อค

— M-Jack

4

นี่ไม่ใช่ความคิดที่ดีจริงๆ

— Jakuje

1

ทำไม ทางเลือกใด ๆ

— M-Jack

8

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

— Jakuje

การปล่อยให้โมดูล PAM ที่ไม่ได้ใช้งานบ่อยเปิดใช้งานเพื่อเข้าถึง SSH เป็นช่องโหว่ความปลอดภัย การ จำกัด การเข้าถึงบริการที่สำคัญเช่น SSH จากจุดยืนด้านความปลอดภัยเป็นความคิดที่ดีสำหรับบริการอื่น ๆ เช่นกัน เมื่อใดที่คุณต้องการให้โมดูล PAM ร่วมมือกับ SSH ตัวอย่างเช่น: เมื่อคุณต้องการรวมกับไดเรกทอรีที่ใช้งานผ่าน winbind เมื่อคุณต้องการสองปัจจัยการตรวจสอบกับโทเค็นของ Google ฯลฯ ในกรณีอื่น ๆ (เมื่อใช้ passwd และเงา) การปิดมันมีความปลอดภัยอย่างสมบูรณ์ ผู้ใช้ PAM ทุกคนจะเห็นสิ่งนี้: cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pam

— Michal Sokolowski

10

สิ่งนี้เกิดขึ้นในเซิร์ฟเวอร์ Fedora 25 สองตัวของฉันและเกิดจากการพยายามล็อกอิน SSH ล้มเหลวมากมาย

(คำแนะนำทั่วไปของการใช้GSSAPIAuthentication=noและUseDNS=noหรือรีสตาร์ทsystemd-logindไม่ทำให้เกิดความแตกต่าง)

บนเซิร์ฟเวอร์เหล่านี้/etc/pam.d/postloginประกอบด้วย:

session     optional      pam_lastlog.so silent noupdate showfailed

หน้าคนสำหรับpam_lastlogอธิบายว่าshowfailedตัวเลือกจะ:

แสดงจำนวนครั้งที่พยายามเข้าสู่ระบบล้มเหลวและวันที่พยายามครั้งสุดท้ายล้มเหลวจาก btmp

บนเซิร์ฟเวอร์เหล่านี้/var/log/btmpไฟล์มีขนาดใหญ่มากเนื่องจากการพยายามเข้าสู่ระบบล้มเหลวหลายครั้ง btmpล็อกไฟล์ไม่ถูกหมุนอย่างใดอย่างหนึ่ง

ฉันติดตั้งlogrotateแพคเกจเพื่อให้แน่ใจว่าไฟล์บันทึกจะถูกหมุนในอนาคต (บน Fedora การกำหนดค่าที่มาพร้อมกับlogrotateจัดการการหมุนของ/var/log/btmp)

ฉันยังลบbtmpไฟล์บันทึกขนาดใหญ่ ทันทีที่ฉันทำสิ่งนี้การเชื่อมต่อกับเซิร์ฟเวอร์ก็เกิดขึ้นทันที

— Richard Fearn
แหล่งที่มา

นี่เป็นการแก้ไขปัญหาของฉัน! ขอขอบคุณ. รับได้สวย. SSH ใช้เวลา 5-10 วินาทีและตอนนี้มันก็น้อยกว่าพริบตา นี่เป็น VM ที่ฉันเชื่อมต่อกับอินเทอร์เน็ตสาธารณะมาหลายปีแล้ว กฎไฟร์วอลล์อาจปรับได้ดีขึ้นเล็กน้อยตอนนี้ฉันคิดว่ามัน สำหรับผู้อื่นนี่คือทั้งหมดที่ฉันทำ: sudo truncate -s 0 /var/log/btmp- Mine มีขนาด 2.7G

— Carl Bennett

2

ในกรณีของฉันเหตุผลเป็น rsyslogd ที่ล้มเหลว ฉันพบสิ่งนี้เพราะไม่มีข้อความบันทึกเพิ่มเติมเช่น / var / log / syslog หรือ /var/log/mail.log

ดังนั้นservice rsyslog restartการแก้ไขปัญหาสำหรับเรา

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

สาเหตุเดียวกันบนเซิร์ฟเวอร์ของเราที่ใช้ CentOS 6.10 รีสตาร์ท rsyslog ดูแลมัน สิ่งนั้นคือมันไม่ได้ตาย มันกำลังทำงานอยู่ แต่เห็นได้ชัดว่าไม่มีประโยชน์อะไรเลย

— UtahJarhead

1

สำหรับผมเรื่องนี้มีสาเหตุมาจาก (หลายร้อยเมกะไบต์) ขนาดใหญ่btmpไฟล์ ไฟล์นี้บันทึกการพยายามลงชื่อเข้าใช้ เมื่อมีคนพยายามที่จะดุร้ายบังคับรหัสผ่านของคุณไฟล์นี้อาจมีขนาดใหญ่และทำให้เกิดความล่าช้าใน"pledge: network"ขั้นตอน

ลองล้างไฟล์บันทึก

echo "" > /var/log/btmp

และดูว่ามันช่วยได้ไหม

— Marek Nagy
แหล่งที่มา

3

สิ่งนี้ต้องการคำอธิบายที่มากขึ้น สำหรับผู้เริ่มต้นทำไมคุณคิดว่าสิ่งนี้มีประโยชน์

— สเวน

เคล็ดลับ: เพียงแค่พิมพ์:> /var/log/btmpbtw เดียวกันเท่านั้น

— Marius

1

สำหรับฉันทางออกคือการเพิ่ม

UseDNS no

ไปที่/etc/ssh/sshd_configแล้วแน่นอนservice ssh restart(บนเซิร์ฟเวอร์ Debian / Jessie ของเรา) ไม่มีอะไรอีกแล้ว...

ก่อน :

ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 13.440 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 20.990 total
ssh git@git.*****.de true  0.03s user 0.02s system 0% cpu 31.114 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 25.898 total

หลัง :

ssh git@git.*****.de true  0.03s user 0.02s system 5% cpu 0.832 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.523 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.574 total

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

ไม่การเพิ่มUseDNS noเป็นวิธีแก้ปัญหาที่แตกต่างอย่างสิ้นเชิง

— kasperd

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

— tamasgal

เดียวกันที่นี่สองแฮงค์ระหว่างการเชื่อมต่อหนึ่งหลังจากที่หนึ่งอีกต่อไปหลังจากsign_and_send_pubkey pledge: networkการเพิ่มเฉพาะในUseDNS noภายหลังservice ssh restartนั้นสามารถแก้ไขปัญหาในการติดตั้ง Ubuntu 14.04.5 LTS เก่าได้ที่นี่

— Hound

0

ฉันสังเกตเห็นบรรทัดต่อไปนี้ในข้อเสนอแนะการดีบักของฉัน:

Control socket connect(/var/lib/jenkins/.ssh/USER@HOST:22): Permission denied

ซึ่งเป็นแฟ้มที่ถูกเจ้าของโดยในขณะที่ฉันroot:root jenkinsการลบไฟล์นี้แก้ไขปัญหาของฉันได้

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