SSHログインが遅いのはなぜですか？

UseDNSやnoで/etc/sshd_configを/etc/ssh/sshd_configにしてみてください。

同じようにパフォーマンスが低下しているサーバで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設定が悪いのだと思います）。(ホストプロバイダのDNS設定が悪かったのだと思います。)どのステップがハングアップしているかを示すssh -vを実行することでこれを発見しました。

解決策はsshオプションで-4すること。

ssh -4 me@myserver.com

systemd では、いくつかのアップグレード後に logind との dbus 通信でログインがハングアップすることがあり、logind を再起動する必要があります。

ssh は常に -v オプションで起動することができ、これは現在何が行われているかを表示します。

$ ssh -v you@host

あなたが提供してくれた情報では、クライアント側の設定をいくつか提案することしかできません。

• パスワードを手動で入力していると書いているので、可能であれば公開鍵認証を使用することをお勧めします。これにより、速度のボトルネックとなるあなたを取り除くことができます。

• X-forwarding を -x で無効にし、認証転送を -a で無効にすることもできます (これらはデフォルトで既に無効になっているかもしれません)。特に X-forwarding を無効にすることで、クライアントが ssh コマンドのために X-server を起動する必要がある場合 (例: OS X の場合)、速度が大幅に向上します。

その他のすべては、いつ、どこで、どのような遅延が発生するかにかかっています。

2.については、サーバを変更する必要がなく、root/管理者権限を必要としない方法をご紹介します。

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 アドレスと一致していることを確認してください。クールな利点としては、ssh がこのサーバのオートコンプリートを提供してくれるようになったことです。ssh lin + Tab と入力すると、ssh linux-srv にオートコンプリートされます。

このファイルに記載されているDNSサーバが正常に動作するかどうか、サーバ上の/etc/resolv.confを確認し、動作していないDNSを削除します。

非常に参考になることもあります。

すでに述べた DNS の問題に加えて、多数の NFS マウントがあるサーバに ssh 接続している場合、quota コマンドが noquota でマウントされていないすべてのファイルシステムの使用量/クォータをチェックするため、パスワードとプロンプトの間に遅延が生じる可能性があります。Solaris システムでは、デフォルトの /etc/profile でこれを確認し、touch $HOME/.hushlogin を実行することでこれをスキップすることができます。

上記の回答のどれもうまくいかず、DNSの逆引き問題に直面している場合は、nscd (ネームサービスキャッシュデーモン)がインストールされていて実行されているかどうかを確認することもできます。

これが問題であれば、DNSキャッシュがなく、ホストファイルにないホスト名を問い合わせるたびに、キャッシュを探す代わりにネームサーバに質問を送っていることが原因です

上記のオプションをすべて試してみましたが、nscdを起動しただけでした。

最初にhostsファイルを使用するために、/etc/nsswitch.confでDNSクエリの解決を行う順番を確認する必要があります。

これはおそらく Debian/Ubuntu OpenSSH にのみ特有のもので、Debian パッケージメンテナの一人が書いた user-group-modes.patch が含まれています。このパッチは、~/.ssh ファイルに書き込み可能なグループビット (g+w) を設定できるようにします。パッチの secure_permissions() 関数がこのチェックを行います。チェックのフェーズの一つは、getpwent() を使って各 passwd エントリを調べ、エントリの gid とファイルの gid を比較することです。nscd は getpwent() コールをキャッシュしないので、サーバがローカルでない場合、すべての passwd エントリがネットワーク経由で読み込まれてしまいます。私がこれを発見したシステムでは、ssh を起動したりシステムにログインしたりするたびに約 4 秒が追加されていました。

