CentOS7でSSHの多要素認証を設定する方法

投稿日: 2019-11-08 2022-10-18
タグ: CentOS, Security

序章

認証要素は、システムへのログインなどのアクションを実行する権限があることを証明するために使用される単一の情報です。 認証チャネルは、認証システムがユーザーに要素を配信する方法、またはユーザーに応答を要求する方法です。パスワードとセキュリティトークンは、認証要素の例です。コンピューターや電話はチャネルの例です。

SSHはデフォルトで認証にパスワードを使用し、ほとんどのSSH強化手順では、代わりにSSHキーを使用することを推奨しています。ただし、これはまだ1つの要因にすぎません。悪意のある攻撃者がコンピュータを侵害した場合、彼らはあなたのキーを使用してサーバーも侵害する可能性があります。

このチュートリアルでは、これに対抗するために多要素認証を設定します。 多要素認証（MFA）は、認証またはログインするために複数の要素を必要とします。これは、悪意のある攻撃者が侵入するために、コンピュータと電話の両方など、複数のものを危険にさらす必要があることを意味します。さまざまなタイプの要因は、多くの場合、次のように要約されます。

パスワードやセキュリティ保護用の質問など、知っている
オーセンティケーターアプリやセキュリティトークンなど、持っているもの
指紋や声など、あなたがしているもの

一般的な要因の1つは、Google認証システムのようなOATH-TOTPアプリです。 OATH-TOTP （オープン認証時間ベースのワンタイムパスワード）は、ワンタイム使用パスワード（通常は30秒ごとに再利用される6桁の数字）を生成するオープンプロトコルです。

この記事では、SSHキーに加えてOATH-TOTPアプリを使用してSSH認証を有効にする方法について説明します。 SSH経由でサーバーにログインするには、2つのチャネルで2つの要素が必要になるため、パスワードまたはSSHキーのみの場合よりも安全になります。さらに、MFAのいくつかの追加のユースケースと、いくつかの役立つヒントとコツについて説明します。

前提条件

このチュートリアルに従うには、次のものが必要です。

sudo非rootユーザーとSSHキーを備えた1台のCentOS7サーバー。これは、この初期サーバーセットアップチュートリアルに従ってセットアップできます。
Google Authenticator（ iOS 、 Android ）などのOATH-TOTPアプリがインストールされたスマートフォンまたはタブレット。

ステップ1—GoogleのPAMをインストールする

このステップでは、GoogleのPAMをインストールして構成します。

Pluggable Authentication Module の略であるPAMは、ユーザーを認証するためにLinuxシステムで使用される認証インフラストラクチャです。 GoogleはOATH-TOTPアプリを作成したため、TOTPを生成し、GoogleAuthenticatorやAuthyなどのOATH-TOTPアプリと完全に互換性のあるPAMも作成しました。

まず、EPEL（Enterprise Linux用の追加パッケージ）リポジトリを追加する必要があります。

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

次に、PAMをインストールします。リポジトリを初めて使用する場合は、EPELキーを受け入れるように求められる場合があります。承認されると、キーを承認するように再度求められることはありません。

sudo yum install google-authenticator

PAMをインストールしたら、PAMに付属のヘルパーアプリを使用して、2番目の要素を追加するユーザーのTOTPキーを生成します。このキーは、システム全体ではなく、ユーザーごとに生成されます。つまり、TOTP認証アプリを使用するすべてのユーザーは、ログインしてヘルパーアプリを実行し、自分のキーを取得する必要があります。一度だけ実行してすべてのユーザーが有効にすることはできません（ただし、このチュートリアルの最後に、多くのユーザーにMFAを設定または要求するためのヒントがいくつかあります）。

初期化アプリを実行します。

google-authenticator

コマンドを実行すると、いくつかの質問が表示されます。最初の質問は、認証トークンを時間ベースにする必要があるかどうかを尋ねます。

Output
Do you want authentication tokens to be time-based (y/n) y

このPAMは、時間ベースまたは順次ベースのトークンを許可します。 シーケンシャルベースのトークンを使用するということは、コードが特定のポイントで開始し、使用するたびにコードをインクリメントすることを意味します。 時間ベースのトークンを使用するということは、特定の時間が経過するとコードがランダムに変化することを意味します。 Google Authenticatorのようなアプリが予想するのは時間ベースであるため、時間ベースを使用します。そのため、回答してください。 y はい。

