Git clone fatal protocol error bad line length character

Bad line length character after updating to Sourcetree 3.4.8

i am experiencing an issue already discussed both here and on stackoverflow, concerning this error:

but most solutions suggest the problem lies in the server.

Thing is, this happens only on my desktop where i’ve updated to SourceTree 3.4.8; if i try to fetch/push from my laptop to the very same server it works just fine.
On my laptop i delayed the update, and still running SourceTree ver. 3.4.7.

As for the server address, which includes the 4 bytes of the error message reported above, it is in fact:

Pageant is running on the client, although there is no ssh key, since i am hosting the server in my house and there’s just a password auth for the user git_user .

I also tried removing the passwd file, to see if it was failing authentication, but pushing/fetching won’t even get to the authentication phase: i reckon the error happens before auth, since i’m not being asked to input the password again.

Aside from testing with both machines, with the same configuration, where one works and the other doesn’t, i’m quite stuck with troubleshooting. the only thing i could concieve was the version mismatch.
I should probably try to downgrade and see if it solves the issue.

Can anyone provide additional feedback?
Thanks

Источник

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

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

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

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

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

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

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

30 ответы

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

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

Что происходит, когда ты бежишь ssh git-receive-pack

? Вы должны увидеть сообщение об ошибке, с которым работает ваш git-клиент, и вы, возможно, сможете его исправить.

ответ дан 19 апр.

Это и ssh /bin/true не должен ничего выводить. — Стефан Нэве

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

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

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

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

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

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

Это в Windows, с GIT_SSH установить на путь plink.exe PuTTY.

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

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

ответ дан 10 мар ’16, в 10:03

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

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

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

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

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

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

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

Выбрать [OpenSSH] вместо того [PuTTY]

ответ дан 01 окт ’18, 07:10

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

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

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

ответ дан 11 апр.

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

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

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

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

Так было со мной. В моем .bashrc была команда «баннер». Комментирование устранило проблему. Спасибо :). — Джейми

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

ответ дан 16 дек ’15, 15:12

для меня — добавление закрытого ключа ssh в конкурс — Ник Грили

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

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

ответ дан 17 мая ’13, 10:05

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

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

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

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

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

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

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

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

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

И в моем случае я добавил LocalCommand config, чтобы что-то повторить — Фу Нго

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

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

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

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

git clone ssh: // @someaccount.amazonaws.com/v1/repos/repo1

Примечание: это потому, что вы используете plink, и если вы это сделаете plink ls тогда первое, что выводит plink на стандартный вывод, это login as , который git пытается интерпретировать как нечто важное. Быстрое решение — просто unset GIT_SSH и unset SVN_SSH . Больше информации здесь — Стручок

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

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

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

Создан 30 июля ’13, 13:07

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

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

ответ дан 23 авг.

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

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

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

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

Я пришел к такому же выводу на ПК с Windows 10 с Visual Studio Code — PaulH

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

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

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

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

ответ дан 28 авг.

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

ответ дан 16 мая ’17, 20:05

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

ответ дан 18 мая ’18, 00:05

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

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

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

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

Источник

fatal: protocol error: bad line length character is an error I started seeing when trying to perform git clone, git fetch or git pull from public Git repositories hosted at git.wincent.com. I am not entirely sure when the problem started but I first noticed it after updating my local Git install to version 1.6.4 (see «Updating to Git 1.6.4»), with the server still running 1.6.3.3 (see «Updating to Git 1.6.3.3»).

Troubleshooting

First step, try using another version of Git to perform the clone. On the server itself:

$ git --version
git version 1.6.3.3
$ cd /tmp
$ git clone git://git.wincent.com/WOPublic.git
Initialized empty Git repository in /tmp/WOPublic/.git/
fatal: protocol error: bad line length character

So we know it’s not a conflict between 1.6.3.3 and 1.6.4. Could be a problem with the 1.6.3.3 server, so let’s update the server; see «Updating to Git 1.6.4» for the full details.

Now we repeat our server-side clone test:

$ git --version
git version 1.6.4
$ git clone git://git.wincent.com/WOPublic.git
Initialized empty Git repository in /tmp/WOPublic/.git/
fatal: protocol error: bad line length character

So back to the old drawing board… Try cloning from a different server:

$ git clone git://github.com/wincent/WOPublic.git
Initialized empty Git repository in /tmp/WOPublic/.git/
remote: Counting objects: 403, done.
remote: Compressing objects: 100% (218/218), done.
remote: Total 403 (delta 242), reused 297 (delta 172)
Receiving objects: 100% (403/403), 153.31 KiB, done.
Resolving deltas: 100% (242/242), done.

So we can see here that the problem is almost certainly not on the client side, regardless of whether the client is running 1.6.3.3 and 1.6.4. And we’ve also established that the problem on the server side was present in 1.6.3.3 just as it is in 1.6.4.

I wanted to see if this affected all repositories or just the one I was working with at that moment (WOPublic), but it turns out that the message is always the same, even for non-existent repos such as this fictional «xyz» one:

