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

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

fatal: protocol error: bad line length character: Unab

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

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

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

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

Это сообщение об ошибке немного туповато, но на самом деле оно пытается вам сказать, что удаленный сервер не ответил правильным ответом 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-agent был запущен и сгенерированный ключ был добавлен ( ссылка на 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 Authentication Agent) запущен и соответствующий закрытый ключ загружен.

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

   git clone ssh: // {ID ключа 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) и добавить закрытый ключ, который исчез из списка ключей.

К вашему сведению, я получил то же сообщение об ошибке после того, как обновил контейнер 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. Комментарий к этому исправил ошибку.

В моем случае проблема заключалась в 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 pull origin <current_branch>

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

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

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

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

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

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

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-адресу.

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

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

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

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

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

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

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

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каталог и отредактировать 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/*

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