SSHはパテでは動作するが端末では動作しない

23

ターミナルでこれをSSHしようとすると： ssh username@sub.domain.com 次のようなエラーが表示されます。
Connection closed by 69.163.227.82

パテを使用すると、サーバーに接続できます。なぜこれが起こっているのでしょうか、そしてどうやってこれを端末で動作させることができますか？

ssh -v username@sub.domain.com 

OpenSSH_6.0p1 (CentrifyDC build 5.1.0-472) (CentrifyDC build 5.1.0-472), OpenSSL 0.9.8w 23 Apr 2012
debug1: Reading configuration data /etc/centrifydc/ssh/ssh_config
debug1: /etc/centrifydc/ssh/ssh_config line 52: Applying options for *
debug1: Connecting to sub.domain.com [69.163.227.82] port 22.
debug1: Connection established.
debug1: identity file /home/ryannaddy/.ssh/id_rsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_rsa-cert type -1
debug1: identity file /home/ryannaddy/.ssh/id_dsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_dsa-cert type -1
debug1: identity file /home/ryannaddy/.ssh/id_ecdsa type -1
debug1: identity file /home/ryannaddy/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
debug1: Miscellaneous failure
Cannot resolve network address for KDC in requested realm

debug1: Miscellaneous failure
Cannot resolve network address for KDC in requested realm

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Connection closed by 69.163.227.82
linux  ssh  terminal  putty 
— Get Off My Lawn
ソース
なにが ssh -v username@sub.domain.com 見せる？
— James Sneeringer
主な質問を更新しました。また、サーバーはパスワードを要求する必要があります、ログインに必要なSSHキーはありません。
— Get Off My Lawn
PuTTYの設定をデフォルトから変更しましたか？
— Kruug
また、試してみましたか user@domain.com？手放す sub。
— Kruug
1
CentrifyのOpenSSHのビルドを使用しています。これは、システムがAD統合されていることを意味します。 Active DirectoryはKerberosを使用しており、OpenSSHはKerberos KDCを見つけることができないと不平を言っているので、それは回避します。あなたのしていること /etc/krb5.conf のように見える？
— James Sneeringer

回答:

23

次のURLで解決策が見つかりました。 http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/

何が起こっているのかを説明するのにもかなり良い仕事をします。

最終的に、私は以下を/ etc / ssh / ssh_configに追加しました。 

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
HostKeyAlgorithms ssh-rsa,ssh-dss
MACs hmac-md5,hmac-sha1,hmac-ripemd160

CiphersもHostKeyAlgorithmsも独自には機能しませんでした。Macがこれを機能させるために私を最優先にしてくれましたが、私はこれを解決するのに何時間も費やすことを確信できません。これが少なくとも他の誰かに役立つことを願っています。

編集：これは（時々）問題を解決しますが、おそらくあなたが望む方法ではありません。 --jcwenger

これらの設定は（副作用として）sshクライアントがパケットを送信する方法を変更するようで、偶然に小さいパケットを送信します。これで問題は解決しません。それは時々、本当の問題（MTU断片化が愚かなファイアウォールルール実装と相互作用すること）が引き起こされないようにするだけです。

正しい解決策は、エンドツーエンドで機能するMTUを設定することです。

断片化が発生しないようにMTUを手動で小さい値に設定する必要はありません。 クリーナー （私たちユーザーとしては、私たちのネットワークチームによって引き起こされた問題に手動で対処する必要はありません）...しかし、SSHの暗号設定を台無しにするのではなく、少なくとも直接的に実際の原因を信頼でき証明方法で対処します。つまり、副作用として、星が並ぶときに、大きなパケットができないようにします。

また、大きなパケットを生成するのはSSHだけではありません。 MTUを設定すると、同じことが他のプロトコルにも発生しないようになります。

