SSHログインが遅いのはなぜですか？
SSHログインが遅れる具体的には、瞬間的な遅延から数秒の遅延までの範囲が2つあります。
- Sshコマンドを発行してからログインプロンプトを表示するまで
- パスフレーズの入力とシェルのロードの間
今、具体的に私はここだけでSSHの詳細を見ている。明らかに、ネットワークの待ち時間、関係するハードウェアとOSの速度、複雑なログインスクリプトなどが遅延の原因となる可能性があります。私はクライアントシステムとしてUbuntu、CentOS、そしてMacOS Xを主に使っています。ほとんどの場合、sshサーバーの設定はOSのデフォルト設定から変更されていません。
どのSSHサーバ設定に興味がありますか？調整できるOS /カーネルパラメータはありますか？ログインシェルトリック？等？
/etc/sshd_configまたは/etc/ssh/sshd_configでUseDNSをnoに設定してみてください。
同じような遅いパフォーマンスのサーバーでssh -vvvを実行したとき、ここでハングアップが見られました。
debug1: Next authentication method: gssapi-with-mic
/etc/ssh/ssh_configを編集してその認証方法をコメントアウトすることで、ログインのパフォーマンスが通常に戻りました。これがサーバー上の/etc/ssh/ssh_configにあるものです。
GSSAPIAuthentication no
これをサーバー上でグローバルに設定できるので、GSSAPIを認証に使用することはできません。サーバー上のGSSAPIAuthentication noに/etc/ssh/sshd_configを追加してサービスを再開してください。
私にとって、犯人はIPv6解決であり、タイムアウトでした。 （ホストプロバイダーのDNS設定が間違っていると思います。）ssh -vを実行することでこれを発見し、どのステップがハングしていたかを示しました。
解決策は、-4オプションを使用してsshにすることです。
ssh -4 [email protected]
Systemdを使用すると、アップグレード後にログインがlogindとのdbus通信でハングすることがあるので、logindを再起動する必要があります。
systemctl restart systemd-logind
Debian 8、Arch linx、そしてsuseメーリングリストでそれを見ました
現時点で何が行われているのかを表示する-vオプションで、sshをいつでも起動できます。
$ ssh -v you@Host
あなたが与えた情報で私はいくつかのクライアント側の設定を提案することができるだけです：
手動でパスワードを入力していると書いているので、可能であれば公開鍵認証を使用することをお勧めします。これはスピードのボトルネックとしてあなたを削除します。
-xを使用してX転送を無効にし、-aを使用して認証転送を無効にすることもできます（これらはデフォルトで既に無効になっている可能性があります）。特にX転送を無効にすると、クライアントがsshコマンドのためにXサーバーを起動する必要がある場合（OS Xの下など）、速度が大幅に向上します。
それ以外のことはすべて、いつどこでどのような遅延を経験するかによって異なります。
2.については、サーバーを変更する必要も、root /管理者特権を必要としない答えもあります。
以下の "user ssh_config"ファイルを編集する必要があります。
vi $HOME/.ssh/config
（注：ディレクトリ$ HOME/.sshが存在しない場合は作成する必要があります）
そして追加：
Host *
GSSAPIAuthentication no
GSSAPIDelegateCredentials yes
必要ならば、ホストごとにこれを行うことができます。
Host linux-srv
HostName 192.158.1.1
GSSAPIAuthentication no
GSSAPIDelegateCredentials yes
IPアドレスがサーバーのIPと一致することを確認してください。素晴らしい利点の1つは、sshがこのサーバーに対してオートコンプリートを提供することです。そのため、ssh lin + Tabと入力すると、ssh linux-srvにオートコンプリートするはずです。
このファイルにリストされているDNSサーバーが正常に機能していることを確認し、機能していないDNSを削除するには、サーバーの/etc/resolv.confを確認してください。
時々それは非常に役に立ちます。
すでに述べたDNSの問題に加えて、多数のNFSマウントを持つサーバーにSSH接続している場合、quotaコマンドがnoquotaでマウントされていないすべてのファイルシステムで使用量/割り当て量をチェックするため。 Solarisシステムでは、これをデフォルトの/etc/profileに表示し、touch $HOME/.hushloginを実行してスキップできます。
これはおそらくDebian/Ubuntu OpenSSHのみに特有のもので、Debianパッケージメンテナの一人によって書かれたuser-group-modes.patchが含まれています。このパッチは、ファイルと同じGIDを持つユーザーが1人だけの場合、〜/ .sshファイルにグループ書き込み可能ビットを設定（g + w）できるようにします。パッチのsecure_permissions（）関数がこのチェックを行います。チェックのフェーズの1つは、getpwent（）を使用して各passwdエントリーを調べて、エントリーのgidをファイルのgidと比較することです。
多数のエントリがあるシステムやNIS/LDAP認証が遅いシステムでは、このチェックは遅くなります。 nscdはgetpwent（）呼び出しをキャッシュしないため、サーバーがローカルでない場合はすべてのpasswdエントリがネットワーク経由で読み取られます。私がこれを見つけたシステムでは、それはsshの起動またはシステムへのログインごとに約4秒を追加しました。
修正は、chmod g-w ~/.ssh/*を実行することで〜/ .ssh内のすべてのファイルの書き込み可能ビットを削除することです。
Systemd-logind.serviceを再起動しても数時間しか問題が解決しないことがわかりました。 sshd_configでUsePAMをyesからnoに変更すると、高速ログインになりましたが、motdは表示されなくなりました。セキュリティ問題についてのコメント
このスレッドはすでに多くの解決策を提供していますが、ここでは説明していません=）。だからここにあります。私の問題（私のRaspberry PiにSSHログインするのに1分ほどかかりました）は、破損した.bash_historyファイルが原因でした。ファイルはログイン時に読み取られるため、これがログインの遅延を引き起こしていました。ファイルを削除すると、ログイン時間は瞬時のように通常に戻りました。
これが他の人々に役立つことを願っています。
最近sshログインが遅くなる原因がもう1つ見つかりました。
UseDNS noに/etc/sshd_configがある場合でも、/etc/hosts.denyに次のようなエントリがあると、sshdはDNSの逆引き参照を実行する可能性があります。
nnn-nnn-nnn-nnn.rev.some.domain.com
あなたのシステムに DenyHosts がインストールされているなら、それは起こるかもしれません。
DenyHostsがこの種のエントリを/etc/hosts.denyに入れないようにする方法を誰かが知っていれば素晴らしいでしょう。
/etc/hosts.denyからエントリを削除する方法については、 DenyHosts FAQ へのリンクです。 を参照してください。DenyHostsがブロックしたIPアドレスを削除するにはどうすればよいですか？
推奨される名前解決方法は、ホストファイルではなくDNSです。
たとえば、これは通常の設定です。
[root@LINUX1 ~]# cat /etc/nsswitch.conf|grep hosts
#hosts: db files nisplus nis dns
hosts: files dns myhostname
最初に、hostsファイルに到達し（オプション：files）、次にDNS（オプション：dns）に到達しましたが、動作していない別の名前解決システムが追加されていることがわかります。
名前解決の順序が正しくない場合は、次の場所で変更できます。/etc/nsswitch.conf
抽出元： http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html
DNS解決があなたのsshログインを遅くすることができることを示すすべての答えを完成させるために、時々、ファイアウォール規則が欠けている。たとえば、デフォルトですべてのINPUTパレットを削除したとします。
iptables -t filter -P INPUT DROP
それからsshポートとDNSリクエストのためにINPUTを受け入れなければなりません
iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
私はすべての答えを試しましたが、どれもうまくいきませんでした。最後に私は私の問題を見つけます：
最初にSudo tail -f /var/log/auth.logを実行するので、sshのログを確認してから別のセッションでssh 172.16.111.166を実行し、待機していることに気付くことができます。
/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166
/ etc/ssd/ssh_configにあるこの行を検索した後
ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h
私はそれをコメントし、遅れはなくなった
うまくいきます。
# uname -a
SunOS oi-san-01 5.11 oi_151a3 i86pc i386 i86pc Solaris
# ssh -V
Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x009080ff
# echo "GSSAPIAuthentication no" >> /etc/ssh/sshd_config
# echo "LookupClientHostnames no" >> /etc/ssh/sshd_config
# svcadm restart ssh
UseDNSはOpenIndianaでは機能しません。
すべてのオプションについては "man sshd_config"を読んでください。
サーバーが解決できない場合は「LookupClientHostnames no」
上記の答えがどれもうまくいかず、DNS逆引き参照の問題に直面している場合は、nscd（ネームサービスキャッシュデーモン）がインストールされ実行されているかどうかも確認できます。
これが問題である場合、それはあなたがDNSキャッシュを持っていない、そしてあなたがあなたのホストファイルにないホスト名を問い合わせるたびにあなたのキャッシュを調べる代わりにあなたのネームサーバに質問を送るからです
私は上記のすべてのオプションを試してみましたが、うまくいった唯一の変更はstart nscdです。
また、hostsファイルを最初に使用するように、/etc/nsswitch.confでDNSクエリを解決する順序を確認する必要があります。
ssh -vvv接続は、少なくとも20秒間端末を取得しようとしているシステムにハングアップするまで本当にうまくいきました。
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
... waiting ... waiting ... waiting
サーバー上でsystemctl restart systemd-logindを実行した後、またすぐに接続できました。
これはdebian8にありました！だからsystemdはここの問題でした！
注：Bastien Durelはすでにこの問題について回答していますが、デバッグ情報がありません。これが誰かに役立つことを願っています
注：これは「How to debug」チュートリアルとして始まりましたが、Ubuntu16.04 LTSサーバーで私を助けてくれた解決策になりました。
TLDR：landscape-sysinfoを実行し、そのコマンドが終了するまでに時間がかかるかどうかを確認してください。これは新しいSSHログインのシステム情報のプリントアウトです。このコマンドがすべてのシステムで利用できるわけではないことに注意してください、landscape-commonパッケージはそれをインストールします。 （「でも、まだまだあります…」）
問題があるマシン上の別のポートで2番目のSSHサーバを起動します。デバッグモードで起動します。そうしないとフォークされず、デバッグメッセージが表示されます。
Sudo /usr/sbin/sshd -ddd -p 44321
冗長モードで別のマシンからそのサーバーに接続します。
ssh -vvv -p 44321 username@server
私のクライアントは、眠り始める直前に以下の行を出力します。
debug1: Entering interactive session.
debug1: pledge: network
グーグルはそれほど便利ではありませんが、サーバーログはより優れています。
debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
debug3: PAM: opening session
---- Pauses here ----
debug3: PAM: sshpam_store_conv called with 1 messages
User child is on pid 28051
UsePAM yesをUsePAM noに変更すると、この問題は解決することに気付きました。
UseDNSname__や他の設定には関係なく、UsePAMname__だけが私のシステムのこの問題に影響を与えます。
その原因はわからないし、副作用もわからないため、UsePAMname__をnoname__に残していませんが、調査を続けることができます。
ですから、これを答えとしてではなく、何が悪いのかを突き止めるための最初のステップと考えてください。
そこで調査を続け、sshdname__（Sudo strace /usr/sbin/sshd -ddd -p 44321）を付けてstracename__を実行しました。これにより以下のものが得られた。
sendto(4, "<87>Nov 20 20:35:21 sshd[2234]: "..., 110, MSG_NOSIGNAL, NULL, 0) = 110
close(5) = 0
stat("/etc/update-motd.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
umask(022) = 02
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffde6152d2c) = 2385
wait4(2385, # BLOCKS RIGHT HERE, BEFORE THE REST IS PRINTED OUT # [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2385
/etc/update-motd.dという行は私を疑わしくしました、どうやらプロセスは/etc/update-motd.dにあるものの結果を待ちます
それで、私はcdnameを/etc/update-motd.dに入れ、Sudo chmod -x *を実行して、この動的なMessage Of The Dayを生成するすべてのファイルを実行することを禁止しました。
これは「エネルギー効率の良い」N3150 CPUをベースにしたサーバーで、毎日24時間365日の作業が必要なので、このモッドデータをすべて収集するには多すぎると思います。
そのフォルダ内のスクリプトを選択的に有効にしてどれがより害が少ないかを確かめることができますが、特にlandscape-sysinfoの呼び出しは非常に遅く、50-landscape-sysinfoはそのコマンドを呼び出します。それが最大の遅れを引き起こすものだと私は思います。
ほとんどのファイルを再度有効にした後、私は50-landscape-sysinfoと99-esmが私の問題の原因であるという結論に達しました。 50-landscape-sysinfoは実行に約5秒、99-esmは約3秒かかりました。残りのファイルは全部で2秒です。
50-landscape-sysinfoと99-esmはどちらも重要ではありません。 50-landscape-sysinfoは興味深いシステム統計を（そして、あなたがスペースが足りない場合も）プリントし、99-esmはUbuntu Extended Security Maintenanceに関連したメッセージをプリントアウトします
最後にecho '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.shを使ってスクリプトを作成し、要求に応じてそのプリントアウトを入手することができます。
私にはGSSAPIが必要でしたが、DNSの逆引き参照を無効にしたくありませんでした。これは良い考えのようには思えなかったので、resolv.confのメインページを調べました。私とSSH接続しているサーバーとの間のファイアウォールがDNS要求を妨害していたことがわかりました。なぜなら、それらはファイアウォールが期待する形式ではなかったからです。結局、私がしなければならなかったのは、私がSSH接続していたサーバー上のresolv.confにこの行を追加することだけでした。
options single-request-reopen
注目すべきことに、CentOS 7でのbindのパッケージ更新はnamedを壊し、/ etc/named.confにパーミッションの問題があることをログに記録しました。 0640で何ヶ月もうまく機能していました。今では0644を望んでいます。namedデーモンは 'named'ユーザーに属しているので、これは理にかなっています。
sshログインからローカルWebサーバーからのページ配信、遅いLAMPアプリなど、すべての要求が停止したローカルサーバー上でタイムアウトしたため、外部のセカンダリサーバーを探すまでに時間がかかりました。設定されているDNS。
私にとっては、私のローカルの/etc/hostsファイルに問題がありました。そのためsshは、タイムアウトまでに時間がかかった2つの異なるIP（1つ間違った）を試していました。
ssh -vを使うことはここでトリックをしました：
$ ssh -vvv remotesrv
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /home/mathieu/.ssh/config
debug1: /home/mathieu/.ssh/config line 60: Applying options for remotesrv
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to remotesrv [192.168.0.10] port 22.
debug1: connect to address 192.168.0.10 port 22: Connection timed out
debug1: Connecting to remotesrv [192.168.0.26] port 22.
debug1: Connection established.