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


120

Я настроил сервер git и теперь хочу сначала отправить свое репо с клиента. Я использовал git push origin masterи получаю это сообщение об ошибке:

fatal: protocol error: bad line length character: Unab

Я не знаю, что случилось. Я не знаю, что такое «Унаб». Я попытался изменить размер оболочки, но она все еще "Unab". Я не могу найти решение для этого сообщения об ошибке.

Я настраиваю сервер с «authorized_keys» и SSH. (Я могу подключиться к нему по SSH.)

Вроде проблема с git?

Кстати: сервер настроен на виртуальной машине Windows 7


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

Ответы:


117

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

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

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


10
Это и ssh <host> /bin/trueничего не должно выводить.
Stefan Näwe

9
У меня была такая же проблема, и причиной была "echo" .bashrc "" в моем .bashrc, поэтому вместо "фатальной: ошибка протокола: неправильная длина строки" символ: Unab "я видел" фатальная: ошибка протокола: неправильная длина строки персонаж: .bas ".
snarkyname77

4
Да, это тоже была моя проблема: у меня .bashrcна машине, на которой размещался репозиторий Git, из которого я пытался извлечь, была строка, которая выдавала эхо на стандартный вывод. (То есть я был владельцем репозитория на удаленной машине, поэтому .bashrcпроблема была вызвана мной .) Я использовал трюк, данный пользователем ruslo в другом ответе, а именно перенаправил вывод этой команды из stdout в stderr ( some_command 1>&2). После этого git pullснова заработал.
Teemu Leisti

2
С помощью указанной выше команды вывод просто зависает. В нем перечислены все мои ветки, по одной в каждой строке, а затем в последней напечатанной строке я получаю результат 0000 и курсор сразу после, как если бы другая строка была записана, но никогда не завершается.
demongolem

3
Я ненавижу сталкиваться с проблемой семилетней давности, но у меня та же проблема 0000 с git-receive-pack. Он зависает, пока я не нажму четыре раза клавишу возврата, после чего он сообщает о той же ошибке протокола и завершает работу.
Марк Э. Гамильтон

61

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

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

Это в Windows с GIT_SSHустановленным путем plink.exeк PuTTY.

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

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

7
У меня была такая же проблема в Windows, и она оказалась той же основной причиной по противоположной причине. Я пытался использовать Cygwin (и встроенный Git SSH), но для GIT_SSH было установлено значение C: \ ... \ plink.exe, что вызывало конфликт. Как только я удалил это, все заработало.
Мэтт Хольцман

11
Удаление записи GIT_SSH из переменных среды
помогло

Похожая ошибка после обновления GitExt пришлось перезапустить pageant и повторно импортировать ключевой файл .ppk.
Билл Долан

9
Я просто забыл загрузить закрытый ключ на конкурсе, которым закончился fatal: protocol error: bad line length character: git@. Что за вводящее в заблуждение сообщение об ошибке.
Людвиг

1
В моем случае (Windows 10) конкурс не запускался. Как только я запустил его и добавил к нему закрытый ключ, это просто сработало.
26 апреля,

30

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

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

Решение:

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

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

введите описание изображения здесь


Это именно то, что я сделал, когда вы получили сообщение об ошибке fatal: protocol error: bad line length character: git@. Убедитесь, что ключ SSH сгенерирован и добавлен в GitLab . Возможно, перезапуск Git Extensions был необходим.
тестирование

20

У меня была такая же проблема после установки 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


Для меня ситуация заключалась в том, что в Visual Studio я получал ошибку: «Git завершился с фатальной ошибкой. Ошибка протокола: неправильная длина строки, символ: gitu» каждый раз при перезапуске Windows. Конкурс вообще не начался. Мне нужно было использовать, например, TortoiseGit, который решил эту проблему в фоновом режиме, а затем GIT работал в Visual Studio как шарм.
Honza P.

18

Возможно, у вас есть оператор в серверном .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

В моем случае (Windows 10) проблема заключалась в выводе некоторых команд, связанных с докером, в моем сценарии запуска cmd init.cmd (который я создал с помощью этих инструкций: stackoverflow.com/questions/17404165/…). но принцип тот же. Спасибо!
ET-CS

Так было со мной. В моем .bashrc была команда "баннер". Комментируя это, проблема была решена. Спасибо :).
Jamie


10

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

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

git проигнорирует эти символы


Это сделало это для меня. У меня было заявление rvm use 2.0.0-p353в моем .bashrc, которое должно быть запутало git pull. После добавления 1>&2и повторной попытки все git pullработало нормально.
Teemu Leisti

7

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

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

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

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


Я вижу то же самое (64-разрядная версия Windows 10), но запуск от имени администратора не исправляет.
Эд Авис

4
У меня есть догадка о том, что вызывает это. Если у вас не настроена пара ключей ssh ​​(или она по какой-то причине не читается), то ssh запрашивает пароль. В Windows нет четкого различия между стандартным выводом и выводом на консоль, поэтому запрос пароля переходит к stdout: "git @ Any's password:". Это рассматривается git как поврежденный вывод протокола.
Эд Авис

@EdAvis Спасибо! У меня была та же проблема, и после прочтения вашего комментария я дважды проверил свой ключевой агент (который обычно запускается при запуске на моей машине). Оказалось, что он по какой-то причине не работает ...
Griddo 03

5

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

RequestTTY force

в .ssh / config

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


И в моем случае я добавил LocalCommandконфиг для эха чего-то
Phu Ngo

5

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

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

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

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

    git clone ssh: // {ID ключа SSH}@someaccount.amazonaws.com/v1/repos/repo1


4
Примечание: это потому, что вы используете plink, и если вы это сделаете, plink <server_name> lsпервое, что plink выводит на стандартный вывод, это то login as, что git пытается интерпретировать как нечто важное. Быстрое решение - просто unset GIT_SSHи unset SVN_SSH. Более подробная информация здесь
Pod

@Pod, вы правы, на windows эти команды должны помочь: set GIT_SSH=иset SVN_SSH=
Максим Костромин

У меня была такая же проблема с TFS. После добавления идентификатора ключа все работает нормально, спасибо!
Андре Хофмайстер

3

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


3

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

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


2

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

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

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

# ssh git@bitbucket.org
Invalid clock_id for clock_gettime: 7

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


2

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


2

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


1

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


1

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

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

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


1

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


1

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. Ответ Дэна Макклейна в /server/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801 описывает это. Одно дополнение к его ответу, в моем случае ожидалось, что файл закрытого ключа будет называться id_rsa.pub


1

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


1

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

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

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

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


1

TL; DR: Do не опускаем 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-адресу.


git remote set-url origin myusername@...Мне помогло добавление имени пользователя к удаленному .
Максим Суслов

0

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


у меня было «Привет». Оказывается, я следил за каким-то сайтом настройки безопасности, и теперь мой логин git говорит: «Привет, git! Вы успешно прошли аутентификацию, но я не предоставляю интерактивный доступ к оболочке». думаю, я должен удалить это ....
Дон

0

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

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

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

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

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


0

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

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

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


0

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


0

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


0

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


0

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

Решение

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

  2. Еще одно быстрое исправление - перейти в свой .gitкаталог и отредактировать configфайл [remote "origin"] urlот 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/*

0

Изменение исполняемого файла ssh со встроенного на nativ в settings / version control / git помогло мне.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.