— mattw
ソース
5
おかげで、私の場合は最後の行だけ MACs hmac-md5,hmac-sha1,hmac-ripemd160 十分でした
— Tombart
私はgithub - git pull / git pushに問題がありました - 何も起こりませんでした。 ssh -T -v git@github.comを試しても同じエラーが発生しました。それを解決するためにこれを使いました。ありがとうございました！
— Jason
私は同様の問題を抱えており、この解決策を試しました。 1つの副作用はそれから知られているホストへのどんな接続もホストキー変更を非難するだろうということです。
— lfagundes
これらのパッチはすべて症状ではなく原因を治療しています。暗号サイズを小さくすることはMTUの断片化を防ぐ可能性があります...これは本当の問題です。
— jcwenger
/ etc / ssh / ssh_configに "HostKeyAlgorithms ssh-rsa、ssh-dss"という行を追加すると、ZyxelモデムにSSH接続できないという問題が修正されました。上記のtetboxの他のすべての行は、すでに私のマシン上に配置されていました。先端をありがとう！
— Jeff Wright
5

これは何らかの値をハードコードする必要なしにMTU問題を修正しました、それはsshとこれによって影響される他のどんなプロトコルのためにそれも修正するでしょう。 rootとして、次のコマンドを実行してください。 

echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing

あなたは問題と解決策についてもっと読むことができます ここに そして ここに 。

— Marwan Alsabbagh
ソース
説明： "カーネル/ procファイルシステムは、 'file' / proc / sys / net / ipv4 / tcp_mtu_probingの値を変更することで、TCP MTUプローブを有効または無効にする簡単な方法を提供します。 ; 1 =ブラックホールルーターが検出されたときに有効になり、2 =常に有効になります。
— Jorj
1

いくつか見て、次のような提案を見つけました ここに ：

/ etc / ssh / ssh_config内の次の行（NOT sshd_config）がコメントアウトされていないことを確認してください。 

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

また、そのファイルをデフォルトに戻してから再試行する、つまりアンインストールして再インストールすることもできます。 openssh-client IIRCパッケージの名前。

— LawrenceC
ソース
それはそれを修正しませんでした:(
— Get Off My Lawn
1

私はこの問題を解決することができました。 

ssh -4 username@host.xyz

私はMacを使っているので、ここでのMTU設定やその変更方法はわかりませんが、他の人がこれから恩恵を受ける可能性があると思いました。

— Bruno Kim
ソース
そのオプションはsshにIP4だけを使うよう強制します。私もMacを使っていますが、問題は解決しませんでした。
— Jorj
0

私は今日、Windows（Gitと一緒に配布されたssh）とUbuntuでこの問題を抱え始めました。

これはOpenSSHのバグのようですが、に問題があります 発射台 。

それは私のために3des-cbc暗号とUbuntuの鍵を強制的にWindows上で働いた。

— LawfulHacker
ソース
0

ちょっとネクロなのですが、OpenSSH_7.8p1、Linux上でこれに遭遇しました。 OpenSSHの最近のリリースでDSCPマーキングが導入されたことは、VMwareのNATで跳ね上がっているようです（ブリッジネットワークは、以下のリンクで問題ないと言及されました）。

以下を追加/設定することで今のところこれを回避することができます。 / etc / ssh / ssh_config ： 

IPQoS lowdelay throughput

その他の要因としては、PuTTY（または他の異なるSSHクライアント）が同じホストからの問題に遭遇していない可能性があり、これまでのところあなたのMTUがチェックアウトしています。すなわち： 

ping -M do -s 1472 your-ssh-server

これらの投稿は特に役に立ち、私が必要としている場所に私を導きました：

https://groups.google.com/forum/#!topic/opensshunixdev/5FK67SCpPg8 https://groups.google.com/forum/#!topic/opensshunixdev/uNd48nGOe7A

— Kachunkachunk
ソース
-2

ssh -c aes256-ctrは正常に動作します。

— udara
ソース
なぜあなたはこのコマンドが問題を解決すると信じていますか？
— Scott
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.