Попытка git clone через SSH, но ошибка сбойной трубы

У меня возникли странные проблемы с попыткой сделать git clone одним из моих общедоступных репозиториев GitHub из-за странной проблемы. Я знаю, что это не проблема с моим ключом, потому что я взял тот же ключ у другой виртуальной машины и просто установил его права доступа. Это ошибка, которую я получаю при попытке использовать SSH:

[root:kali:~/scripts]# ssh -T [email protected]_write_wait:
Connection to 192.30.253.112 port 22: Broken pipe

Предложение 1

Ссылка: https://gitlab.com/gitlab-com/support-forum/issues/129

Попытался добавить следующее в файл /etc/ssh/ssh_config:

Host *
ServerAliveInterval 120
TCPKeepAlive no

и не повезло. Я даже попытался изменить TCPKeepAlive на yes, и происходит то же самое.

Мой DNS-сервер установлен на 8.8.8.8, поэтому не совсем уверен, что проблема. Я могу сделать клон http-URL, но не SSH-URL.

Предложение 2

Я также попытался запустить команду ssh с параметром verbose, и в соответствии с выводом он выглядит так, как будто он на самом деле успешно проходит аутентификацию, как показано ниже:

debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to github.com ([192.30.253.113]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = C.UTF-8
debug1: Sending env LC_CTYPE = C.UTF-8
packet_write_wait: Connection to 192.30.253.113 port 22: Broken pipe

Есть идеи, что еще может пойти не так?

ОТВЕТЫ

Ответ 1

Я не знаю, кто этот парень, но благослови его! Это сработало для меня: http://blog.bchoy.me/2018/09/11/vmware-ssh-bug/

Host *
   ServerAliveInterval 600
   TCPKeepAlive yes
   IPQoS=throughput

У него есть ссылка на некоторую дискуссию о параметре IPQoS, которая исправила это для меня.

Ответ 2

Не берите в голову. Переключил сетевой интерфейс от NAT к мостовому режиму, и теперь все хорошо. Псих.

Ответ 3

Решение

У @ScottCrunkleton был правильный ответ для меня, но мне не нужны были все настройки, которые он перечислил. Как минимум, в ~/.ssh/config мне просто нужно было установить:

Host *
   IPQoS=throughput

Информация о IPQoS

Это решило мою проблему, но все, что я хотел знать, это то, что, черт возьми, IPQoS. Я не мог найти простое объяснение в любом месте (эта тема является хитом для ipqos на SO), но там есть хоть какая-то информация.

  • ssh_config man ssh_config описывает опцию IPQoS мы установили выше, и перечисляет все ее допустимые значения.

  • Документы Debian описывают устранение неисправностей, аналогичное ситуации с OP. В их случае они рекомендуют

    Host *
    IPQoS=0x00

    как исправить. Не уверен, в чем разница.

  • И наконец, в списках страниц спецификаций openssh есть спецификация RFC8325, которая описывает QoS (качество обслуживания) очень подробно. Не все так просто, но, насколько я могу судить, идея заключается в том, что при подключении современные версии сервера openssh будут передавать ToS (тип сервиса), который каким-то образом должен соответствовать настройкам QoS вашего клиента.