Git Remote: ошибка: фатальная: ошибка протокола: неправильный символ длины строки: Unab

Это сообщение об ошибке немного бестолковое, но на самом деле оно пытается вам сказать, что удаленный сервер не ответил правильным ответом git. В конечном итоге возникла проблема на сервере, на котором запущен процесс git-receive-pack.

В протоколе Git первые четыре байта должны быть длиной строки. Вместо этого это были символы Unab... что, вероятно, является началом какого-то сообщения об ошибке. (т.е., вероятно, "Unable to..." что-то делает).

Что происходит, когда вы запускаете ssh <host> git-receive-pack <path-to-git-repository>? Вы должны увидеть сообщение об ошибке, из-за которого ваш git-клиент блеет, и вы сможете исправить его.

У меня была похожая проблема, но точное сообщение об ошибке было:

фатальный: ошибка протокола: неправильный символ длины строки: Usin

Это в Windows, где GIT_SSH установлен на путь plink.exe PuTTY.

Возможные проблемы и решения:

• Убедитесь, что путь к plink.exe указан правильно. Путь в стиле Unix тоже работает нормально, например /c/work/tools/PuTTY/plink.exe
• Убедитесь, что ключевой агент PuTTY (pageant.exe) запущен.
• Убедитесь, что агент ключей содержит действительный ключ для доступа к серверу.

Для пользователей GitExtension:

Я столкнулся с той же проблемой после обновления git до 2.19.0.

Решение:

Инструменты > Настройки > Расширения Git > SSH

Выберите [OpenSSH] вместо [PuTTY].

У меня была такая же проблема после установки GIT в Windows. Сначала это сработало; затем, через день (после перезагрузки ПК), этого больше не было, и я получил это:

$ git pull
fatal: protocol error: bad line length character: git@

Проблема заключалась в том, что после перезагрузки автоматически запускаемый Putty «pageant.exe» больше не имел активного закрытого ключа. Когда вы добавляете ключ в театрализованное представление, он не является постоянной настройкой по умолчанию. Мне просто нужно было снова добавить ключ, и он работал нормально. Итак, в этом случае необходимо, чтобы pagenant загружал ключ автоматически, как описано здесь:

https://www.digitalocean.com/community/tutorials/how-to-use-pageant-to-streamline-ssh-key-authentication-with-putty

Возможно, у вас есть оператор в .bashrc сервера, который производит вывод. У меня например было так:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
rvm use ruby-1.9.3-p194@rails32

В этом случае вывод использования rvm будет (ошибочно) интерпретироваться как исходящий от git. Поэтому замените его на:

rvm use ruby-1.9.3-p194@rails32 > /dev/null

После загрузки закрытого ключа SSH в Git Extensions эта проблема будет решена.

Вы можете перенаправить любой вывод с .bashrc на stderr:

# inside .bashrc
echo 'some error/warning/remind message' 1>&2

git будет игнорировать эти символы

У меня была аналогичная проблема в Windows с использованием Git Bash. Я продолжал получать эту ошибку при попытке сделать клон git. Репозиторий был на Linux с установленным GitLab.

git clone git@servername:path/to/repo
fatal: protocol error: bad line length character: git@

Я убедился, что ключ ssh был сгенерирован. Открытый ключ был добавлен на GitLab. Агент ssh был запущен, и сгенерированный ключ был добавлен (ссылка на github) .

У меня закончились варианты, и затем, наконец, я попытался закрыть Git Bash и снова открыть его, щелкнув правой кнопкой мыши «Запуск от имени администратора». Работал после этого.

Для меня это было потому, что я недавно добавил

RequestTTY force

в .ssh/config

комментирование этого позволило ему работать

Это может помочь кому-то. Когда я пытался клонировать проект из экземпляра EC2, я получал следующую ошибку:

Cloning into 'repo1'...
fatal: protocol error: bad line length character: logi

Решение для меня включает следующие шаги:

1. Убедитесь, что ключ SSH (общедоступный) добавлен/обновлен в экземпляре EC2.
2. Убедитесь, что агент аутентификации (в моем случае это агент аутентификации Pageant=Putty) запущен и соответствующий закрытый ключ загружен.

3. Используйте идентификатор ключа SSH EC2 в качестве открытого ключа для git clone. Пример:

   git clone ssh://{Идентификатор ключа SSH}@someaccount.amazonaws.com/v1/repos/repo1

