サーバーに負荷は掛かっていないはずなのに、ssh でのログインが異常なほど遅いと感じる時があります。
もちろん原因があって ssh ログインが遅延しています。
その場合の対応方法です。
ssh のデバッグモード(Verbose mode)でログインする
まずは ssh のデバッグモードでログインを試してみます。
「-v」でデバッグモードになり詳細にログが出力されます。
デバッグモードにもレベルがあり、マックスは「-vvv」と3つの v までです。
以下、デバッグモードで ssh ログインをした場合のログです。
$ ssh xx.xx.xx.215 -vvv debug1: Unspecified GSS failure. Minor code may provide more information debug2: we did not send a packet, disable method |
何度かログを見返してみたのですが、正直言うと上記のログでは当たりがつけられませんでした。
途中で何度か下記のようなログが表示されています。
これは様々な認証方式を試しているログと思いますが、実際他のサーバーも同じ環境であるにもかかわらず、当該サーバーのみ異様にログインに時間が掛かります。
debug1: identity file /home/test_accont/.ssh/id_rsa type -1
debug1: identity file /home/test_accont/.ssh/id_rsa-cert type -1
debug1: identity file /home/test_accont/.ssh/id_dsa type -1
debug1: identity file /home/test_accont/.ssh/id_dsa-cert type -1
debug1: identity file /home/test_accont/.ssh/id_ecdsa type -1
debug1: identity file /home/test_accont/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/test_accont/.ssh/id_ed25519 type -1
debug1: identity file /home/test_accont/.ssh/id_ed25519-cert type -1
あとは、ここら辺が怪しいでしょうか。
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
ここで時間を取っている?
具体的に ssh でログインする際にどのような内部処理が行われているのか確認するために「man ssh」コマンドで「認証部分」のみ調べてみました。
AUTHENTICATION The OpenSSH SSH client supports SSH protocols 1 and 2. OpenSSH SSHクライアントは、SSHプロトコル1と2をサポートしています。
The default is to use protocol 2 only, though this can be changed via the Protocol option in ssh_config(5) or the -1 and -2 options (see above). デフォルトではプロトコル2のみを使用しますが、これはssh_config(5)のプロトコルオプションまたは-1と-2のオプション(上記参照)で変更できます。
Both protocols support similar authentication methods, but protocol 2 is the default since it provides additional mechanisms for confidentiality (the traffic is encrypted using AES, 3DES, Blowfish, CAST128, or Arcfour) and integrity (hmac-md5, hmac-sha1, hmac-sha2-256, hmac-sha2-512, umac-64, umac-128, hmac-ripemd160). どちらのプロトコルも同様の認証方法をサポートしていますが、プロトコル2は、機密性(トラフィックはAES、3DES、Blowfish、CAST128、またはArcfourを使用して暗号化されています)と整合性(hmac-md5、hmac-sha1、hmac- sha2-256、hmac-sha2-512、umac-64、umac-128、hmac-ripemd160)があります。
Protocol 1 lacks a strong mechanism for ensuring the integrity of the connection. プロトコル1には、接続の完全性を保証する強力なメカニズムがありません。
The methods available for authentication are: GSSAPI-based authentication, host-based authentication, public key authentication, challenge-response authentication, and password authentication. 認証に使用できるメソッドは、GSSAPIベースの認証、ホストベースの認証、公開鍵認証、チャレンジ/レスポンス認証、およびパスワード認証です。
Authentication methods are tried in the order specified above, though protocol 2 has a configuration option to change the default order: PreferredAuthentications. プロトコル2にはデフォルトの順序「PreferredAuthentications」を変更する設定オプションがありますが、認証方法は上記の順序で試行されます。
Host-based authentication works as follows: If the machine the user logs in from is listed in /etc/hosts.equiv or /etc/ssh/shosts.equiv on the remote machine, and the user names are the same on both sides, or if the files ~/.rhosts or ~/.shosts exist in the user’s home directory on the remote machine and contain a line containing the name of the client machine and the name of the user on that machine, the user is considered for login. ホストベースの認証は、次のように動作します。ユーザーがログインしたマシンがリモートマシンの /etc/hosts.equiv または /etc/ssh/shosts.equiv にリストされていて、ユーザー名が両側で同じである場合は、 ファイル「 ~/.rhosts 」または「 ~/.shosts 」がリモートマシン上のユーザのホームディレクトリに存在し、クライアントマシンの名前とそのマシン上のユーザ名を含む行を含む場合、ユーザはログインと見なされます 。
Additionally, the server must be able to verify the client’s host key (see the description of /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts, below) for login to be permitted. さらに、サーバはログインを許可するために、クライアントのホスト鍵(以下の「 /etc/ssh/ssh_known_hosts 」および「 ~/.ssh/known_hosts 」の説明を参照)を検証できる必要があります。
This authentication method closes security holes due to IP spoofing, DNS spoofing, and routing spoofing. この認証方法は、IPスプーフィング、DNSスプーフィング、およびルーティングスプーフィングによるセキュリティホールを閉じます。
[Note to the administrator: /etc/hosts.equiv, ~/.rhosts, and the rlogin/rsh protocol in general, are inherently insecure and should be disabled if security is desired.] [管理者への注意:「 /etc/hosts.equiv 」、「 ~/.rhosts 」、および rlogin rsh プロトコルは、本質的に安全ではないので、セキュリティが必要な場合は無効にする必要があります。]
Public key authentication works as follows: The scheme is based on public-key cryptography, using cryptosystems where encryption and decryption are done using separate keys, and it is unfeasible to derive the decryption key from the encryption key. 公開鍵認証は次のように機能します。スキームは、暗号化と復号化が別々の鍵を使用して行われる暗号システムを使用する公開鍵暗号化に基づいており、暗号化鍵から復号鍵を引き出すことは不可能です。
The idea is that each user creates a public/private key pair for authentication purposes. アイデアは、各ユーザが認証のために公開鍵/秘密鍵のペアを作成することです。
The server knows the public key, and only the user knows the private key. サーバは公開鍵を知っており、ユーザだけが秘密鍵を知っています。
ssh implements public key authentication protocol automatically, using one of the DSA, ECDSA, ED25519 or RSA algorithms. sshは、DSA、ECDSA、ED25519またはRSAアルゴリズムのいずれかを使用して、公開鍵認証プロトコルを自動的に実装します。
Protocol 1 is restricted to using only RSA keys, but protocol 2 may use any. プロトコル1はRSAキーのみを使用するように制限されていますが、プロトコル2は任意のものを使用できます。
The HISTORY section of ssl(8) contains a brief discussion of the DSA and RSA algorithms. ssl(8)のHISTORYセクションには、DSAアルゴリズムとRSAアルゴリズムの簡単な説明が含まれています。
The file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in. ~/.ssh/authorized_keys ファイルには、ログインが許可されている公開鍵がリストされています。
When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. ユーザーがログインすると、sshプログラムは認証に使用するキーペアをサーバーに通知します。
The client proves that it has access to the private key and the server checks that the corresponding public key is authorized to accept the account. クライアントは、秘密鍵へのアクセス権を有していることを証明し、サーバは、対応する公開鍵がそのアカウントを受け入れる権限を有することをチェックする。
The user creates his/her key pair by running ssh-keygen(1). ユーザは、ssh-keygen(1)を実行することによって、自分の鍵ペアを作成します。
This stores the private key in ~/.ssh/identity (protocol 1), ~/.ssh/id_dsa (protocol 2 DSA), ~/.ssh/id_ecdsa (protocol 2 ECDSA), ~/.ssh/id_ed25519 (protocol 2ED25519), or ~/.ssh/id_rsa (protocol 2 RSA) and stores the public key in ~/.ssh/identity.pub (protocol 1), ~/.ssh/id_dsa.pub (protocol 2 DSA), ~/.ssh/id_ecdsa.pub (protocol 2 ECDSA), ~/.ssh/id_ed25519.pub (protocol 2 ED25519), or ~/.ssh/id_rsa.pub (protocol 2 RSA) in the user’s home directory. これは秘密鍵を ~/.ssh/identity(プロトコル1)、 ~/.ssh/id_dsa(プロトコル2 DSA)、 ~/.ssh/id_ecdsa(プロトコル2 ECDSA)、 ~/.ssh/id_ed25519(プロトコル2ED25519 )、 ~/.ssh/id_rsa(プロトコル2 RSA) に格納し、
公開鍵を ~/.ssh/identity.pub(プロトコル1)、 ~/.ssh/id_dsa.pub(プロトコル2 DSA)、 ~/.ssh/id_ecdsa.pub(プロトコル2 ECDSA)、 ~/.ssh/id_ed25519.pub(プロトコル2 ED25519)、 ~/.ssh/id_rsa.pub(プロトコル2 RSA) に格納します。
The user should then copy the public key to ~/.ssh/authorized_keys in his/her home directory on the remote machine. ユーザーは、公開鍵をリモートマシンのホームディレクトリの ~/.ssh/authorized_keys にコピーする必要があります。
The authorized_keys file corresponds to the conventional ~/.rhosts file, and has one key per line, though the lines can be very long. authorized_keys ファイルは、従来の ~/.rhosts ファイルに対応し、1行に1つのキーがありますが、行は非常に長くなります。
After this, the user can log in without giving the password. その後、ユーザーはパスワードを入力せずにログインできます。
A variation on public key authentication is available in the form of certificate authentication: instead of a set of public/private keys, signed certificates are used. 公開鍵認証のバリエーションは、証明書認証の形で利用できます。公開鍵/秘密鍵のセットではなく、署名された証明書が使用されます。
This has the advantage that a single trusted certification authority can be used in place of many public/private keys. これには、多くの公開鍵/秘密鍵の代わりに単一の信頼できる証明機関を使用できるという利点があります。
See the CERTIFICATES section of ssh-keygen(1) for more information. 詳細は、ssh-keygen(1)のCERTIFICATESセクションを参照してください。
The most convenient way to use public key or certificate authentication may be with an authentication agent. 公開鍵または証明書認証を使用する最も便利な方法は、認証エージェントを使用する方法です。
See ssh-agent(1) for more information. 詳細は、ssh-agent(1)を参照してください。
Challenge-response authentication works as follows: The server sends an arbitrary “challenge” text, and prompts for a response. チャレンジレスポンス認証は、次のように動作します。サーバーは任意の「チャレンジ」テキストを送信し、応答を求めるメッセージを表示します。
Protocol 2 allows multiple challenges and responses; protocol 1 is restricted to just one challenge/response. プロトコル2では、複数のチャレンジと応答が可能です。 プロトコル1は1つのチャレンジ/レスポンスに制限されています。
Examples of challenge-response authentication include BSD Authentication (see login.conf(5)) and PAM (some non-OpenBSD systems). チャレンジレスポンス認証の例には、BSD認証(login.conf(5)を参照)とPAM(OpenBSD以外のシステム)が含まれます。
Finally, if other authentication methods fail, ssh prompts the user for a password. 最後に、他の認証方法が失敗すると、sshはユーザにパスワードの入力を促します。
The password is sent to the remote host for checking; however, since all communications are encrypted, the password cannot be seen by someone listening on the network. チェックのためにパスワードがリモートホストに送信されます。 ただし、すべての通信は暗号化されているため、ネットワーク上で聴取している人はパスワードを見ることができません。
ssh automatically maintains and checks a database containing identification for all hosts it has ever been used with. sshは、それまで使用されていたすべてのホストの識別情報を含むデータベースを自動的に維持し、チェックします。
Host keys are stored in ~/.ssh/known_hosts in the user’s home directory. ホストキーは、ユーザーのホームディレクトリの ~/.ssh/known_hosts に格納されます。
Additionally, the file /etc/ssh/ssh_known_hosts is automatically checked for known hosts. さらに、/etc/ssh/ssh_known_hosts ファイルには、既知のホストが自動的にチェックされます。
Any new hosts are automatically added to the user’s file. 新しいホストは自動的にユーザーのファイルに追加されます。
If a host’s identification ever changes, ssh warns about this and disables password authentication to prevent server spoofing or man-in-the-middle attacks, which could otherwise be used to circumvent the encryption. ホストの身分証明書が変更された場合、sshはこれについて警告し、パスワードの認証を無効にしてサーバーのなりすましや中間者攻撃を防止します。
The StrictHostKeyChecking option can be used to control logins to machines whose host key is not known or has changed. StrictHostKeyCheckingオプションを使用すると、ホスト鍵が不明または変更されたマシンへのログインを制御できます。
When the user’s identity has been accepted by the server, the server either executes the given command, or logs into the machine and gives the user a normal shell on the remote machine. ユーザーのIDがサーバーによって受け入れられると、サーバーは指定されたコマンドを実行するか、マシンにログインして、リモート・マシン上の通常のシェルをユーザーに与えます。
All communication with the remote command or shell will be automatically encrypted. リモートコマンドまたはシェルとのすべての通信は自動的に暗号化されます。
If a pseudo-terminal has been allocated (normal login session), the user may use the escape characters noted below. 擬似端末が割り当てられている場合(通常のログインセッション)、ユーザーは以下に示すエスケープ文字を使用することがあります。
If no pseudo-tty has been allocated, the session is transparent and can be used to reliably transfer binary data. 擬似ttyが割り当てられていない場合、セッションは透過的であり、バイナリデータを確実に転送するために使用できます。
On most systems, setting the escape character to “none” will also make the session transparent even if a tty is used. ほとんどのシステムでは、エスケープ文字を “none”に設定すると、ttyが使用されてもセッションが透過的になります。
The session terminates when the command or shell on the remote machine exits and all X11 and TCP connections have been closed. セッションは、リモートマシン上のコマンドまたはシェルが終了し、すべてのX11およびTCP接続が閉じられたときに終了します。
|
この説明を読んでも不明でした。
さらにインターネット検索をしたら、以下の記事を見つけました。
Why does ssh’s “password” prompt take so long to appear?
https://askubuntu.com/questions/246323/why-does-sshs-password-prompt-take-so-long-to-appear
以下、記事の内容
質問
When I try to ssh, the password prompt takes too long (almost two minutes) to appear.
Why does this happen?
回答
There are several things that can go wrong. Add -vvv to make ssh print a detailed trace of what it’s doing, and see where it’s pausing.
The problem could be on the client or on the server.
A common problem on the server is if you’re connecting from a client for which reverse DNS lookups time out.
(A “reverse DNS lookup” means getting back from the client machine’s IP address to a host name. It isn’t really useful for security, only slightly helpful to diagnose breakin attempts from log entries, but the default configuration does it anyway.)
To turn off reverse DNS lookups, add UseDNS no to /etc/ssh/sshd_config (you need to be root on the server; remember to restart the SSH service afterwards).
Another thing that can go wrong is GSSAPI authentication timing out.
If you don’t know what that is, you’re probably not relying on it; you can turn it off by adding the line GSSAPIAuthentication no to /etc/ssh/ssh_config or ~/.ssh/config (that’s on the client side).
まさにドンピシャな感じです。
回答では
①-vvvをつけるようにアドバイス
→しかしこれをやってみたが不明でした。
②よくある問題は、DNSの逆引き(IPアドレスからドメイン名(FQDN)を引くこと)でタイムアウトをしているのが原因
→確かに動作確認をすると何の処理を待ってタイムアウトをして最後に「password」プロンプトを表示しているように見えます。
その場合の対応策(Work around)として「/etc/ssh/sshd_config」ファイルに「UseDNS no」を加えると良いと回答しています。
③その他よくある問題は「GSSAPI authentication」がタイムアウトをしていることが原因
→これもログに出ていました。
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)
そもそも「GSSAPI authentication」とは一体何なのでしょうか?
GSSAPI は「Generic Security Service Application Programming Interface」の略で、アプリケーションにデータのセキュリティを提供するライブラリのようです。
このライブラリを利用するとプログラマは細かいセキュリティの設定までプログラミングする必要はないということなのでしょうか。
それ以上は詳しく分かりませんでした。
とりあえず、切り分け調査をする材料が揃ったので、1つ1つ試してみます。
「/etc/ssh/sshd_config」ファイルに「UseDNS no」を追加する
まずは「/etc/ssh/sshd_config」ファイルに「UseDNS no」を追加して動作確認をしてみます。
# vi sshd_config # This is the sshd server system-wide configuration file. See # This sshd was compiled with PATH=/usr/local/bin:/usr/bin # The strategy used for options in the default sshd_config shipped with # If you want to change the port on a SELinux system, you have to tell # The default requires explicit activation of protocol 1 # HostKey for protocol version 1 # Lifetime and size of ephemeral version 1 server key # Ciphers and keying # Logging # Authentication: #LoginGraceTime 2m #RSAAuthentication yes # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts # To disable tunneled clear text passwords, change to no here! # Change to no to disable s/key passwords # Kerberos options # GSSAPI options # Set this to ‘yes’ to enable PAM authentication, account processing, #AllowAgentForwarding yes # no default banner path # Accept locale-related environment variables # override default of no subsystems # Example of overriding settings on a per-user basis |
この後、sshd サービスを再起動します。
# cat /etc/redhat-release ← OSのバージョンを確認します。 6月 19 18:39:57 xxx-xxxx01 systemd[1]: Starting OpenSSH server daemon… |
この後、sshでログインを試してみたところ、1秒以内で ssh ログインができました。
この「UseDNS no」を入れる前まで1分近くかかっていたログインが、一瞬でログインができるようになり若干感動を味わいました。
また、この結果により「GSSAPI authentication」は ssh ログインに遅延には無関係であることが分かりました。
「UseDNS no」は何をするための設定なのか?
DNSを使用してリモートホスト名を確認するためのオプションです。
もっと詳しくいうと、このオプションは接続されたクライアントのIPアドレスから逆引きによって解決されたホスト名を、同じIPアドレスにマップするかどうかを確認するよう sshd に指示するオプションです。
デフォルトは「UseDNS yes」です。
UseDNSオプションはあまり役に立つ場面がありません。
通常クライアントマシンは、逆引き設定を持たない場合が多く、逆引きが解決されません。
一般的には、DNSはロギングにのみ使用されますが、認証に使用する場合は、「sshd_config」ファイルに「IgnoreRhosts no」が指定されている場合です。
非常に特殊な環境を除いては、「UseDNS no」にした方がいいと思います。
今回の場合のように、環境によっては、リモートの ssh サーバーの逆引きがタイムアウトするまで数十秒待つことになることがあります。
コメント