☰

Невозможно завершить SSH-подключение после успешного обмена ключами с Ubuntu из некоторых сетей

tag-icon • tag-icon ssh
Невозможно завершить SSH-подключение после успешного обмена ключами с Ubuntu из некоторых сетей

После перелета из одной страны в другую я теперь не могу подключиться по ssh к нескольким своим серверам Digital Ocean Ubuntu. Однако я все еще могу войти через консоль и ssh с одного ящика на другой (они все находятся в одном физическом центре обработки данных).

При запуске ssh с параметром -vvvv и выполнении команды time с ним последнее отладочное сообщение будет следующим:

debug2: channel 0: open confirm rwindow 0 rmax 32768
Write failed: Broken pipe

Время ожидания истекает через 1 минуту 37 секунд.

Вот журнал отладки с момента успешной аутентификации по ключу SSH:

debug1: Authentication succeeded (publickey).
Authenticated to 128.199.170.168 ([128.199.170.168]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env TMPDIR
debug3: Ignored env Apple_PubSub_Socket_Render
debug3: Ignored env TERM_PROGRAM_VERSION
debug3: Ignored env TERM_SESSION_ID
debug3: Ignored env USER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug3: Ignored env PATH
debug3: Ignored env MARKPATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env XPC_FLAGS
debug3: Ignored env PS1
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env GREP_OPTIONS
debug3: Ignored env LOGNAME
debug3: Ignored env SCALA_HOME
debug3: Ignored env SECURITYSESSIONID
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
Write failed: Broken pipe

Соединение не особенно медленное, моя оболочка — bash (и я все еще могу войти через консоль и другие сетевые ssh). Похоже, ничто не блокирует соединение ssh, поскольку я вижу, что происходит аутентификация с открытым ключом.

Я не знаю, какой канал записи сломан. Кстати, я подключаюсь из OSX, но у меня не было проблем до полета в США.

Вот что auth.logотображается при попытке входа в систему:

May 17 12:28:01 db1 CRON[24931]: pam_unix(cron:session): session opened for user root by (uid=0)
May 17 12:28:01 db1 CRON[24931]: pam_unix(cron:session): session closed for user root
May 17 12:28:02 db1 sshd[24955]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
May 17 12:28:04 db1 sshd[24955]: Accepted publickey for tomo from 24.210.28.151 port 63202 ssh2: DSA 3a:[redacted]
May 17 12:28:04 db1 sshd[24955]: pam_unix(sshd:session): session opened for user tomo by (uid=0)

Захват трафика порта 22 с помощью Tcpdump во время попытки подключения:

    $ sudo tcpdump -i en0 port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:00:40.917870 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [S], seq 3430788632, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1286503697 ecr 0,sackOK,eol], length 0