修正方法は、~/.ssh のすべてのファイルの書き込み可能ビットを chmod g-w ~/.ssh/* で削除することです。

注：これは、「デバッグ方法」、チュートリアルとして始まりましたが、Ubuntu 16.04 LTSサーバー上で私を助けてくれた解決策になりました。

TLDR . landscape-sysinfoを実行して、そのコマンドが終了するのに時間がかかるかどうかを確認してください; それは新しいSSHログイン時のシステム情報のプリントアウトです。このコマンドはすべてのシステムで利用できるわけではないことに注意してください。(「でも待って、もっとあるのよ…」)

問題のあるマシンの別のポートで 2 台目の ssh サーバを起動して、デバッグモードで行います。

sudo /usr/sbin/sshd -ddd -p 44321

冗長モードで別のマシンからそのサーバに接続してください。

ssh -vvv -p 44321 username@server

私のクライアントはスリープ開始直前に以下の行を出力します。

debug1: Entering interactive session.
debug1: pledge: network

landscape-common を UsePAM yes に変更すると、この問題が解決されることに気づきました。

UsePAM noや他の設定とは関係ありませんが、私のシステムではUseDNSだけがこの問題に影響しています。

理由はわかりません。また、どのような副作用があるのかわからないので、UsePAMをUsePAMのままにしているわけではありません。

だから、これは答えではなく、何が悪いのかを見つけ始めるための第一歩だと思ってください。

そこで私は調査を続け、no (sshd)でstraceを実行した。すると、以下のようになりました。

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

sudo strace /usr/sbin/sshd -ddd -p 44321 の行は私を疑わせました。どうやらプロセスは/etc/update-motd.d

にあるものの結果を待っているようです。

これは「エネルギー効率の良い」N3150 CPUをベースにしたサーバで、24時間365日やるべきことがたくさんあるので、このすべてのモットデータを収集するのはあまりにも無理があったのだと思います。

どれが害が少ないのか、そのフォルダ内のスクリプトを選択的に有効にし始めるかもしれませんが、特別に/etc/update-motd.dを呼び出すのは非常に遅く、cdはそのコマンドを呼び出してしまいます。これが一番の遅延の原因になっていると思います。

ほとんどのファイルを再有効化した後、/etc/update-motd.dとsudo chmod -x *が私のトラブルの原因であるという結論に達しました。Message Of The Dayは実行に約5秒、landscape-sysinfoは約3秒かかりました。残りのファイルは全部で約2秒。

50-landscape-sysinfoも50-landscape-sysinfoも重要ではない。99-esm は興味深いシステム統計をプリントアウトしてくれます(スペースが足りない場合にも！)。

最初に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 no は OpenIndiana で動作しません!

すべてのオプションの “man sshd_config” を読んでください

サーバが解決できない場合は “LookupClientHostnames no” を読んでください。

ssh -vvv 接続は本当にうまくいきましたが、少なくとも20秒以上端末を取得しようとするとシステム上でハングアップしてしまいました。

debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
... waiting ... waiting ... waiting

systemctl restart systemd-logind *サーバ上で0x6& *を実行した後、すぐに接続できるようになりました!

これは debian8 でのことです! つまり、ここではsystemdが問題だったということです!

注:_Bastien Durel さんが既にこの問題に対する回答を提供していますが、デバッグ情報が不足しています。誰かの参考になれば幸いです。

好ましい名前解決方法がホストファイルではなく、次に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

このスレッドはすでに解決策の束を提供していますが、私のはここでは与えられていません =)。だから、ここにあります。私の問題(ラズベリーπにsshでログインするのに約1分かかりました)は、破損した.bash_historyファイルが原因でした。ファイルはログイン時に読み込まれるので、これがログイン遅延の原因となっていました。ファイルを削除したら、ログイン時間は一瞬にして普通の時間に戻りました。

他の方の参考になれば幸いです。

DNS解決がsshログインを遅くする可能性があることを示すすべての回答を完成させるには、ファイアウォールのルールが欠落していることがあります。例えば、デフォルトの

iptables -t filter -P INPUT DROP

のすべての INPUT パケットを DROP した場合、ssh ポートと DNS リクエスト

iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
``` の INPUT を受け入れなければならないことになります。

最近、sshのログインが遅くなる別の原因を発見しました。

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アドレスを削除するにはどうすればいいですか？

systemd-logind.serviceを再起動すると数時間だけ問題が解決しました。sshd_config で UsePAM を yes から no に変更すると、motd は表示されなくなりましたが、高速にログインできるようになりました。セキュリティ問題についてのコメント

私の場合、ローカルの /etc/hosts ファイルに問題がありました。そのため、sshは2つの異なるIP(1つは間違ったIP)を試していて、タイムアウトするのに時間がかかっていました。

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.

私にとってはGSSAPIが必要で、DNSの逆引きをオフにしたくありませんでした。それは良い考えとは思えなかったので、resolv.confのメインページをチェックアウトしました。私と SSH 接続しているサーバとの間にあるファイアウォールが DNS リクエストを妨害していることがわかりました。結局、私がする必要があったのは、SSH 接続先のサーバの resolv.conf に以下の行を追加することだけでした。

options single-request-reopen

驚くべきことに、CentOS 7 上の bind のパッケージの更新は、今 /etc/named.conf がパーミッションの問題を持っていたことをログに記載して、名前が壊れました。これは0640で数ヶ月間うまく動いていました。今では 0644 を要求しています。これは named デーモンが ‘named’ ユーザに属していることを意味しています。

named がダウンしているときは、ローカルのウェブサーバからの ssh ログインからページ提供まで、すべてが遅くなっていました。