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

Question

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

[root:kali:~/scripts]# ssh -T git@github.compacket_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

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

Answer 1

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

Host *
   ServerAliveInterval 600
   TCPKeepAlive yes
   IPQoS=throughput

У него есть ссылка на некоторые обсуждения о параметре IPQoS - который исправил его для меня.

Answer 2

Решение

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

Host *
   IPQoS=throughput

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

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

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

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

  Host *
      IPQoS=0x00
  

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

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

Answer 3

Nevermind.Переключил сетевой интерфейс с NAT на мостовой режим и теперь все хорошо.Сумасшедший.