この質問に答えた後、大きなQRコードを含む多くの出力がスクロールして通過します。この時点で、携帯電話の認証アプリを使用してQRコードをスキャンするか、秘密鍵を手動で入力します。 QRコードが大きすぎてスキャンできない場合は、QRコードの上にあるURLを使用して小さいバージョンを取得できます。追加すると、アプリ内で30秒ごとに変化する6桁のコードが表示されます。

注：秘密鍵、確認コード、および回復コードは、パスワードマネージャーなどの安全な場所に記録してください。たとえば、TOTPアプリにアクセスできなくなった場合に、アクセスを回復する唯一の方法はリカバリコードです。

残りの質問は、PAMに機能する方法を通知します。それらを1つずつ見ていきます。

Output
Do you want me to update your "/home/sammy/.google_authenticator" file (y/n) y

これにより、キーとオプションが .google_authenticator ファイル。いいえと答えると、プログラムは終了し、何も書き込まれません。これは、オーセンティケーターが機能しないことを意味します。

OutputDo you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

ここで「はい」と答えると、使用直後に各コードを期限切れにすることでリプレイ攻撃を防ぐことができます。これにより、攻撃者が使用したコードをキャプチャしてログインするのを防ぐことができます。

OutputBy default, tokens are good for 30 seconds. In order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with
poor time synchronization, you can increase the window from its default
size of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens). 
Do you want to do so? (y/n) n

ここで「はい」と答えると、移動する4分のウィンドウで最大8つの有効なコードが許可されます。「いいえ」と答えると、1：30分のローリングウィンドウで有効なコードが3つに制限されます。 1:30分の時間枠で問題が見つからない限り、「いいえ」と答えるのがより安全な選択です。

OutputIf the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

レート制限とは、リモートの攻撃者がブロックされる前に特定の数の推測しか試行できないことを意味します。以前にSSHに直接レート制限を設定していない場合は、今すぐ設定することは優れた強化手法です。

注：このセットアップが完了したら、秘密鍵をバックアップする場合は、 ~/.google-authenticator 信頼できる場所にファイルします。そこから、追加のシステムにデプロイするか、バックアップ後に再デプロイできます。

GoogleのPAMがインストールおよび構成されたので、次のステップは、TOTPキーを使用するようにSSHを構成することです。 SSHにPAMについて通知し、それを使用するようにSSHを構成する必要があります。

ステップ2—OpenSSHの構成

SSHを介してSSHの変更を行うため、最初のSSH接続を絶対に閉じないことが重要です。代わりに、2番目のSSHセッションを開いてテストを行います。これは、SSH構成に誤りがあった場合に、サーバーから自分自身をロックアウトしないようにするためです。すべてが機能したら、セッションを安全に閉じることができます。

まず、編集します sshd 構成ファイル。ここでは、 nano、デフォルトではCentOSにインストールされていません。あなたはそれをインストールすることができます sudo yum install nano、またはお気に入りの代替テキストエディタを使用します。

sudo nano /etc/pam.d/sshd

ファイルの最後に次の行を追加します。

/etc/pam.d/sshd

. . .
# Used with polkit to reauthorize users in remote sessions
-session   optional     pam_reauthorize.so prepare
auth required pam_google_authenticator.so nullok

The nullok 最後の行の最後にある単語は、この認証方法がオプションであることをPAMに伝えます。これにより、OATH-TOTPトークンを持たないユーザーでも、SSHキーを使用してログインできます。すべてのユーザーがOATH-TOTPトークンを取得したら、削除できます nullok この行からMFAを必須にします。

ファイルを保存して閉じます。

次に、この種の認証をサポートするようにSSHを構成します。 SSH構成ファイルを開いて編集します。

sudo nano /etc/ssh/sshd_config

探す ChallengeResponseAuthentication 行。コメントアウト no 線を引き、コメントを外します no ライン。

/ etc / ssh / sshd_config

. . .
# Change to no to disable s/key passwords
ChallengeResponseAuthentication yes
#ChallengeResponseAuthentication no
. . .

ファイルを保存して閉じてから、SSHを再起動して構成ファイルを再ロードします。再起動 sshd サービスは開いている接続を閉じないため、このコマンドでロックアウトされるリスクはありません。