19:00:41.211348 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [S.], seq 4135716624, ack 3430788633, win 28960, options [mss 1460,sackOK,TS val 898678531 ecr 1286503697,nop,wscale 8], length 0
19:00:41.211415 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1, win 4117, options [nop,nop,TS val 1286503989 ecr 898678531], length 0
19:00:41.215051 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1:22, ack 1, win 4117, options [nop,nop,TS val 1286503992 ecr 898678531], length 21
19:00:41.484824 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 22, win 114, options [nop,nop,TS val 898678606 ecr 1286503992], length 0
19:00:41.488532 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1:42, ack 22, win 114, options [nop,nop,TS val 898678609 ecr 1286503992], length 41
19:00:41.488616 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 42, win 4116, options [nop,nop,TS val 1286504260 ecr 898678609], length 0
19:00:41.490182 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], seq 22:1470, ack 42, win 4116, options [nop,nop,TS val 1286504261 ecr 898678609], length 1448
19:00:41.490183 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1470:1614, ack 42, win 4116, options [nop,nop,TS val 1286504261 ecr 898678609], length 144
19:00:41.491254 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], seq 42:1490, ack 22, win 114, options [nop,nop,TS val 898678609 ecr 1286503992], length 1448
19:00:41.592287 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1490, win 4096, options [nop,nop,TS val 1286504362 ecr 898678609], length 0
19:00:41.760341 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1490:1674, ack 22, win 114, options [nop,nop,TS val 898678676 ecr 1286504260], length 184
19:00:41.760401 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1674, win 4090, options [nop,nop,TS val 1286504527 ecr 898678676], length 0
19:00:41.762375 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 1614, win 136, options [nop,nop,TS val 898678676 ecr 1286504261], length 0
19:00:41.762409 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1614:1638, ack 1674, win 4096, options [nop,nop,TS val 1286504529 ecr 898678676], length 24
19:00:42.027042 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1674:1826, ack 1638, win 136, options [nop,nop,TS val 898678743 ecr 1286504529], length 152
19:00:42.027103 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 1826, win 4091, options [nop,nop,TS val 1286504789 ecr 898678743], length 0
19:00:42.028104 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1638:1782, ack 1826, win 4096, options [nop,nop,TS val 1286504790 ecr 898678743], length 144
19:00:42.300304 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 1826:2546, ack 1782, win 148, options [nop,nop,TS val 898678812 ecr 1286504790], length 720
19:00:42.300357 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2546, win 4073, options [nop,nop,TS val 1286505053 ecr 898678812], length 0
19:00:42.302441 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1782:1798, ack 2546, win 4096, options [nop,nop,TS val 1286505055 ecr 898678812], length 16
19:00:42.600776 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 1798, win 148, options [nop,nop,TS val 898678888 ecr 1286505055], length 0
19:00:42.600843 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1798:1850, ack 2546, win 4096, options [nop,nop,TS val 1286505349 ecr 898678888], length 52
19:00:42.857852 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 1850, win 148, options [nop,nop,TS val 898678952 ecr 1286505349], length 0
19:00:42.858552 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2546:2598, ack 1850, win 148, options [nop,nop,TS val 898678952 ecr 1286505349], length 52
19:00:42.858584 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2598, win 4094, options [nop,nop,TS val 1286505604 ecr 898678952], length 0
19:00:42.859131 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1850:1918, ack 2598, win 4096, options [nop,nop,TS val 1286505605 ecr 898678952], length 68
19:00:43.124310 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2598:2650, ack 1918, win 148, options [nop,nop,TS val 898679019 ecr 1286505605], length 52
19:00:43.124374 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2650, win 4094, options [nop,nop,TS val 1286505867 ecr 898679019], length 0
19:00:43.124473 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 1918:2434, ack 2650, win 4096, options [nop,nop,TS val 1286505867 ecr 898679019], length 516
19:00:43.394690 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2650:2702, ack 2434, win 159, options [nop,nop,TS val 898679086 ecr 1286505867], length 52
19:00:43.394774 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2702, win 4094, options [nop,nop,TS val 1286506134 ecr 898679086], length 0
19:01:04.685580 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2434:2582, ack 2702, win 4096, options [nop,nop,TS val 1286527239 ecr 898679086], length 148
19:01:04.966270 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2702:2738, ack 2582, win 170, options [nop,nop,TS val 898684479 ecr 1286527239], length 36
19:01:04.966378 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2738, win 4094, options [nop,nop,TS val 1286527514 ecr 898684479], length 0
19:01:04.967018 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2582:2702, ack 2738, win 4096, options [nop,nop,TS val 1286527514 ecr 898684479], length 120
19:01:05.269214 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [.], ack 2702, win 170, options [nop,nop,TS val 898684555 ecr 1286527514], length 0
19:01:06.027067 IP [redacted_ip].ssh > 192.168.1.2.50409: Flags [P.], seq 2738:2790, ack 2702, win 170, options [nop,nop,TS val 898684744 ecr 1286527514], length 52
19:01:06.027144 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [.], ack 2790, win 4094, options [nop,nop,TS val 1286528563 ecr 898684744], length 0
19:01:06.027497 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286528563 ecr 898684744], length 460
19:01:06.603432 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286529135 ecr 898684744], length 460
19:01:07.552730 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286530077 ecr 898684744], length 460
19:01:09.250116 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286531762 ecr 898684744], length 460
19:01:12.442790 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286534930 ecr 898684744], length 460
19:01:18.634929 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286541067 ecr 898684744], length 460
19:01:24.068621 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286546451 ecr 898684744], length 460
19:01:34.714519 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286557019 ecr 898684744], length 460
19:01:45.384050 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286567587 ecr 898684744], length 460
19:01:56.051835 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286578155 ecr 898684744], length 460
19:02:06.715163 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286588723 ecr 898684744], length 460
19:02:17.355823 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286599291 ecr 898684744], length 460
19:02:28.042962 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [P.], seq 2702:3162, ack 2790, win 4096, options [nop,nop,TS val 1286609859 ecr 898684744], length 460
19:02:38.690971 IP 192.168.1.2.50409 > [redacted_ip].ssh: Flags [R.], seq 3162, ack 2790, win 4096, length 0

Вот еще несколько вещей, которые я попробовал:

  • уменьшение mtu на сервере, возможная ошибка в pmtu: sudo ip link set mtu 1280 dev eth0
  • уменьшение mtu до 1280 в OS X для моего интерфейса Wi-Fi
  • еще больше уменьшив ServerAliveInterval до 30, при котором соединение все еще прерывается, но не с обрывом канала
  • запуск ssh с "cat" вместо "bash" или bash, но без загруженного профиля/rc
  • настройка IP-адреса интерфейса Wi-Fi OS X вручную вместо DHCP

решение1

В трассировке пакетов мы видим, что пакеты максимального размера обмениваются в обоих направлениях на ранней стадии потока. Это не вызвало никаких проблем, поэтому нет ничего, что указывало бы на проблему MTU.

