การเชื่อมต่อ ssh แรกใช้เวลาหลายนาที

ฉันทำงานบน Ubuntu 17.04, เคอร์เนลopenssh-client==7.4p1-104.10.0-33-generic

ฉันมีปัญหากับการดำเนินการคำสั่ง ssh เช่น:

rsync -t -e ssh -p 22 script.sh root@remote.server:/var/lib/script.sh
\_ ssh -p 22 -l root root@remote.server rsync --server -te.LsfxC . /var/lib/script.sh

ใช้เวลาrsync6 นาทีในการซิงค์สคริปต์นั้นซึ่งมี 4kB ปัญหาไม่ได้อยู่เพียงกับrsyncยังgit pushผ่าน SSH บางครั้งได้รับการดูด

สิ่งที่ตลกคือหลังจากขัดจังหวะกระบวนการและดำเนินการอีกครั้งมันจะทำงานทันที:

^Crsync error: unexplained error (code 130) at rsync.c(638) [sender=3.1.2]
rsync: [sender] write error: Broken pipe (32)

ดูเหมือนจะไม่ใช่ปัญหา DNS นี่คือ/etc/resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4
options single-request-reopen
options attempts:2
options rotate
options timeout:2

ฉันปิดใช้งาน GSSAPI แล้ว:

/etc/ssh/ssh_config:

   GSSAPIAuthentication no
   GSSAPIDelegateCredentials no

ฉันได้ลองบังคับใช้การเชื่อมต่อ IPv4 ด้วย-4เช่นกันโดยไม่ประสบความสำเร็จใด ๆ มีความคิดอะไรที่อาจจะผิดหรือเปล่า?

นี่คือกระบวนการทั้งหมด:

strace: Process 7610 attached
select(8, [3 5], [], NULL, NULL)        = 1 (in [3])
clock_gettime(CLOCK_BOOTTIME, {42870, 893598449}) = 0
read(3, "\372oyu\331J\20\327\264\325\357\274\vn\233\nG\207\207c\251\230\341NzUk\261\351v\23\353"..., 8192) = 44
clock_gettime(CLOCK_BOOTTIME, {42870, 894108136}) = 0
clock_gettime(CLOCK_BOOTTIME, {42870, 894258960}) = 0
select(8, [3 5], [6], NULL, NULL)       = 1 (out [6])
clock_gettime(CLOCK_BOOTTIME, {42870, 894325845}) = 0
write(6, "\3\0\0\7\0\0\0", 7)           = 7
clock_gettime(CLOCK_BOOTTIME, {42870, 894439661}) = 0
clock_gettime(CLOCK_BOOTTIME, {42870, 894473071}) = 0
select(8, [3 5], [], NULL, NULL)        = 1 (in [5])
clock_gettime(CLOCK_BOOTTIME, {42870, 894558087}) = 0
read(5, "\2\0\0\7\0\0\1\0\0\7\0", 16384) = 11
clock_gettime(CLOCK_BOOTTIME, {42870, 894661575}) = 0
clock_gettime(CLOCK_BOOTTIME, {42870, 894699595}) = 0
select(8, [3 5], [3], NULL, NULL)       = 1 (out [3])
clock_gettime(CLOCK_BOOTTIME, {42870, 894780961}) = 0
write(3, "\f\16\6UF|B\1\315\nYP\355\f|\177|\234v\371\322\236*)\32`\3214\225$u\337"..., 52) = 52
clock_gettime(CLOCK_BOOTTIME, {42870, 894852781}) = 0
clock_gettime(CLOCK_BOOTTIME, {42870, 894874370}) = 0
select(8, [3 5], [], NULL, NULL)        = 1 (in [3])
clock_gettime(CLOCK_BOOTTIME, {42870, 923152465}) = 0
read(3, "\310\3258\332\212)\re\262\322^\f\275\324X{\361\23f\211mk'\213\224\v\0\204\322\n\25\221"..., 8192) = 44
clock_gettime(CLOCK_BOOTTIME, {42870, 923618233}) = 0
clock_gettime(CLOCK_BOOTTIME, {42870, 923845130}) = 0
select(8, [3 5], [6], NULL, NULL)       = 1 (out [6])
clock_gettime(CLOCK_BOOTTIME, {42870, 923946992}) = 0
write(6, "\1\0\0\7\0", 5)               = 5
clock_gettime(CLOCK_BOOTTIME, {42870, 924002335}) = 0
clock_gettime(CLOCK_BOOTTIME, {42870, 924027449}) = 0
select(8, [3 5], [], NULL, NULL)        = 1 (in [3])
clock_gettime(CLOCK_BOOTTIME, {42870, 943180384}) = 0
read(3, "\326U\32\20\246\374\201K\246\177!z\265\302^\252\371\255\215\355\265\356\313\322W\2341`%\215\20P"..., 8192) = 176
close(6)                                = 0
close(5)                                = 0
clock_gettime(CLOCK_BOOTTIME, {42870, 943307191}) = 0
clock_gettime(CLOCK_BOOTTIME, {42870, 943334146}) = 0
close(7)                                = 0
select(8, [3], [3], NULL, NULL)         = 1 (out [3])
clock_gettime(CLOCK_BOOTTIME, {42870, 943414987}) = 0
write(3, "0\236\27\233p\303\324\302\222mD\242Y_\34S\365\366p\214z\320\367.sN\252\337\322S\202("..., 36) = 36
rt_sigaction(SIGWINCH, NULL, {0x5639600b7460, [], SA_RESTORER, 0x7f7046de37f0}, 8) = 0
rt_sigaction(SIGWINCH, {SIG_DFL, [], SA_RESTORER, 0x7f7046de37f0}, NULL, 8) = 0
write(3, "F\226\207\7\243\207\33\316\37\1U$\326Y\314\253\310p\210\354\240\247\322n\32\272A\312\312:\252\324"..., 60) = 60
ioctl(0, TCGETS, 0x7ffc20de6720)        = -1 ENOTTY (Inappropriate ioctl for device)
fcntl(0, F_GETFL)                       = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(0, F_SETFL, O_RDWR)               = 0
ioctl(1, TCGETS, 0x7ffc20de6720)        = -1 ENOTTY (Inappropriate ioctl for device)
fcntl(1, F_GETFL)                       = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl(1, F_SETFL, O_RDWR)               = 0
ioctl(2, TCGETS, {B38400 opost isig icanon echo ...}) = 0
shutdown(3, SHUT_RDWR)                  = 0
close(3)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

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