sudo systemctl restart sshd.service

これまでにすべてが機能していることをテストするには、別のターミナルを開いてSSH経由でログインしてみてください。以前にSSHキーを作成して使用している場合は、ユーザーのパスワードやMFA確認コードを入力する必要がないことに気付くでしょう。これは、SSHキーがデフォルトで他のすべての認証オプションを上書きするためです。それ以外の場合は、パスワードと確認コードのプロンプトを取得する必要があります。

これまでに行ったことを確認したい場合は、開いているSSHセッションで次の場所に移動します。 ~/.ssh/ そして、authorized_keysファイルの名前を一時的に変更し、新しいセッションを開いて、パスワードと確認コードを使用してログインします。

cd ~/.ssh
mv authorized_keys authorized_keys.bak

TOTPトークンが機能することを確認したら、「authorized_keys.bak」ファイルの名前を元の名前に戻します。

mv authorized_keys.bak authorized_keys

次に、SSHキーを1つの要素として有効にし、検証コードを2番目の要素として有効にし、SSHにどの要素を使用するかを指示し、SSHキーが他のすべてのタイプを上書きしないようにする必要があります。

ステップ3—SSHにMFAを認識させる

再開します sshd 構成ファイル。

sudo nano /etc/ssh/sshd_config

ファイルの最後に次の行を追加します。これにより、SSHにどの認証方法が必要かが通知されます。この行は、SSHキーとパスワードまたは確認コード（または3つすべて）のいずれかが必要であることをSSHに通知します。

/ etc / ssh / sshd_config

. . .
# Added by DigitalOcean build process
ClientAliveInterval 120
ClientAliveCountMax 2
AuthenticationMethods publickey,password publickey,keyboard-interactive

ファイルを保存して閉じます。

次に、PAMを開きます sshd 構成ファイルを再度。

sudo nano /etc/pam.d/sshd

行を見つける auth substack password-auth ファイルの先頭に向かって。追加してコメントアウトする # 行の最初の文字としての文字。これは、パスワードの入力を求めないようにPAMに指示します。

/etc/pam.d/sshd

. . .
#auth       substack     password-auth
. . .

ファイルを保存して閉じてから、SSHを再起動します。

sudo systemctl restart sshd.service

次に、別のセッションでサーバーに再度ログインしてみてください。前回とは異なり、SSHは確認コードを要求する必要があります。入力すると、ログインします。 SSHキーが使用されたという兆候は見られませんが、ログインの試行には2つの要素が使用されました。確認したい場合は、追加できます -v （詳細）SSHコマンドの後：

Example SSH output\. . .
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammy/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
Authenticated with partial success.
debug1: Authentications that can continue: keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Verification code:

出力の終わりに向かって、SSHがSSHキーを使用する場所を確認してから、確認コードを要求します。これで、SSHキーとワンタイムパスワードを使用してSSH経由でログインできます。 3つの認証タイプすべてを適用する場合は、次の手順に従うことができます。

ステップ4— 3番目の要素を追加する（オプション）

ステップ3では、承認された認証の種類を sshd_config ファイル：

publickey （SSHキー）
password publickey （パスワード）
keyboard-interactive （検証コード）

これまでに選択したオプションを使用して、3つの異なる要素をリストしましたが、それらはSSHキーと検証コードのみを許可します。 3つの要素（SSHキー、パスワード、確認コード）をすべて取得したい場合は、1回の簡単な変更で3つすべてが有効になります。

PAMを開きます sshd 構成ファイル。

sudo nano /etc/pam.d/sshd

以前にコメントアウトした行を見つけて、 #auth substack password-auth、を削除して行のコメントを解除します # キャラクター。ファイルを保存して閉じます。ここでもう一度、SSHを再起動します。

sudo systemctl restart sshd.service

オプションを有効にすることにより auth substack password-auth、PAMは、SSHキーのチェックと、以前に作業していた確認コードの要求に加えて、パスワードの入力を求めるようになりました。これで、2つの異なるチャネルで、既知のもの（パスワード）と2つの異なるタイプのもの（SSHキーと検証コード）を使用できます。

