Git Remote: Помилка: фатальна: помилка протоколу: символ неправильної довжини рядка: Unab

Я налаштував git-сервер і хочу зараз відштовхнути своє репо від клієнта. Я використав git push origin masterта отримав це повідомлення про помилку:

fatal: protocol error: bad line length character: Unab

Я не знаю, що не так. Я не знаю, що таке "Унаб". Я спробував змінити розмір оболонки, але це все ще "Unab". Я не можу знайти рішення для цього повідомлення про помилку.

Я налаштовую сервер за допомогою "санкціонованих_ ключів" та SSH. (Я можу підключитися до нього за допомогою SSH.)

Здається, це проблема з git?

BTW: Сервер налаштований у вікні Windows 7

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

У протоколі Git перші чотири байти повинні бути довжиною рядка. Натомість вони були персонажами Unab... що, мабуть, є початком якогось повідомлення про помилку. (тобто, ймовірно, " Unable to..." щось робити).

Що відбувається, коли ти біжиш ssh <host> git-receive-pack <path-to-git-repository>? Ви повинні побачити повідомлення про помилку, на якому ваш клієнт git перешкоджає, і ви, можливо, зможете його виправити.

У мене була подібна проблема, але точне повідомлення про помилку було:

фатально: помилка протоколу: символ неправильної довжини рядка: Усін

Це в Windows, з GIT_SSHналаштованим на шлях plink.exePuTTY.

Можливі проблеми та рішення:

• Переконайтесь, що шлях до 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" більше не активував приватний ключ. Коли ви додаєте ключ у конкурсі, за замовчуванням це не постійне налаштування. Мені просто довелося знову додати ключ, і він справно працював. Отже, для цього випадку потрібно змусити автоматично завантажувати сторінку, як описано тут:

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 ця проблема буде вирішена.

Ви можете перенаправити будь-який вихід з .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-агент запускався і доданий створений ключ ( посилання github ).

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

Це може комусь допомогти. Коли я намагався клонувати проект із екземпляра EC2, я отримував помилку нижче:

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

Роздільна здатність для мене включає наступні етапи:

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

3. Використовуйте ідентифікатор ключа EC2 SSH для відкритого ключа для клонування git. Приклад:

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

Для мене це було, бо я нещодавно додав

RequestTTY force

в .ssh / config

коментуючи це, це дозволило йому працювати

Перевірте свої файли запуску в обліковому записі, який використовується для підключення до віддаленої машини, на наявність викликів "echo". Для оболонки 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) знову і додати приватний ключ, який зник зі списку ключів.

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/isissue/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 / санкціонованих_keys або ~ / .ssh / санкціонованих_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-адреси.

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

Помилка, трансформована у: фатальна: помилка протоколу: символ неправильної довжини рядка: фата

після додавання місця розташування git-upload-pack до системного шляху.

Проблема, мабуть, полягає в апострофі, що додається навколо назви сховища: Погляд за допомогою інструмента, як Process Monitor (від sys Internals), який додав клієнт git. Здається, це проблема специфічної для Windows.

Я спробував той самий командний рядок у підказці сервера: повна помилка була "фатальною: не заданий сховище (або будь-який з батьківських каталогів): .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 repo або налаштуйте агента 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 exectuable з вбудованого на nativ у налаштуваннях / контролі версій / git зробило для мене трюк.