$ git clone git://git.wincent.com/xyz
Initialized empty Git repository in /private/tmp/xyz/.git/
fatal: protocol error: bad line length character

Looks like this is going to be hideously painful, but I am going to try and bisect it. I am not even sure what the last known «good» version was, so I guess I am going to go back through the «major» revisions (1.6.3, 1.6.2, 1.6.1) until I find one that works, then will run git bisect from there:

$ git co v1.6.3
$ make clean
$ NO_CURL=1 NO_EXPAT=1 NO_SVN_TESTS=1 NO_TCLTK=1 make test prefix=/usr/local
$ sudo -s
# NO_CURL=1 NO_EXPAT=1 NO_SVN_TESTS=1 NO_TCLTK=1 make prefix=/usr/local install

Ditto for:

• v1.6.2 (broken)
• v1.6.1 (works)

That’s a relief. We can start the real bisection:

$ git bisect start v1.6.2 v1.6.1
$ make clean
$ NO_CURL=1 NO_EXPAT=1 NO_SVN_TESTS=1 NO_TCLTK=1 make test prefix=/usr/local
$ sudo -s
# NO_CURL=1 NO_EXPAT=1 NO_SVN_TESTS=1 NO_TCLTK=1 make prefix=/usr/local install
# exit

And then git bisect good or git bisect bad, depending on the result and repeat…

Ultimately, we bisect down to this:

8e3462837b0ace04357503a3f58802cc2231df29 is first bad commit
commit 8e3462837b0ace04357503a3f58802cc2231df29
Author: Steffen Prohaska <prohaska@zib.de>
Date:   Sun Jan 18 13:00:13 2009 +0100

    Modify setup_path() to only add git_exec_path() to PATH

    Searching git programs only in the highest priority location is
    sufficient.  It does not make sense that some of the required
    programs are located at the highest priority location but other
    programs are picked up from a lower priority exec-path.  If
    exec-path is overridden a complete set of commands should be
    provided, otherwise several different versions could get mixed,
    which is likely to cause confusion.

    If a user explicitly overrides the default location (by --exec-path
    or GIT_EXEC_PATH), we now expect that all the required programs are
    found there.  Instead of adding the directories "argv_exec_path",
    "getenv(EXEC_PATH_ENVIRONMENT)", and "system_path(GIT_EXEC_PATH)"
    to PATH, we now rely on git_exec_path(), which implements the same
    order, but only returns the highest priority location to search for
    executables.

    Accessing only the location with highest priority is also required
    for testing executables built with RUNTIME_PREFIX.  The call to
    system_path() should be avoided if RUNTIME_PREFIX is set and the
    executable is not installed at its final destination.  Because we
    test before installing, we want to avoid calling system_path()
    during tests.  The modifications in this commit avoid calling
    system_path(GIT_EXEC_PATH) if a higher-priority location is
    provided, which is the case when running the tests.

    Signed-off-by: Steffen Prohaska <prohaska@zib.de>
    Acked-by: Johannes Sixt <j6t@kdbg.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

This is on a server with Git installed using prefix=/usr/local, but /usr/local/bin is not in the default PATH so the daemon is launched via xinetd with the following settings in /etc/xinetd.d/git:

• server is explicitly set to the absolute path, /usr/local/bin/git
• in server_args, we pass --exec-path=/usr/local/bin daemon --inetd etc

The key paragraph in the commit message for 8e34628 sheds light on what’s happening here:

   If a user explicitly overrides the default location (by --exec-path
   or GIT_EXEC_PATH), we now expect that all the required programs are
   found there.  Instead of adding the directories "argv_exec_path",
   "getenv(EXEC_PATH_ENVIRONMENT)", and "system_path(GIT_EXEC_PATH)"
   to PATH, we now rely on git_exec_path(), which implements the same
   order, but only returns the highest priority location to search for
   executables.

So, dropped the explicit --exec-path from the server_args and the bad line length character errors go away. The git executable is obviously smart enough to know where the needed binaries are (currently /usr/local/libexec/git-core) and so doesn’t need the explicit parameter; and in fact, it was something that I only ever added in the first place to fix breakage caused by changes to where the binaries were stored and how they were searched for (see «Upgrading to Git 1.5.4»).

See also

• Entry on the official Git FAQ for the protocol error: bad line length character message (not really helpful/applicable to this specific case as it applies to SSH-based access and I am talking about anonymous public access using the Git protocol): http://git.or.cz/gitwiki/GitFaq#protocolerror.3Abadlinelengthcharacter
• Mailing list thread: http://kerneltrap.org/mailarchive/git/2007/1/20/236259
• Google search for ‘»protocol error: bad line length character» git’ (currently 209 results at time of writing)

fatal: protocol error: bad line length character: Unab

30 Answers

$ git pull
fatal: protocol error: bad line length character: [email protected]

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
rvm use [email protected]

rvm use [email protected] > /dev/null

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

git clone [email protected]:path/to/repo
fatal: protocol error: bad line length character: [email protected]

RequestTTY force

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

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

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

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

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

$ plink server-name
login as: _

$ plink [email protected]
...logs you in...

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

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