sshセッションが遅くなる原因は何ですか？[閉まっている]

リモートホストでsshを実行しますが、端末のパフォーマンスが低下します。入力中の記号はすぐには表示されませんが、少し遅れて表示されます。遅延後、一度に2つのシンボルが表示される場合があります。

高い遅延は、sshのパフォーマンスが低下するもう1つの原因です。tracerouteの代わりとしてmtrを使用することを強くお勧めします。ネットワークの問題が発生する可能性のある場所を知ることができるはずです。

不要な場合はX11転送を無効にし（ssh -x）、圧縮を有効にすると（ssh -C）、セッションを高速化することもできます。

次の2つの原因が考えられます。

1. 接続でのパケット損失
2. サーバーの高負荷。

すぐに端末が正常であることを発見して、ネットワークパフォーマンスを測定しようとしました。何が起きたの？

2つのインターネットチャネルルーター間で負荷分散が行われています。時々sshトラフィックをwan1とwan2にルーティングします。私は、たった1つのチャネルに何か問題があると提案しました。そこで、2つのチャネルのmtr（すばらしいツール！）を使用してネットワークパフォーマンスを個別に測定しました。

うん！wan2には110ミリ秒で21ホップ、wan1には21ミリ秒で15ホップがあります！wan2の遅延が問題です。

9のCompressionとCompressionLevelを使用します。これは少し役立ちます。これらのパラメーターは、/ etc / ssh / ssh_configで構成できます。しかし、実際のネットワークが非常に悪い場合、このトリックはあまり効果がありません。

この動作の最も明らかな原因は、飽和しているリンクまたはパケットをドロップしているリンクです。ワークステーションからsshを実行するマシンまでのホップ数はいくつですか？該当する場合、トレースルートを分析しましたか？

長脂肪パイプ（高帯域幅+高遅延）でOpenSSHを使用している場合、OpenSSHがより大きなtcpウィンドウサイズを使用するようにする修正が含まれているため、両側で少なくともバージョン4.7を使用していることを確認してください。

 * The SSH channel window size has been increased, and both ssh(1)
   sshd(8) now send window updates more aggressively. These improves
   performance on high-BDP (Bandwidth Delay Product) networks.

接続を最大限に活用したい場合、これは重要です。そうしないと、送信者は送信を続ける前に確認応答を待たなければならない場合があります。

すでに他の人が言ったように、それは待ち時間、ネットワークの損失、サーバーの低速から来る可能性があります。
最近のTCPスタックではNaggleというアルゴリズムが使用されているため、1つのタイプで2文字が表示される場合があります。

接続を制限するSSHブルートフォースの試みである可能性もあります。セッションの実行が遅くなるたびにログをチェックしますが、多くの場合、誰かが狂ったようなパスワードを試しています。

DNSの構成を誤ると、これが発生する可能性があります。サーバーはログインすると問題なく応答し、ファイルのアップロードとダウンロードはかなり速くなりますが、SSHログインは遅くなります。

確認する1つのことは、単にサーバーメモリです。256Mbのメモリを搭載したUbuntu VMを実行していましたが、SSHは本当に遅くなりました。これを512Mbに倍増することで問題を解決しました。