これまで、この記事では、SSHキーと時間ベースのワンタイムパスワードを使用してMFAを有効にする方法の概要を説明してきました。これが必要なすべてである場合は、ここで終了できます。ただし、これが多要素認証を行う唯一の方法ではありません。以下は、多要素認証にこのPAMモジュールを使用するいくつかの追加の方法と、回復、自動使用などのためのいくつかのヒントとコツです。

ヒント1—アクセスの回復

強化して保護する他のシステムと同様に、そのセキュリティを管理する責任はあなたにあります。この場合、SSHキーまたはTOTPシークレットキーを紛失せず、TOTPアプリにアクセスできることを確認してください。ただし、場合によっては事態が発生し、アクセスする必要のあるキーやアプリを制御できなくなる可能性があります。

SSHキーまたはTOTPシークレットキーの紛失

SSHキーまたはTOTPシークレットキーを紛失した場合、リカバリはいくつかのステップに分割できます。 1つ目は、確認コードを知らずに戻ってくることです。2つ目は、秘密鍵を見つけるか、通常のMFAログイン用に再生成することです。

DigitalOcean Dropletで確認コードを生成する秘密鍵を紛失した後に入るには、ダッシュボードから仮想コンソールを使用して、ユーザー名とパスワードを使用してログインするだけです。

それ以外の場合は、sudoアクセス権を持つ管理ユーザーが必要になります。このユーザーに対してMFAを有効にしないでください。ただし、SSHキーのみを使用してください。あなたまたは別のユーザーが秘密鍵を紛失してログインできない場合、管理ユーザーはログインして、を使用して任意のユーザーの鍵を回復または再生成することができます。 sudo.

ログインしたら、TOTPシークレットを取得するのに役立つ2つの方法があります。

既存のキーを回復する
新しいキーを生成します

各ユーザーのホームディレクトリに、秘密鍵とGoogle認証システムの設定が保存されます ~/.google-authenticator. このファイルの最初の行は秘密鍵です。キーを取得する簡単な方法は、次のコマンドを実行することです。このコマンドは、 google-authenticator ファイル（すなわち秘密鍵）。次に、その秘密鍵を取得して、TOTPアプリに手動で入力します。

head -n 1 /home/sammy/.google_authenticator

既存のキーを使用しない理由がある場合（たとえば、影響を受けるユーザーと秘密キーを簡単に安全に共有できない場合、または既存のキーが危険にさらされている場合）、削除できます。 ~/.google-authenticator 完全にファイルします。これにより、ユーザーは、「/ etc / pam.d / sshd」ファイルの「nullok」を削除してMFAを適用していない場合、単一の要素のみを使用して再度ログインできるようになります。その後、実行できます google-authenticator 新しいキーを生成します。

TOTPアプリへのアクセスを失う

サーバーにログインする必要があるが、確認コードを取得するためにTOTPアプリにアクセスできない場合でも、秘密鍵を最初に作成したときに表示された回復コードを使用してログインできます。これらのリカバリコードは1回限りの使用であることに注意してください。ログインに使用すると、再度確認コードとして使用することはできません。

ヒント2—認証設定の変更

初期構成後にMFA設定を変更する場合は、更新された設定で新しい構成を生成する代わりに、 ~/.google-authenticator ファイル。このファイルは次のようにレイアウトされています。

.google-認証システムのレイアウト

<secret key>
<options>
<recovery codes>

このファイルで設定されているオプションには、オプションセクションに行があります。初期設定時に特定のオプションに「いいえ」と答えた場合、対応する行はファイルから除外されます。

このファイルに加えることができる変更は次のとおりです。

時間ベースのコードの代わりにシーケンシャルコードを有効にするには、行を変更します " TOTP_AUTH に " HOTP_COUNTER 1.
1つのコードを複数回使用できるようにするには、次の行を削除します " DISALLOW_REUSE.
コードの有効期限を4分に延長するには、次の行を追加します " WINDOW_SIZE 17.
複数の失敗したログインを無効にするには（レート制限）、行を削除します " RATE_LIMIT 3 30.
レート制限のしきい値を変更するには、次の行を見つけます " RATE_LIMIT 3 30 数字を調整します。 The 3 オリジナルでは、一定期間の試行回数を示し、 30 期間を秒単位で示します。
リカバリコードの使用を無効にするには、ファイルの下部にある5つの8桁のコードを削除します。

