web-dev-qa-db-ja.com

ログイン時の長い待ち時間

サーバーにログインすると、次のメッセージが表示されます。

No mail.
Last login: Fri Nov  5 14:22:45 2010...

それから私は5秒間待たなければならず、準備ができています...

wolfy@ubuntu-server:~$

この待機時間は正常ですか、これを「修復」するために何かを行う必要がありますか？

serversshperformancelogin
20
Wolfy

これは通常、pam_motd/etc/motdファイルを再生成した結果です。 /etc/update-motd.dの個々のスクリプトをチェックして、何かが特に遅いかどうかを確認できます。

18
Kees Cook

10.04（LTS）でも同じ問題があります。

-vvvでsshを実行すると、次の場所で停止します。

debug1: Entering interactive session.

この答えを拡張します。

サーバーをリモートで再起動し、DEBUG logginを有効にしました。また、この機会を利用してログインしたままにし、他のログイン試行を観察しました。ここで何が起こるかです。クライアントは接続し、承認され、上記のメッセージでハングします。

サーバーでは、プロセスリストに次のように表示されます。

root       835  0.0  0.1  11476  3348 ?        Ss   13:39   0:00 sshd: till [priv]
root       840  0.0  0.0   4804  1124 ?        S    13:39   0:00 /bin/sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/run-parts --lsbsysinit /etc/update-motd.d
root       841  0.0  0.0   4728  1108 ?        S    13:39   0:00 /bin/run-parts --lsbsysinit /etc/update-motd.d
root       854  0.0  0.0   4804  1144 ?        S    13:39   0:00 /bin/sh /etc/update-motd.d/50-landscape-sysinfo
root       861  0.2  0.5  15388  9248 ?        S    13:39   0:00 /usr/bin/python /usr/bin/landscape-sysinfo
root       863  0.0  0.0      0     0 ?        Z    13:39   0:00 [who] <defunct>

ログイン中に/usr/bin/python /usr/bin/landscape-sysinfoを実行できますが、何らかの理由で、ログインプロセスが停止する理由がわかりません。プロセスを強制終了すると、ログインはプロンプトに進み、successfulになります。

これはssh（d）の問題ではないようです。update-motdとランドスケープにより関連しています。 update-motdパッケージをアンインストールしましたが、/etc/update-motdディレクトリが持続し、スクリプトがまだ実行されているようです-プロセスがハングします。

これをさらにデバッグする：

/etc/update-motd.d/ディレクトリは実際にはパッケージupdate-motdに属していませんが、sshdを介したpam認証によってトリガーされているようです。

私はそれを打ち付けたようです！

次のファイルでpam_motdを無効にしました。

  • /etc/pam.d/sshd
  • /etc/pam.d/login

もう一つ：

apt-get purge landscape-client landscape-common

これらは一定の範囲で役立つようです。ただし、onlyは/etc/update-motd.d/の問題のスクリプトを削除し、そのディレクトリ内のすべてのスクリプトを削除することも、pam_motdを削除することもしません。

一般に、pam_motdを完全に無効にする方法はありませんでした。何をするにしても、ログインプロセスが特定の範囲まで遅くなるからです。 landscape-commonのスクリプトのようにブロックしませんが、遅いです。

この問題に関するバグレポート：

そこからの回避策：

ログインする機能はmotdを提示するよりも重要であることは正しいです。この動作が問題になる場合は、いくつかの方法で無効にできます。

  • motdを表示したくない場合は、/etc/pam.d/sshdの 'pam_motd'行をコメント化します。
  • /etc/update-motd.dディレクトリの内容を削除します。
  • chmod -x /etc/update-motd.d内の実行したくないスクリプト。
13
Till

最終的に自分で解決策を見つけました：

  1. Sudo apt-get remove landscape-client landscape-common
  2. session optional pam_motd.soおよび/etc/pam.d/loginのコメント行/etc/pam.d/sshd

これでログインが瞬時になりました！

10
BarsMonster

あなたの説明から、それはネットワークの問題のように聞こえます。診断するには：

  • -vパラメータを指定してsshを実行すると、冗長になります。
  • 接続しているSSHサーバーにpingを実行してみて、これも同時にハングするかどうかを確認します。
  • 同じサーバーに他の種類の転送を試してください。たとえば、-limit-rateパラメーターを指定したwgetでHTTPを介してファイルを取得し、「ハング」動作をトリガーするのに十分な時間がかかるようにします。
  • アイドル状態のときだけハングするのか、それとも何かをしているときでもハングするのかを確認します。アイドル中にハングした場合、-v診断でおそらく通知されます。その場合、キープアライブを使用することをお勧めします（ssh -o "TCPKeepAlive yes"）

WindowsとPuTTYでOKに接続できれば、おそらくサーバー側の問題ではありません。

4
roadmr

PermitEmptyPasswordとUsePAMの両方が有効になっている場合、OpenSSHサーバーは常にヌルパスワードで認証を試行します。これは、問題のアカウントに認証が必要ないというサインとして受け取ります。これは、両方のプロトコルで認証プロセスが開始されるとすぐに行われ、クライアントからの「実際の」認証要求への応答ではありません。 OpenSSHは、sshd_configフラグPermitEmptyPasswordが設定されている場合にのみ、そのようなアクセスを許可します。残念ながら、コードの記述方法は、どのような場合でもパスワードテストを実行するため、失敗としてPAMまで表示されます。

したがって：PermitEmptyPasswordまたはUsePAMを無効にしますが、PAMがないと、キーなしではログインできません。

リファレンス： https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG-c

3
Alessandro Pezzato

私の限られた経験では、PuTTYが機能するが、Linux（この場合はUbuntu）が機能しない場合、通常はキープアライブです。ネットワークまたはサーバーの問題は、両方のクライアントOSに影響します。

コマンドラインで上記のキープアライブオプションを使用できますが、入力するのは面倒です。

いくつかの構成ファイルを簡単に編集できます。

root accessがあり、すべてのユーザーに対して自動的に有効にする場合は、/etc/ssh/ssh_configを編集して、追加します

KeepAlive yes
ServerAliveInterval 120

ルートアクセスがない場合、または単一のユーザーに対して有効にする場合は、~/.ssh/configを編集して、同じ2行を追加します。

2
Panther

ログインすると、ubuntuはこれらのファイルを1つ以上実行します。

/etc/bash.bashrc
~/.bash_profile
~/.bashrc

あなたはそれらの中に何があるのか​​を見ることができ、多分時間がかかっているものを見るためにそれらを実行しようとするかもしれません。

2
Savvas Radevic

/ var/logでシステムログを確認します。関連するエラー/タイムアウトのメッセージが見つかる場合があります。

0
João Pinto

すでにログインしている接続（または別のコンソール）からサーバーにログインしているときに、実行中のプロセスを監視することができます。その時点でどのプロセスが最もアクティブであるか、または最もCPUを使用しているのかを特定する機会があります。

以下は可能な方法の1つです。

  1. 他のコンソールでログインしてみてください。
  2. topを実行して、何が起こるかを確認します。
  3. 最初のコンソールにログインします。

CPUを集中的に使用する計算が原因で遅延が発生しない場合は、不適切なものを見つけることはできません。この場合、問題はI/Oバウンド（ディスクの読み取り/書き込みまたはネットワーク応答の待機）である可能性があります。

0
ido

前に時間があれば

編集/etc/sshd_config

設定（または追加）

UseDNS no

または、静的なローカルIPの場合は、/etc/hostsにIPを追加します

0
user11187