web-dev-qa-db-ja.com

SSHはPuTTYでは機能しますが、ターミナルでは機能しません

端末でこれをsshしようとすると：ssh [email protected]次のエラーが発生します。
Connection closed by 69.163.227.82

PuTTYを使用すると、サーバーに接続できます。なぜこれが起こっているのですか？これをターミナルでどのように機能させることができますか？

ssh -vユーザー名@ 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
linuxsshterminalputty
24
Get Off My Lawn

次の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を手動で小さい数に設定する必要はありませんcleaner（ユーザーがネットワークによって引き起こされる問題に対処するために手動で手順を実行する必要はないため）チーム）...しかし、それは、副作用として、星が整列したときに偶然にそれを引き起こさない方法でSSHの暗号設定を台無しにするのではなく、少なくとも実際の原因を信頼できる証明可能な方法で直接処理しています大きなパケットを作る。

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

24
mattw

これは私のために働いた...

ifconfig eth0 mtu 576

http://fred-web.blogspot.com.au/2012/10/ssh-hang-on-expecting.html

8
jagguli

これにより、いくつかの値をハードコードする必要なしにMTUの問題が修正されました。これにより、sshおよびその他のプロトコルの影響が修正されます。 rootとして以下を実行します。

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

問題と解決策についての詳細は here および here を参照してください。

6
Marwan Alsabbagh

探していて、次の提案を見つけました here ：

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

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

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

1
LawrenceC

それを解決するために、ネットワークインターフェイスMTUを変更します。これは、ubuntu 14.04のバグです。

これは私のために働きました：

Sudo ip li set mtu 1200 dev wlan0

または：

Sudo ifconfig wlan0 mtu 1200

sshがVPNホストへの接続に失敗する-「SSH2_MSG_KEX_ECDH_REPLYを予期しています」でハングする

1
shgnInc

私はIPv4を強制的に使用することでこの問題を解決できました

ssh -4 [email protected]

私はMacを使用しているので、ここでのMTU設定とは何なのか、またはどのように変更するのかはわかりませんが、他の人がこれから恩恵を受ける可能性があると思いました。

1
Bruno Kim

ここでは少しネクロですが、LinuxのOpenSSH_7.8p1でこれに遭遇しました。 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/5FK67SCpPg8https://groups.google.com/forum/#!topic/opensshunixdev/uNd48nGOe7A

0
Kachunkachunk

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

OpenSSHのバグのようです。 LauchPad に問題があります。

Windowsでは3des-cbc暗号とUbuntuではキーを強制しました。

0
LawfulHacker