Проверьте свои файлы запуска в учетной записи, используемой для подключения к удаленному компьютеру, на наличие операторов «эха». Для оболочки Bash это будут ваши .bashrc и .bash_profile и т. д. Эдвард Томсон прав в своем ответе, но конкретная проблема, с которой я столкнулся, заключается в том, что при входе на сервер через ssh появляется некоторая стандартная распечатка. Git получит первые четыре байта этого шаблона и выдаст эту ошибку. Теперь в этом конкретном случае я собираюсь предположить, что «Unab» на самом деле является работой «Unable...», что, вероятно, указывает на то, что на хосте Git что-то еще не так.

В моем случае после выборки было написано: fatal: protocol error: bad line length character: Pass. Также после нажатия я получил: fatal: protocol error: bad line length character: git@ Done.

После перезагрузки Windows мне пришлось снова запускать "агент PuTTY" (pageant.exe) и добавлять приватный ключ, который исчез из списка ключей.

Если вы используете Putty. Затем убедитесь, что Pageant запущен, и ваш закрытый ключ загружен в Pageant (щелкните правой кнопкой мыши значок Pageant на панели задач и выберите «Просмотреть ключи» в появившемся меню).

В противном случае, когда вы делаете в cmd.exe :

git clone ssh://name@host:/path/to/git/repo.git

вы получаете это сообщение «фатальная: ошибка протокола: неправильный символ длины строки:»

я также сталкиваюсь с этой ошибкой время от времени, но когда это происходит, это означает, что моя ветка не актуальна, поэтому я должен сделать git pull origin <current_branch>

К вашему сведению, я получил такое же сообщение об ошибке после того, как обновил контейнер CentOS6 до CentOS7 — некоторые операции git начали давать сбой при сборке контейнера, например.

# git remote show origin
fatal: protocol error: bad line length character: Inva

Запуск ssh дал мне ошибку, которую я мог искать:

# ssh [email protected]
Invalid clock_id for clock_gettime: 7

Это привело меня к https://github.com/wolfcw/libfaketime/issues/63. где я понял, что забыл, что у меня есть LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1 в родительском файле Docker. Комментируя это, исправлена ​​​​ошибка.

В моем случае проблема заключалась в 32-битном Putty и pageant.exe — он не может взаимодействовать с 64-битным TortoisePlink.exe. Замена 32-битной версии Putty на 64-битную решила проблему.

У меня была такая же ошибка "fatal: protocol error: bad line length character: shmi" Где shmi в моем случае это имя пользователя. Я переключил SSH с PuTTY на OpenSSH в "Git Extensions->Settings->SSH". Это помогло.

У меня была та же проблема, что и у Кристера Фернстрома. В моем случае это было сообщение, которое я поместил в свой .bashrc, напоминающее мне сделать резервную копию, если я не делал ее пару дней.

Кому-то может помочь следующее: при попытке клонировать проект, который у меня есть на моем экземпляре AWS EC2, я получаю следующую ошибку:

Cloning into 'AWSbareRepo'...
fatal: protocol error: bad line length character: Plea

Это было вызвано попыткой использовать ssh от имени пользователя root вместо EC2-USER. если вы на самом деле ssh без клонирования git ... вы увидите сообщение об ошибке в чем-то вроде «Пожалуйста, войдите в систему с пользователем ec2». Когда я сделал клонирование git как пользователь ec2, это было хорошо.

Git не запрашивает пароль и выдает аналогичное загадочное сообщение «фатальная ошибка протокола: неправильный символ длины строки: пользователь» если у вас также нет настройки аутентификации с закрытым ключом.

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server рассказывает, как указать открытый ключ на сервере. В основном добавьте открытый ключ в ~/.ssh/authorized_keys или ~/.ssh/authorized_keys2.

Мне пришлось немного потрудиться над тем, как предоставить закрытый ключ Git Bash на машине с Windows. Ответ Дэна Макклейна в https://serverfault.com/questions/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 описывает это. Одно дополнение к его ответу: в моем случае файл закрытого ключа должен был называться id_rsa.pub.

Для меня сработало добавление тех же сведений о хосте в Putty с закрытым ключом (конвертировать с помощью puttygen). Любые команды git bash после этого не имели проблем.

TL;DR: не опускайте username@ в удаленных URL-адресах при работе в Windows.

