1

Я работаю на Ubuntu 17.04, openssh-client==7.4p1-10 , ядро 4.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

rsync занимает 6 минут для синхронизации этого сценария, который имеет 4 КБ. Проблема не только в rsync и git push over 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

РЕДАКТИРОВАТЬ:

Я уже пытался без какого-либо успеха:

  • замена сетевого кабеля (идет напрямую к роутеру)
  • замена сетевой карты (на борту Broadcom гигабитной картой Realtek)
|источник

2 ответа2

1

Вы можете получить больше отладочной информации, попробовав простой ssh -vvv на сервере и увидев сообщения, поступающие от клиентского процесса.

Также попробуйте подключиться к порту ssh (по умолчанию 22) и посмотреть, как быстро он ответит.

Как и предполагали другие, это может быть проблема с брандмауэром (кажется, что ограничения для входящих подключений), однако, поскольку вы отключили его, и это не сильно помогло, на этот раз это может быть не так.

Другой вариант - это информация о пользователе / группе, которая хранит соединение в течение достаточно долгого времени, например, при подключении к компьютеру, который использует удаленный сервер LDAP, и он занят или испытывает проблемы с достижением LDAP (что необходимо для разрешения вашего uid / gid). также задержит соединение. (если возможно попробуйте войти в учетную запись root с помощью ключа ssh, так как он не должен использовать внешние серверы)

Еще одна вещь, которую нужно проверить, - это DNS-сервер на удаленном конце, ssh-сервер может попытаться преобразовать ваш IP-адрес в DNS-хост, и, если его DNS-сервер ненадежен, это также может занять некоторое время.

Что касается подключений, следующих за первым и намного более быстрых, то это также может указывать на проблему в каком-то механизме кэширования (DNS, LDAP, состояние RELATED netfilter, состояние ESTABLISHED) или просто на то, что ваш ssh-клиент использует controlsockets (и он сохраняет их открыть после первоначального подключения)

|источник
0

После нескольких неудачных попыток я настроил параметры, связанные с сетью, /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-буферов не помогло. Сейчас сеть ведет себя как положено.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .