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

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

fatal: ошибка протокола: плохая длина строки символ: Usin

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

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

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

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

У меня была такая же проблема после установки 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 это будет вашим .bashrc и и .файл и т. д. Эдвард Томсон прав в своем ответе, но конкретная проблема, которую я испытал,-это когда есть распечатка котельной плиты при входе на сервер через ssh. Git получит первые четыре байта этой котельной плиты и поднимет эту ошибку. Теперь в этом конкретном случае я собираюсь догадаться, что" Unab " на самом деле является работой "Неспособный..."что, вероятно, указывает на то, что на хосте Git что-то не так.

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

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

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

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

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

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

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

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

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

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

Это было вызвано попыткой ssh как root вместо EC2-USER. если вы на самом деле ssh, не делая клон git... вы увидите ошибку msg в чем-то вроде "пожалуйста, войдите в систему с 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-битную версию решила проблему.

для меня добавление тех же деталей хоста в шпатлевку с закрытым ключом (преобразование с помощью 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 из builtin в nativ в разделе Настройки / контроль версий/git сделало трюк для меня.

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

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

устранение:

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

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

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