ヒント3—一部のアカウントでMFAを回避する

単一のユーザーまたは少数のサービスアカウント（つまり、人間ではなくアプリケーションが使用するアカウント）は、MFAを有効にせずにSSHアクセスする必要があります。たとえば、一部のFTPクライアントなど、SSHを使用する一部のアプリケーションは、MFAをサポートしていない場合があります。アプリケーションに確認コードを要求する方法がない場合、SSH接続がタイムアウトするまで要求がスタックする可能性があります。

のいくつかのオプションがある限り /etc/pam.d/sshd 正しく設定されている場合、ユーザーごとに使用する要素を制御できます。

一部のアカウントにMFAを許可し、他のアカウントにのみSSHキーを許可するには、次の設定を確認してください。 /etc/pam.d/sshd アクティブです。

/etc/pam.d/sshd

#%PAM-1.0
auth       required     pam_sepermit.so
#auth       substack     password-auth

. . .

# Used with polkit to reauthorize users in remote sessions
-session   optional     pam_reauthorize.so prepare
auth       required      pam_google_authenticator.so nullok

ここ、 auth substack password-auth パスワードを無効にする必要があるため、コメントアウトされています。一部のアカウントでMFAを無効にすることを意図している場合、MFAを強制することはできないため、 nullok 最終行のオプション。

この構成を設定した後、単に実行します google-authenticator MFAを必要とするすべてのユーザーと同様に、SSHキーのみが使用されるユーザーにはMFAを実行しないでください。

ヒント4—構成管理によるセットアップの自動化

多くのシステム管理者は、Puppet、Chef、Ansibleなどの構成管理ツールを使用してシステムを管理しています。このようなシステムを使用して、新しいユーザーのアカウントが作成されたときに秘密鍵を設定してインストールする場合は、それを行う方法があります。

google-authenticator 単一の非対話型コマンドですべてのオプションを設定するコマンドラインスイッチをサポートします。すべてのオプションを表示するには、次のように入力します google-authenticator --help. 以下は、ステップ1で概説したようにすべてを設定するコマンドです。

google-authenticator -t -d -f -r 3 -R 30 -W

これにより、手動で回答したすべての質問に回答し、ファイルに保存してから、秘密鍵、QRコード、およびリカバリコードを出力します。（フラグを追加した場合 -q、その場合、出力はありません。）このコマンドを自動化された方法で使用する場合は、秘密鍵や回復コード、あるいはその両方をキャプチャして、ユーザーが利用できるようにしてください。

ヒント5—すべてのユーザーにMFAを強制する

最初のログインでもすべてのユーザーにMFAを強制したい場合、またはユーザーが独自のキーを生成することに依存したくない場合は、これを処理する簡単な方法があります。あなたは単に同じものを使うことができます .google-authenticator ファイルにはユーザー固有のデータが保存されていないため、各ユーザーのファイル。

これを行うには、構成ファイルが最初に作成された後、特権ユーザーはファイルをすべてのホームディレクトリのルートにコピーし、そのアクセス許可を適切なユーザーに変更する必要があります。ファイルをにコピーすることもできます /etc/skel/したがって、作成時に新しいユーザーのホームディレクトリに自動的にコピーされます。

警告：全員が同じ2番目の要素を共有しているため、これはセキュリティリスクになる可能性があります。これは、リークされた場合、すべてのユーザーが1つの要因しか持っていないかのように見えることを意味します。このアプローチを使用する場合は、これを考慮に入れてください。

ユーザーの秘密鍵の作成を強制する別の方法は、次のようなbashスクリプトを使用することです。

TOTPトークンを作成し、
Google認証システムアプリをダウンロードして表示されるQRコードをスキャンするように促し、
を実行します google-authenticator かどうかを確認した後、それらのアプリケーション .google-authenticator ファイルが既に存在します。

ユーザーがログインしたときにスクリプトが確実に実行されるように、名前を付けることができます .bash_login そしてそれを彼らのホームディレクトリのルートに置きます。

結論

とはいえ、2つのチャネル（コンピューター+電話）に2つの要素（SSHキー+ MFAトークン）を使用することで、外部エージェントがSSH経由でマシンにブルートフォース攻撃を仕掛けることが非常に困難になり、大幅に増加しました。マシンのセキュリティ。

getdocs

13036