В Linux и Windows с ssh по умолчанию вы можете опустить имя пользователя из удаленных URL-адресов, например:

git clone server-name:/srv/git/repo-name

Потому что по умолчанию ssh использует любое имя пользователя, под которым вы вошли в систему. Если вы работаете в Windows и настроили git для использования plink.exe, чтобы вы могли использовать ключ, загруженный в ваш pageant, то это не сработает, потому что plink не имеет такого же автоматического поведения имени пользователя, что приводит к этим загадочным сообщениям об ошибках, потому что он запросит имя пользователя:

$ plink server-name
login as: _

Против:

$ plink username@server-name
...logs you in...

Если вы уже каким-то образом клонировали репозиторий, вы можете исправить удаленные устройства в своем .git/config, добавив username@ к удаленному URL-адресу.

Проверьте, разрешен ли доступ к Shell на сервере.

Ошибка преобразована в: фатальная: ошибка протокола: неправильный символ длины строки: фата

после добавления местоположения git-upload-pack в системный путь.

Проблема, похоже, заключается в добавлении апострофа к имени репозитория: поиск с помощью такого инструмента, как Process Monitor (из внутренних компонентов sys), который был добавлен клиентом git. Кажется, это проблема с git, специфичная для Windows.

Я попробовал ту же командную строку в приглашении сервера: полная ошибка была «фатальной: не заданный репозиторий (или какой-либо из родительских каталогов): .git»

В заключение, мне кажется, что это ошибка программного обеспечения. Имейте в виду, что я не эксперт по git, я впервые использую git, я пришел из subversion и perforce.

Мы тоже столкнулись с этим.

Counting objects: 85, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (38/38), 3.38 KiB | 0 bytes/s, done.
Total 38 (delta 33), reused 0 (delta 0)
Auto packing the repository for optimum performance.
fatal: protocol error: bad line length character: Remo
error: error in sideband demultiplexer

Я не знаю подробностей о том, что пошло не так, но в нашем случае это произошло из-за того, что диск на сервере был заполнен.

Это может быть безопасный доступ на вашем компьютере, вы используете Pageant (который является агентом замазки)?

у вас всегда может быть http-ссылка на ваш проект git. Вы можете использовать это вместо ссылки ssh. Это просто ваш вариант

У меня была такая же проблема (Windows 7). Попробуйте получить репо по паролю. Я использую Git Bash + Plink (переменная среды GIT_SSH) + Pageant. Мне помогает удаление GIT_SSH (временное). Я не знаю, почему я не могу одновременно использовать логин по паролю и логин с RSA...

Поздний ответ здесь, но надеюсь, что это кому-то поможет. Если это ошибка протокола, он должен что-то сделать с вашим локальным git, который не может связаться с удаленным git. Это может произойти, если вы клонировали репозиторий через ssh, а через некоторое время потеряли ключи к репозиторию или ваш агент ssh больше не может найти эти ключи.

Решение

1. Создайте новый ключ и добавьте его в свой репозиторий git или настройте свой ssh-агент для загрузки ключей, если у вас все еще есть ключи с вами, а не с кем-то еще;)

2. Еще одно быстрое решение — перейти в каталог .git и отредактировать [remote "origin"] url файла config с git на http, чтобы ключи ssh не требовались для нажатия, и он вернется к запросу вашего имени пользователя и пароля.

   [remote "origin"]
   url = git@gitlab.*****.com:****/****.git
   fetch = +refs/heads/*:refs/remotes/origin/*
   

Изменить на

    [remote "origin"]
    url = http://gitlab.*****.com/****/****.git
    fetch = +refs/heads/*:refs/remotes/origin/*

Изменение исполняемого файла ssh со встроенного на нативное в настройках/контроле версий/git помогло мне.

У меня была такая же проблема, когда я сделал git pull

git pull fatal: ошибка протокола: неправильный символ длины строки: ‹htm fatal: удаленный конец неожиданно повесил трубку

Я изменил свой удаленный URL-адрес HTTP на SSH, и это сработало для меня.

git remote set-url origin HTTP to SSH

В моем случае проблема вызвана измененным файлом /bin/ssh. Я работаю на сервере с другими людьми, и дефолтный /bin/ssh как-то модифицирован, он выводит непреднамеренные логи при запуске. Я восстанавливаю /bin/ssh в правильный исполняемый файл и решаю его.

В моем случае в основном мне нужно было перезагрузить Windows.