bibucket ssh_exchange_identification: 読み取りました。相手によって接続がリセットされた
bitbucketへのパスワードなしのgit接続をセットアップしようとしています。Windows Server 2008でgit bashを使っています。
HTTPS経由のクローニングは問題なく動作します。
nskoric@P8-DEV /z/test
$ git clone https://dijxtra@bitbucket.org/nek-plan/gittest.git
Cloning into 'gittest'...
Password for 'https://dijxtra@bitbucket.org':
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
Checking connectivity... done.しかし、パスワードレスログインが必要なため、HTTPSではダメなのです。そこで、秘密鍵と公開鍵のペアを生成し、公開鍵をbitbucketにアップロードして、.ssh/configでHost/IdentitiyFileを設定しました。そして、接続を試みたのですが、失敗しました。
会社のファイアウォールでは22番ポートが閉じられています。
nskoric@P8-DEV /z/test
$ ssh git@bitbucket.org -vv
OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014
debug1: Reading configuration data /u/.ssh/config
debug1: /u/.ssh/config line 1: Applying options for *bitbucket.org
debug2: ssh_connect: needpriv 0
debug1: Connecting to bitbucket.org [131.103.20.168] port 22.なので、bitbucketのドキュメントにあるように、443番ポートを使っています。
nskoric@P8-DEV /z/test
$ git clone ssh://git@altssh.bitbucket.org:443/nek-plan/gittest.git
Cloning into 'gittest'...
ssh_exchange_identification: read: Connection reset by peer
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.ググってみたところ、"bitbucket ssh_exchange_identification: read:Connection reset by peer" でググってみましたが、ダメでした :-/ それからSSH接続のデバッグをやってみましたが、これが一番遠回りでした。
nskoric@P8-DEV /z/test
$ ssh git@altssh.bitbucket.org -p 443 -vv
OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014
debug1: Reading configuration data /u/.ssh/config
debug1: /u/.ssh/config line 1: Applying options for *bitbucket.org
debug2: ssh_connect: needpriv 0
debug1: Connecting to altssh.bitbucket.org [131.103.20.174] port 443.
debug1: Connection established.
debug1: identity file /u/.ssh/bitbucketnek type 1
debug1: identity file /u/.ssh/bitbucketnek-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
ssh_exchange_identification: read: Connection reset by peerというわけで、SSH は正しい ID ファイル (/u/.ssh/bitbucketnek) を見つけて、それから死にました。今、問題が私の "bitbucketnek" 秘密鍵にあるのか、私たちの会社のファイアウォールに問題があるのか、あるいは第3の何かにあるのかを理解することができれば、本当に助かるのですが...。何かアイデアはありますか？
ありがとうございます。
5
3
参考になる注釈として、私はこのケースを共有ホスティング環境、具体的にはGoDaddyで経験しましたが、その理由はIt gave me this error:
解決策：私のローカルマシン'のipはGoDaddyによってブロックされていたので、私は彼らのサポートに連絡し、実行中のエラー出力のスクリーンショットを送信しなければなりませんでした。
ssh -v user@domainを実行したときのエラー出力のスクリーンショットを送ってください。
を実行したときのエラー出力のスクリーンショットを送って、私のIPアドレスも伝えました。サポートは、私のIPが実際にブロックされていることに気付き、それを削除し、問題は解決しました。
ssh_exchange_identification" は、クライアントとサーバーがソフトウェアのバージョン文字列を交換するフェーズで発生したことを意味します。これは、クライアントとサーバーがホスト鍵を交換する前、あるいは認証を試みる前に起こります。 言い換えれば、鍵の交換や認証が行われる前に、リモート側の接続が切断されているのです。
異常終了（コネクションリセット）は、通常、サーバープロセスが接続を閉じずに終了したか、クラッシュしたか、ファイアウォールやロードバランサーなどの何かが接続を妨害していることを示します。通常、私はサーバー上でトラブルシューティングを行うことをお勧めします。しかし、これがbitbucketであることを考えると、おそらく彼らのサーバーが正しく動作しているという仮定で始めるのが安全でしょう。考えられる代替案は、あなたのトラフィックがステートフルファイアウォール、ロードバランサー、またはネットワーク内の同様のデバイスを経由しており、それが何らかの理由でTCPストリームを強制的に閉じていることです。
あなたはポート443でSSHを実行しようとしているようですが、おそらくこれらの指示に従っているのでしょう。もしかしたら、あなたのネットワークエンジニアは、インターネットへのポート22をブロックしているかもしれませんね？もしかしたら、彼らは443番ポートのパケット検査も行っていて、HTTPS（HTTP over SSL）のように見えないトラフィックをブロックしているのかもしれません。
20ほどのプロジェクトのアップデートをスクリプトで次々に取得しようとしたときに、この現象が発生しました。 私は、何らかの制限に遭遇したのだと思います。 各プルの後に 'sleep 10' を追加すると、問題が解決したようです。