В дальнейшем во время соединения мы видим, что пакет от клиента к серверу с относительными порядковыми номерами 2702:3162 никогда не получает ACK от сервера.

Моя первая мысль — что эта потеря пакетов вызвана неисправным промежуточным устройством (например, NAT, брандмауэром или чем-то подобным).

Я слышал разговоры о NAT-боксах, которые не могут обрабатывать изменение TOS во время TCP-соединения. Проблема в вашем случае возникает после того, как клиент указывает, что TOS был изменен. Однако, поскольку tcpdump не показывает TOS, я не могу точно сказать, является ли это точным моментом, когда возникает проблема.

Для теста вы можете попробовать использовать -o ProxyCommand='nc %h %p'так, чтобы клиент ssh не управлял TCP-соединением напрямую. Вы также можете попробовать опцию IPQoS. Если проблема заключается в изменении TOS, то указание -o IPQoS=cs0или -o IPQoS=0должно сработать, но любая другая настройка не сработает. Это связано с тем, что ssh использует 0 в качестве QoS во время аутентификации, а затем переключается на выбранный QoS после аутентификации. При выборе QoS равным 0 не будет никаких изменений значения QoS, которые могли бы запутать промежуточные устройства.

решение2

На случай, если кто-то еще столкнется с этим, у меня была похожая проблема с маршрутизатором/модемом TP-Link Archer VR2600 (с прошивкой 1.4.0 0.8.0 v0050.0 Build 160518 Rel.50944n).

Запуск с -o IPQoS=0, как предложил @kasperd, сработал, предполагая какую-то проблему QoS с моим маршрутизатором. Я включил самое близкое, что смог найти в настройках маршрутизатора (Передовой→Управление пропускной способностьюустановив максимальную пропускную способность чуть ниже доступной на моей линии), предполагая, что маршрутизатор в этом случае может начать обращать внимание на соответствующие флаги.

Это, кажется, сработало, и теперь мои соединения проходят. Переключение этой опции надежно контролирует, смогу ли я пройти.

решение3

У вас есть пользовательский ssh-конфиг (~/.ssh/config)?

Если нет, создайте его и попробуйте добавить в него следующие строки:

ServerAliveInterval 120 #ping the server every 120s
TCPKeepAlive no #do not set SO_KEEPALIVE on socket

решение4

К сожалению, у меня недостаточно репутации, чтобы проголосовать или прокомментировать ответ Сэма Мейсона выше, но я бы просто хотел публично поставить +1 тому, что он сказал. У меня тоже есть VR2600, и у меня тоже был такой же опыт:

  1. Соединение (ssh, sftp и т. д.) устанавливается, но затем просто зависает.
  2. tshark показывает TCP Spurious Retransmits
  3. настройка -o IPQoS=0 (сама по себе) со стороны клиента ничего не дала
  4. включениенастройка Advanced->Bandwidth Control на маршрутизаторе (ранее отключенная) с максимально возможными пределами (= фактически неограниченными) по-видимому исправляет маршрутизатор таким образом, что он обращает внимание на флаг IPQoS
  5. tshark больше не показывает ложные повторные передачи TCP, а соединение больше не зависает (клиенты ssh, sftp и т. д. теперь работают с сервером за маршрутизатором VR2600).

Кажется, это указывает на существенную ошибку в маршрутизаторе VR2600. К сожалению (на момент написания статьи) у меня установлена ​​последняя прошивка (1.4.0 0.8.0 v0050.0 Build 160518 Rel.50944n, как у Сэма), и этот маршрутизатор, похоже, несовместим с DD-WRT и не тестировался с ней.

ОДНАКО, в дополнение к тому, что обсуждалось выше, я также скажу:

  1. Выполнив шаги с 1 по 5, я теперь могу успешно подключиться даже без указания "-o IPQoS=0"

Другими словами:

Простого включения опции Advanced->Bandwidth Control в настройках маршрутизатора (даже с максимально высоким верхним пределом) кажется достаточно, чтобы заставить этот маршрутизатор NAT вести себя так, как ожидается. Если отключен контроль пропускной способности, возникает проблема, описанная в OP (и довольно подробно @malasa).

Неясно, является ли лекарством простое включение этой опции или вам нужно подключиться хотя бы один раз с опцией -o. В любом случае, я могу подтвердить, что после включения этой опции, если я затемзапрещатьчто опция Advanced->Bandwidth Control, то мои ssh/sftp/etc сломаны, как и раньше. Если ядавать возможностьчто опция Advanced->Bandwidth Control, все снова работает как и ожидалось. И (включив эту опцию) все также работает нормально после перезагрузки маршрутизатора.

Так что, с моей точки зрения, это довольно хорошее решение/исправление, не требующее никаких изменений или обслуживания на стороне клиента (в ответ на беспокойство @leonardoborges)

Связанный контент