Gitリモート：エラー：致命的：プロトコルエラー：無効な行長文字：Unab

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

fatal: protocol error: bad line length character: Unab

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

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

gitの問題のようですか？

ところで、サーバーはWindows 7 VMで設定されています

このエラーメッセージは少しあいまいですが、実際に伝えようとしているのは、リモートサーバーが適切なgit応答で応答しなかったことです。最終的に、git-receive-packプロセスを実行しているサーバーに問題が発生しました。

Gitプロトコルでは、最初の4バイトは行の長さでなければなりません。代わりに、それらは文字でしたUnab...おそらく、何らかのエラーメッセージの始まりです。（つまり、それはおそらく " Unable to..."何かをすることです）。

実行するとどうなりますssh <host> git-receive-pack <path-to-git-repository>か？gitクライアントがエラーを起こしているというエラーメッセージが表示され、修正できる場合があります。

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

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

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

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

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

GitExtensionユーザーの場合：

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

解決：

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

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

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

$ 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 useからの出力は、（間違って）gitからのものとして解釈されます。だからそれを次のように置き換えてください：

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

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

あなたはから任意の出力をリダイレクトすることができます.bashrcしますstderr：

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

gitはこのシンボルを無視します

Git Bashを使用している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を閉じて、[管理者として実行]を右クリックして再度開きました。その後働いた。

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

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

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

1. SSHキー（公開）がEC2インスタンスに追加/更新されていることを確認します。
2. 認証エージェント（私の場合はPageant = Putty Authentication Agent）が実行されており、対応する秘密鍵がロードされていることを確認します。

3. git cloneの公開鍵にはEC2 SSH鍵IDを使用します。例：

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

最近追加したので私にとっては

RequestTTY force

.ssh / configに

これをコメントアウトすると機能しました

リモートマシンへの接続に使用するアカウントの起動ファイルで「エコー」ステートメントを確認します。Bashシェルの場合、これらは.bashrcや.bash_profileなどになります。エドワードトムソンの答えは正しいですが、sshを介してサーバーにログインしたときにボイラープレートが印刷されるという問題が発生しました。Gitはそのボイラープレートの最初の4バイトを取得し、このエラーを発生させます。ここで、この特定のケースでは、「Unab」は実際には「Unable ...」という作業であると推測します。これは、おそらくGitホストに何か他の問題があることを示しています。

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

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

ちなみに、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ビットのパテと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

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

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

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マシンでGit Bashに秘密鍵を提供する方法について少し苦労しなければなりませんでした。/server/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#382801でのDan McClainの回答がそれを説明しています。彼の答えに加えて、私の場合、秘密鍵ファイルはid_rsa.pubという名前であると予想されていました

私にとっては、プライベートキーを使用して同じホストの詳細をPuttyに追加（puttygenで変換）できました。その後のgit bashコマンドは問題ありませんでした。

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

それ以外の場合は、cmd.exeで次のようにします。

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

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

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

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

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

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

$ plink server-name
login as: _

対：

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

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

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

変換されたエラー：致命的：プロトコルエラー：無効な行長文字：ファタ

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

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

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

結論として、私にはソフトウェアのバグのように思えます。私はgitのエキスパートではないことに注意してください。初めてgitを使用するのは、subversionとperforceの出身です。

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

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（これはパテエージェントです）を実行していますか？

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

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

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

解決

1. 新しいキーを生成し、それをgitリポジトリに追加するか、他の誰かと一緒にではなく、キーをまだ持っている場合は、キーをロードするようにsshエージェントを設定します;）

2. 別の簡単な修正は、.gitディレクトリに移動してconfigファイルの[remote "origin"] urlfrom gitをtoに編集することです。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/*

settings / version control / gitで、実行可能なsshを組み込みからnativに変更すると、うまくいきました。