SSH зависає на SSH2_MSG_KEX_ECDH_REPLY: не завжди річ у MTU

Тунель піднято, банер надходить, і клієнт друкує повідомлення про очікування відповіді обміну ключами. Результати пошуку вказують прямо на MTU, і іноді це слушно. Часто ні: відповідь могла взагалі не надсилатися, бо клієнт не зміг прочитати файл ключа або сторони так і не домовилися про алгоритм. Рядок описує, чого чекає клієнт, а не чому почалося очікування. Вважайте це симптомом і відокремте три причини, перш ніж змінювати будь-який розмір.

Прочитайте трасування, щоб побачити, чи відповідь взагалі очікувалася

Докладний вивід показує останній успішний крок перед тишею. Якщо банер протоколу сервера надійшов, TCP працює і віддалений бік живий; відкрите питання — що сталося з одним конкретним пакетом. Хвилина тиші після банера виглядає як проблема шляху. Повідомлення про відсутність відповідного методу обміну ключами — це проблема політики. Довге очікування, що закінчується закриттям сеансу сервером, означає, що сервер здався, і його журнал пояснює чому.

В останньому випадку прочитайте журнал автентифікації сервера, перш ніж торкатися клієнта. Клієнт не може побачити рішення, яке сервер ніколи не надсилав.

Чому маленька відповідь усе одно може бути завеликою

Відповіді під час обміну ключами зазвичай крихітні, тому звинувачувати розмір здається неправильним. Із сертифікатами хоста відповідь не крихітна, бо несе ланцюг сертифікатів сервера. Це робить її першим пакетом сеансу, який може перевищити корисне навантаження тунелю. Коли зворотний зв'язок виявлення MTU шляху губиться десь на маршруті, відправник продовжує надсилати пакет, який не вміщується, і клієнт чекає вічно на тому самому рядку.

Визначте розмір, а не припускайте його. Прочитайте MTU тунелю за допомогою ip link show tun0, потім надішліть проби, які не повинні фрагментуватися: ping -4 -M do -s 1352 host, повторюючи з меншими навантаженнями. Перехід від невдачі до успіху за певного розміру — це доказ; рівномірна невдача свідчить, що ICMP фільтрується, і нічого вам не каже.

Тимчасове зменшення швидко підтверджує теорію, а постійний варіант належить профілю або як обмеження MSS на маршрутизаторі, що передає тунель:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Дві причини, що імітують проблему розміру

Файл ключа, який клієнт не може прочитати, дає те саме очікування, без попередження навіть у докладному виводі. Один шаблон known_hosts робить це простим: запис @cert-authority, що вказує на відкритий ключ CA, який може прочитати лише один обліковий запис. Обліковий запис-власник файлу підключається, а всі інші зависають. Якщо збій слідує за користувачем, а не за хостом, перевірте режими файлу раніше за розміри пакетів.

Оновлення також може прибрати алгоритм, який обидві сторони раніше використовували. Закріпіть один метод, який сервер ще пропонує, як діагностику: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. З'єднання, яке одразу вдається, доводить, що шлях гаразд, і виправлення належить політиці узгодження з обох боків.

Три факти, які варто записати

Запишіть MTU тунелю до і після будь-якої зміни, чи падає копіювання великого файлу на повторюваному розмірі і чи зависає хост без сертифіката в тому самому тунелі так само. Ці три спостереження відокремлюють розмір від прав і від узгодження швидше, ніж стос команд.

Вони також заважають наступній людині знизити MTU через несправність, яка ніколи не стосувалася розміру.

Якщо картина досі неясна, перевірте з другого клієнта в тому самому тунелі. Клієнт, який підключається, переносить несправність зі шляху на конфігурацію першої машини.