В Git удаленный: ошибка: фатальная ошибка: ошибка протокола: плохая линия длина: сайт unab

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

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

это в Windows, с GIT_SSH установить на путь plink.exe из шпаклевки.

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

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

может быть, у вас есть заявление на сервере .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 эта проблема будет решена.

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

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

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

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

вы можете перенаправить любой вывод от .bashrc to 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@

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

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

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

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

RequestTTY force

што .ssh / config

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

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

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

резолюция для меня включает в себя следующие действия:

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

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

   git clone ssh: / / {SSH Key ID}@someaccount.amazonaws.com/v1/repos/repo1

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

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

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

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

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

Я попробовал ту же командную строку в командной строке сервера: полная ошибка was " fatal: not a given repository (or any of the parent Directory): .ГИТ"

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

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

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

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

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

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

FYI я получил это же сообщение об ошибке после того, как я обновил контейнер 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 и торжества.exe-он не может общаться с 64-разрядной TortoisePlink.исполняемый. Замена 32-битной замазки на 64-битную версию решила проблему.

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

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

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

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 (временное) помогает мне. Я не знаю, почему я не могу использовать login by pass и login с RSA одновременно...

Git не запрашивает пароль и не работает с аналогичным загадочным сообщением "fatal: protocol error: bad line length character: user"если у вас нет настройки аутентификации с закрытым ключом Как хорошо.

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.паб

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

решение

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

2. еще одно быстрое решение-перейти к вашему

изменение ssh exectuable из встроенного в nativ в разделе Настройки / контроль версий / git сделало трюк для меня.

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

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

устранение:

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

выберите [ OpenSSH] вместо [шпаклевка]

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