Попытка 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
вашего клиента.