git - Git Remote：エラー：致命的：プロトコルエラー：行の長さが正しくありません：Unab

Question

gitサーバーをセットアップし、最初にクライアントからリポジトリをプッシュしたいと思います。git push origin master私はこのエラーメッセージを使用して受け取りました：

fatal: protocol error: bad line length character: Unab

何が悪いのかわかりません。「ウナブ」って何なのかわかりません。シェルのサイズを変更しようとしましたが、まだ「Unab」です。このエラーメッセージの解決策が見つかりません。

「authorized_keys」とSSHを使用してサーバーをセットアップしました。（SSHを使用して接続できます。）

gitの問題のようですか？

ところで：サーバーはWindows7VMでセットアップされています

score 127 · Accepted Answer

This error message is a bit obtuse, but what it's actually trying to tell you is that the remote server didn't reply with a proper git response. Ultimately, there was a problem on the server running the git-receive-pack process.

In the Git protocol, the first four bytes should be the line length. Instead, they were the characters Unab... which is probably the beginning an error message of some kind. (ie, it's probably "Unable to..." do something).

What happens when you run ssh <host> git-receive-pack <path-to-git-repository>? You should see the error message that your git client is barfing on and you may be able to correct it.

score 68 · Accepted Answer

同様の問題が発生しましたが、正確なエラーメッセージは次のとおりです。

致命的：プロトコルエラー：不正な行長文字：Usin

これはWindowsにあり、PuTTYGIT_SSHのパスに設定されています。plink.exe

考えられる問題と解決策：

へのパスplink.exeが正しいことを確認してください。たとえば、Unixスタイルのパスも正常に機能します/c/work/tools/PuTTY/plink.exe
PuTTY（pageant.exe）のキーエージェントが実行されていることを確認します
キーエージェントにサーバーにアクセスするための有効なキーが含まれていることを確認してください

score 36 · Accepted Answer

GitExtensionユーザーの場合：

gitを2.19.0にアップグレードした後、同じ問題に直面しました

解決：

ツール>設定>Git拡張機能>SSH

[ PuTTY ]の代わりに[ OpenSSH ]を選択します。

score 25 · Accepted Answer

WindowsにGITをインストールした後も、同じような問題が発生しました。最初はうまくいきました。その後、1日後（PCの再起動後）、それはもうありませんでした、そして私はこれを手に入れました：

$ 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

score 18 · Accepted Answer

サーバーの.bashrcに、出力を生成するステートメントがあるかもしれません。たとえば、私はこれを持っていました：

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"
rvm use ruby-1.9.3-p194@rails32

この場合、rvm useからの出力は、（誤って）gitからのものとして解釈されます。したがって、次のように置き換えます。

rvm use ruby-1.9.3-p194@rails32 > /dev/null

score 12 · Accepted Answer

12

Git ExtensionsにSSH秘密鍵をロードすると、この問題は解決されます。

于 2015-12-16T15:32:51.313 に答える

score 10 · Accepted Answer

.bashrcからの出力をリダイレクトできますstderr：

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

gitはこの記号を無視します

score 7 · Accepted Answer

GitBashを使用しているWindowsでも同様の問題が発生しました。git cloneを実行しようとすると、このエラーが発生し続けました。リポジトリは、GitLabがインストールされたLinuxボックス上にありました。

git clone git@servername:path/to/repo
fatal: protocol error: bad line length character: git@

sshキーが生成されたことを確認しました。公開鍵がGitLabに追加されました。ssh-agentが実行され、生成されたキーが追加されました（github link）。

オプションが足りなくなった後、最後にGit Bashを閉じて、[管理者として実行]を右クリックしてもう一度開いてみました。その後働いた。

score 6 · Accepted Answer

私にとっては、最近追加したからです

RequestTTY force

.ssh/configに

これをコメントアウトすると、機能するようになりました

score 5 · Accepted Answer

これは誰かを助けるかもしれません。EC2インスタンスからプロジェクトのクローンを作成しようとすると、次のエラーが発生しました。

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

私の解決策には、以下の手順が含まれます。

SSHキー（パブリック）がEC2インスタンスで追加/更新されていることを確認します。
認証エージェント（私の場合はそのPageant = Putty Authentication Agent）が実行されており、対応する秘密鍵がロードされていることを確認します。
gitcloneの公開鍵にはEC2SSH鍵IDを使用します。例：

git clone ssh：//{SSHキーID}@someaccount.amazonaws.com/v1/repos/repo1

score 4 · Accepted Answer

私の場合、フェッチ後に次のように記述されfatal: protocol error: bad line length character: Passました。また、プッシュした後、私は得ました：fatal: protocol error: bad line length character: git@ Done。

Windowsを再起動した後、「PuTTYエージェント」（pageant.exe）を再度起動し、キーのリストから消えた秘密キーを追加する必要がありました。

score 4 · Accepted Answer

パテを使用する場合。次に、Pageantが実行されていることと、秘密鍵がPageantにロードされていることを確認します（マウスでタスクバーのPageantアイコンを右クリックし、ポップアップメニューの[キーの表示]をクリックします）。

それ以外の場合は、cmd.exeで実行します。

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

このメッセージが表示されます「致命的：プロトコルエラー：行の長さが正しくありません：」

score 3 · Accepted Answer

リモートマシンへの接続に使用したアカウントのスタートアップファイルで「echo」ステートメントを確認してください。Bashシェルの場合、これらは.bashrcや.bash_profileなどになります。EdwardThomsonの答えは正しいですが、私が経験した特定の問題は、ssh経由でサーバーにログインしたときに定型文が印刷される場合です。Gitはそのボイラープレートの最初の4バイトを取得し、このエラーを発生させます。この特定のケースでは、「Unab」は実際には「Unable ...」という作品であると推測します。これは、Gitホストに何か問題があることを示している可能性があります。

score 3 · Accepted Answer

TL; DR： Windowsの場合は、リモートURLを省略しないでください。username@

Linuxおよびデフォルトのsshを使用するWindowsでは、次のようにリモートURLからユーザー名を省略できます。

git clone server-name:/srv/git/repo-name

sshのデフォルトの動作は、現在ログインしているユーザー名を使用するためです。plink.exeWindowsを使用していて、にロードされたキーを使用できるようにgitを設定している場合pageant、これはplink機能しません。これと同じ自動ユーザー名の動作がないため、これらの不可解なエラーメッセージが表示されます。ユーザー名の入力を求める：

$ plink server-name
login as: _

対：

$ plink username@server-name
...logs you in...

すでにリポジトリのクローンを作成している場合は、リモートURLにを.git/config追加することで、のリモートを修正できます。username@

score 2 · Accepted Answer

私も時々そのエラーに遭遇します、しかしそれが起こったとき、それは私のブランチが最新ではないことを意味するので私はしなければなりませんgit pull origin <current_branch>

score 2 · Accepted Answer

参考までに、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/63LD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1に導き、そこで私は親Dockerfileにあることを忘れていたことに気づきました。コメントアウトするとエラーが修正されました。

score 2 · Accepted Answer

私の場合、問題は32ビットのPuttyとpageant.exeでした。64ビットのTortoisePlink.exeと通信できません。32ビットのPuttyを64ビットバージョンに置き換えると、問題が解決しました。

score 2 · Accepted Answer

同じエラーが発生しました。私の場合"fatal: protocol error: bad line length character: shmi" 、shmiはユーザー名です。でSSHをPuTTYからOpenSSHに切り替えました"Git Extensions->Settings->SSH"。助かりました。

score 1 · Accepted Answer

ChristerFernstromと同じ問題がありました。私の場合、それは私が.bashrcに入れたメッセージであり、数日以内にバックアップを実行していないときにバックアップを実行することを思い出させます。

score 1 · Accepted Answer

以下は誰かを助けるかもしれません：AWS EC2インスタンスにあるプロジェクトのクローンを作成しようとすると、次のエラーが発生しました：

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

これは、EC2-USERではなくrootとしてsshを実行しようとしたことが原因でした。git cloneを実行せずに実際にsshを実行すると、「ec2-userでログインしてください」という行に沿ってエラーメッセージが表示されます。ec2-userとしてgit cloneを実行すると、問題ありませんでした。

score 1 · Accepted Answer

秘密鍵認証も設定されていない場合、 Gitはパスワードの入力を求めず、同様の不可解なメッセージ「致命的：プロトコルエラー：行の長さが正しくありません：ユーザー」で失敗します。

https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-serverは、サーバーで公開鍵を指定する方法を示しています。基本的に、公開鍵を〜/ .ssh / authorized_keysまたは〜/ .ssh/authorized_keys2に追加します

WindowsマシンのGitBashに秘密鍵を提供する方法について少し苦労しなければなりませんでした。https://serverfault.com/questions/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801のDanMcClainの回答はそれを説明しています。彼の答えに加えて、私の場合、秘密鍵ファイルの名前はid_rsa.pubであると予想されていました。

score 1 · Accepted Answer

私にとっては、秘密鍵（puttygenで変換）を使用して同じホストの詳細をPuttyに追加することができました。その後のgitbashコマンドには問題はありませんでした。

score 0 · Accepted Answer

0

サーバーでシェルアクセスが許可されているかどうかを確認します。

于 2012-01-27T18:54:10.057 に答える

score 0 · Accepted Answer

エラーは次のように変換されました：致命的：プロトコルエラー：行の長さが正しくありません文字：fata

git-upload-packの場所をシステムパスに追加した後。

問題は、リポジトリ名の周りに追加されたアポストロフィのようです。gitクライアントによって追加されたProcess Monitor（sys internalsから）のようなツールで探しています。これは、Git固有のWindowsの問題のようです。

サーバーのプロンプトで同じコマンドラインを試しました。完全なエラーは「致命的：特定のリポジトリ（または親ディレクトリ）ではありません：.git」でした。

結論として、私にはそれはソフトウェアのバグのように思えます。私はgitの専門家ではないことに注意してください。初めてgitを使用します。私は、subversionとperforceから来ています。

score 0 · Accepted Answer

私たちもこれに遭遇しました。

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

何がうまくいかなかったのかについての詳細はわかりませんが、私たちの場合、サーバー上のディスクがいっぱいになったことが原因でした。

score 0 · Accepted Answer

マシンのセキュリティアクセスである可能性があります。Pageant（パテエージェント）を実行していますか？

score 0 · Accepted Answer

gitプロジェクトへのhttpリンクはいつでも持つことができます。sshリンクの代わりにそれを使用できます。これはあなたが持っている単なるオプションです

score 0 · Accepted Answer

まあ、私はこれと同じ問題を抱えていました（Windows7）。パスワードでリポジトリを取得してみてください。私はGitBash+ Plink（環境変数GIT_SSH）+Pageantを使用しています。GIT_SSH（一時的）を削除すると役に立ちます。パスによるログインとRSAでのログインを同時に使用できない理由がわかりません...

score 0 · Accepted Answer

ここで遅い答えですが、それが誰かを助けることを願っています。プロトコルエラーの場合は、ローカルgitがリモートgitと通信できない状態で何かを行う必要があります。これは、sshを介してリポジトリのクローンを作成し、しばらくしてからリポジトリのキーを紛失したか、sshエージェントがそれらのキーを見つけられなくなった場合に発生する可能性があります。

解決

新しいキーを生成してgitリポジトリに追加するか、他の誰かと一緒ではなく自分と一緒にキーを持っている場合は、キーをロードするようにsshエージェントを構成します;）
もう1つの簡単な修正方法は、ディレクトリに移動してファイルのfromからto.gitを編集し、sshキーを押す必要がないようにすることです。これにより、ユーザー名とパスワードの要求に戻ります。config[remote "origin"] urlgithttp
```
[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/*

score 0 · Accepted Answer

settings / version control /gitでsshexectuableを組み込みからnativに変更することで、うまくいきました。

score 0 · Accepted Answer

gitpullをしたときに同じ問題がありました

git pull fatal：プロトコルエラー：不正な行長文字：<htm fatal：リモートエンドが予期せずハングアップしました

リモートURLHTTPをSSHに変更しましたが、うまくいきました。

git remote set-url origin " HTTP " to " SSH "

score 0 · Accepted Answer

私の場合、この問題は変更されたによって引き起こされ/bin/sshます。私は他の人と一緒にサーバーで作業していますが、デフォルト/bin/sshはどういうわけか変更されており、起動時に意図しないログを出力します。/bin/sshを正しい実行可能ファイルに復元して解決しました。

score 0 · Accepted Answer

いくつかの同様の問題がありましたが、git fatal：プロトコルエラー：行の長さが正しくありません：Cannと私はすべてのplink.exe依存関係を取り除くまで（インストーラーを介してPuttyをchocoインストールしました）、次の行を削除するまでそれを取り除くことができませんでした.gitconfigファイルsshCommand = plink -batch。

score -2 · Accepted Answer

-2

私の場合、基本的にはWindowsを再起動する必要がありました。

于 2019-09-19T07:21:09.860 に答える

git - Git Remote：エラー：致命的：プロトコルエラー：行の長さが正しくありません：Unab

34 に答える 34

Related

Reference