$ netstat -s | egrep -i 'loss|retran'
    421 segments retransmitted
    TCPLostRetransmit: 6
    1 timeouts in loss state
    47 fast retransmits
    137 retransmits in slow start
    TCPLossProbes: 7
    TCPRetransFail: 3
    TCPSynRetrans: 12

แก้ไข :

ฉันพยายามแล้วโดยไม่สำเร็จ:

• เปลี่ยนสายเคเบิลเครือข่าย (ไปยังเราเตอร์โดยตรง)
• แทนที่ NIC card (บนบอร์ด Broadcom ด้วย Realtek gigabit card)

คุณสามารถรับข้อมูลการดีบักได้มากขึ้นโดยพยายามง่าย ๆssh -vvvไปยังเซิร์ฟเวอร์และดูข้อความที่มาจากกระบวนการไคลเอนต์

ลอง telnet ไปยังพอร์ต ssh (22 โดยค่าเริ่มต้น) และดูว่ามันจะตอบสนองเร็วแค่ไหน

ตามที่คนอื่น ๆ แนะนำว่าอาจเป็นปัญหาไฟร์วอลล์ (ดูเหมือนจะ จำกัด การเชื่อมต่อขาเข้า) อย่างไรก็ตามเนื่องจากคุณได้ปิดการใช้งานและไม่ได้ช่วยอะไรมาก

ตัวเลือกอื่นคือข้อมูลผู้ใช้ / กลุ่มที่มีการเชื่อมต่ออยู่พักหนึ่งเช่นเมื่อเชื่อมต่อกับเครื่องที่ใช้เซิร์ฟเวอร์ LDAP ระยะไกลและไม่ว่างหรือมีปัญหาในการเข้าถึง LDAP (ซึ่งจำเป็นต้องแก้ไข uid / gid ของคุณ) จะชะลอการเชื่อมต่อ (ถ้าเป็นไปได้ลองลงชื่อเข้าใช้บัญชีรูทด้วยคีย์ ssh เพราะไม่ควรใช้เซิร์ฟเวอร์ภายนอก)

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

สำหรับการเชื่อมต่อที่ตามมาครั้งแรกและเร็วกว่ามากมันอาจบ่งบอกถึงปัญหาที่เกิดขึ้นในกลไกการแคชบางชนิด (DNS, LDAP, netfilter RELATED, ESTABLISHED state) หรือเพียงแค่ว่าไคลเอ็นต์ ssh ของคุณใช้กระเป๋าควบคุม เปิดหลังจากการเชื่อมต่อเริ่มต้น)

หลังจากความพยายามไม่สำเร็จไม่กี่ครั้งฉันได้ปรับพารามิเตอร์ที่เกี่ยวข้องกับเครือข่าย/etc/sysctl.confด้วยค่าต่อไปนี้ :

net.core.netdev_max_backlog = 5000
# allow testing with buffers up to 64MB
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
# increase Linux autotuning TCP buffer limit to 32MB
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
# recommended default congestion control is htcp
net.ipv4.tcp_congestion_control=htcp
# recommended for hosts with jumbo frames enabled
net.ipv4.tcp_mtu_probing=1
net.core.default_qdisc = fq

การเพิ่มบัฟเฟอร์ TCP เพียงอย่างเดียวก็ไม่ได้ช่วยอะไร ขณะนี้เครือข่ายทำงานตามที่คาดไว้