Git Remote：エラー：致命的：プロトコルエラー：行の長さが正しくない文字：Unab
Gitサーバーをセットアップし、クライアントから最初にレポをプッシュしたいと思います。 git Push Origin masterを使用すると、次のエラーメッセージが表示されます。
fatal: protocol error: bad line length character: Unab
何が悪いのか分かりません。 「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がPuTTYのplink.exeのパスに設定されています。
考えられる問題と解決策：
plink.exeへのパスが正しいことを確認してください。 Unixスタイルのパスも正常に機能します。たとえば、/c/work/tools/PuTTY/plink.exe- PuTTYのキーエージェント（
pageant.exe）が実行されていることを確認してください - キーエージェントに、サーバーにアクセスするための有効なキーが含まれていることを確認してください
サーバーの.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
WindowsにGITをインストールした後、同じような問題が発生しました。最初はうまくいきました。その後、1日後（PCの再起動後）、それはもうありませんでした。
$ git pull
fatal: protocol error: bad line length character: git@
問題は、再起動後、自動的に開始されたPuTTY "pageant.exe"で秘密キーがアクティブにならないことでした。ページェントにキーを追加する場合、デフォルトでは永続的な設定ではありません。キーを再度追加するだけで、うまくいきました。そのため、ここで説明するように、pagenantにキーを自動的にロードさせる必要があります。
GitExtensionユーザーの場合：
Gitを2.19.0にアップグレードした後、同じ問題に直面しました
解決：
ツール>設定> Git拡張機能> SSH
[PuTTY]ではなく[OpenSSH]を選択します
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
私の解決策には、以下の手順が含まれます。
- SSHキー（公開）がEC2インスタンスで追加/更新されていることを確認します。
- 認証エージェント（私の場合はPageant = PuTTY Authentication Agent）が実行されており、対応する秘密鍵がロードされていることを確認してください。
Git cloneの公開キーにEC2 SSHキーIDを使用します。例：
git clone ssh：// {SSH Key ID}@someaccount.amazonaws.com/v1/repos/repo1
私の場合、フェッチ後はfatal: protocol error: bad line length character: Passと記述されていました。また、プッシュ後、fatal: protocol error: bad line length character: git@ Doneを取得しました。
Windowsの再起動後、「PuTTYエージェント」（pageant.exe）を再度起動し、キーのリストから消えた秘密キーを追加する必要がありました。
私にとっては、最近追加したためです
RequestTTY force
.ssh/configに
これをコメントアウトすると、機能するようになりました
「エコー」ステートメントについては、リモートマシンへの接続に使用されるアカウントのスタートアップファイルを確認してください。 Bashシェルの場合、これらは.bashrcや.bash_profileなどになります。EdwardThomsonの答えは正しいのですが、私が経験した特定の問題は、ssh経由でサーバーにログインしたときにボイラープレートの印刷がある場合です。 Gitはその定型文の最初の4バイトを取得し、このエラーを発生させます。この特定のケースでは、「Unab」は実際には「Unable ...」という作業であると推測します。これはおそらく、Gitホストに何か他の問題があることを示しています。
私の場合、問題は32ビットのPuTTYとpageant.exeでした。64ビットのTortoisePlink.exeとは通信できません。 32ビットPuTTYを64ビットバージョンに置き換えると、問題は解決しました。
同じエラーが発生しました"fatal: protocol error: bad line length character: shmi"ここで、shmiは私の場合のユーザー名です。 "Git Extensions->Settings->SSH"でSSHをPuTTYからOpenSSHに切り替えました。助けた。
私も時々そのエラーに遭遇しますが、そうなった場合、私のブランチが最新ではないことを意味するので、git pull Origin <current_branch>をしなければなりません
私にとっては、同じホストの詳細を秘密キー（Puttygenで変換）でPuTTYに追加しました。その後のgit bashコマンドには問題がありませんでした。
参考までに、CentOS6コンテナーをCentOS7にアップグレードした後、これと同じエラーメッセージが表示されました。
# git remote show Origin
fatal: protocol error: bad line length character: Inva
Sshを実行すると、検索できるエラーが表示されました。
# ssh [email protected]
Invalid clock_id for clock_gettime: 7
https://github.com/wolfcw/libfaketime/issues/6 に至りました。親DockerfileにLD_PRELOAD=/usr/local/lib/faketime/libfaketime.so.1があることを忘れていたことがわかりました。コメントアウトするとエラーが修正されました。
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に秘密鍵を提供する方法について少し苦労しました。 https://serverfault.com/questions/194567/how-do-i-tell-git-for-windows-where-to-find-my-private-rsa-key/382801#のDan McClainの回答382801 それについて説明します。彼の答えに加えて、私の場合、秘密鍵ファイルの名前はid_rsa.pubであると予想されていました。
AWS EC2インスタンスにあるプロジェクトを複製しようとすると、次のエラーが表示されました。
Cloning into 'AWSbareRepo'...
fatal: protocol error: bad line length character: Plea
これは、EC2-USERの代わりにrootとしてsshを試みたために発生しました。 git cloneを実行せずに実際にsshを実行した場合、「ec2-userでログインしてください」という行に沿って何かエラーメッセージが表示されます。
Christer Fernstromと同じ問題がありました。私の場合、それは.bashrcに入れたメッセージであり、数日後にバックアップを行っていないときにバックアップを行うことを思い出させます。
PuTTYを使用する場合。次に、Pageantを実行し、秘密キーがPageantにロードされていることを確認します（マウスをタスクバーのPageantアイコンで右クリックし、ポップアップメニューの[キーの表示]をクリックします）。
それ以外の場合は、cmd.exeで行うと：
git clone ssh://name@Host:/path/to/git/repo.git
「致命的：プロトコルエラー：行の長さが正しくない文字：」というメッセージが表示されます
ここで遅い答えですが、それが誰かを助けることを願っています。プロトコルエラーの場合、ローカルgitがリモートgitと通信できない状態で何かを行う必要があります。これは、sshを介してリポジトリを複製し、後でリポジトリのキーを紛失した場合、またはsshエージェントがそれらのキーを見つけられなくなった場合に発生する可能性があります。
解決
新しいキーを生成してgitリポジトリに追加するか、他の誰かとではなくキーを持っている場合はキーをロードするようにsshエージェントを設定します;）
もう1つの簡単な修正方法は、
.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/*
TL; DR： DonotWindowsの場合、リモートURLでusername@を省略します。
デフォルトのsshを使用するLinuxおよびWindowsでは、次のようにリモートURLからユーザー名を省略できます。
git clone server-name:/srv/git/repo-name
Sshのデフォルトの動作は、現在ログインしているユーザー名を使用することです。 Windowsでpageantにロードされたキーを使用できるようにplink.exeを使用するようにgitを設定している場合、plinkにはないため、これは機能しません。ユーザー名の入力を促すため、これらの不可解なエラーメッセージが表示される同じ自動ユーザー名の動作：
$ plink server-name
login as: _
対：
$ plink username@server-name
...logs you in...
すでにリポジトリをクローンしている場合は、.git/configをリモートURLに追加することで、username@のリモートを修正できます。
変換後のエラー：致命的：プロトコルエラー：行の長さが正しくない文字：ファタ
git-upload-packの場所をシステムパスに追加した後。
問題はリポジトリ名の周りに追加されたアポストロフィのようです：gitクライアントによって追加されたProcess Monitor（sys internalsから）のようなツールを探します。これはgit固有のWindowsの問題のようです。
サーバーのプロンプトで同じコマンドラインを試しました：完全なエラーは「致命的：特定のリポジトリ（または親ディレクトリ）：.git」ではありませんでした
結論として、私にはソフトウェアのバグのように思えます。私はgitの専門家ではありません。gitを使用するのは初めてで、Subversionとperforceから来ています。
gitプロジェクトへのhttpリンクをいつでも保持できます。 sshリンクの代わりにそれを使用できます。これはあなたが持っているオプションです
Settings/version control/gitでssh実行可能ファイルをビルトインからnativに変更すると、私にとってはうまくいきました。
マシン上のセキュリティアクセスの可能性があります。Pageant（PuTTYエージェント）を実行していますか？
私たちもこれに遭遇しました。
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
何がうまくいかなかったかについての詳細はわかりませんが、今回のケースでは、サーバー上のディスクがいっぱいだったことが原因でした。
まあ、私はこれと同じ問題を抱えていました（Windows 7）。パスワードでレポを取得してください。 Git Bash + Plink（環境変数GIT_SSH）+ Pageantを使用します。 GIT_SSH（一時）を削除すると役立ちます。なぜパスによるログインとRSAによるログインを同時に使用できないのかわかりません...