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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

rvm use [email protected] > /dev/null

Ответ 4

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

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

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

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

Ответ 5

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

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

Решение:

Сервис> Настройки> Расширения Git> SSH

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

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

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

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

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

Ответ 10

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

Ответ 11

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

RequestTTY force

в .ssh/config

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

Ответ 12

В моем случае после получения было написано: fatal: protocol error: bad line length character: Pass. Также после нажатия я получил: fatal: protocol error: bad line length character: [email protected].

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

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

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

Ответ 17

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

Ответ 18

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

Ответ 19

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

Ответ 20

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

Ответ 21

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

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

git clone ssh://[email protected]: /path/to/git/repo.git

вы получите это сообщение "fatal: protocol error: неверный символ длины строки:"

Ответ 22

Ошибка, преобразованная в: fatal: ошибка протокола: неправильный символ длины строки: fata​​p >

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

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

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

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

Ответ 23

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

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

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

Ответ 24

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

Ответ 25

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

Ответ 26

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

Ответ 27

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

Решение

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

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

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

Изменить на

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

Ответ 28

Изменение ssh exectuable от builtin to nativ в настройках/управлении версиями /git сделало трюк для меня.

Ответ 29

TL; DR: не опускайте [email protected] в ваших удаленных 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 [email protected]
...logs you in...

Если вы уже каким-либо образом клонировали репозиторий, вы можете починить пульты в вашем .git/config, добавив [email protected] к удаленному URL.

Ответ 30

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