CentOS 7 で SSH 用の多要素認証を設定する方法

by admin Leave Comment

はじめに

認証要素とは、システムにログインするなどのアクションを実行する権利を持っていることを証明するために使用する情報の単一ピースのことを指します。 認証チャネルは、認証システムがユーザに要素を提供する方法、またはユーザが返答することを要求する方法である。 パスワードとセキュリティトークンは認証要素の例であり、コンピュータと電話はチャネルの例です。

SSH はデフォルトで認証にパスワードを使用し、ほとんどの SSH 強化手順は、代わりに SSH キーを使用することを推奨します。 しかし、これはまだ 1 つの要素に過ぎません。

このチュートリアルでは、これに対処するために多要素認証をセットアップします。 多要素認証 (MFA) は、認証またはログインするために複数の要素を必要とします。 つまり、悪者が侵入するためには、パソコンと携帯電話の両方など、複数のものを危険にさらす必要があるのです。 異なるタイプの要素は、次のように要約されます。

  1. パスワードやセキュリティ質問など、知っているもの
  2. 認証アプリやセキュリティ トークンなど、持っているもの
  3. 指紋や音声など、自分自身

1 つの共通要素は、Google 認証などの OATH-TOTP アプリケーションです。 OATH-TOTP (Open Authentication Time-Based One-Time Password) は、1 回だけ使用するパスワードを生成するオープン プロトコルで、通常は 6 桁の数字で、30 秒ごとにリサイクルされます。

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

前提条件

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

  • sudo 非 root ユーザーおよび SSH キーを持つ 1 つの CentOS 7 サーバー（この初期サーバー設定チューナーでセットアップ可能）。
  • Google Authenticator (iOS, Android) などの OATH-TOTP アプリをインストールしたスマートフォンまたはタブレット。

ステップ 1 – Google の PAM のインストール

このステップでは、Google の PAM をインストールおよび設定します。

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

まず、EPEL (Extra Packages for 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 を設定または要求するヒントがあります)。

Run the initialization app.

  • google-authenticator

After you are asked a few questions that you run the command, you’re replaced a lot. 

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

このPAMでは、タイムベースのトークンかシーケンシャルベースのトークンを使用することができます。 シーケンシャルベースのトークンを使用すると、コードが特定のポイントから始まり、使用するたびにコードが増加します。 時間ベースのトークンを使用すると、一定の時間が経過した後にコードがランダムに変更されることを意味します。 この質問に答えると、大きなQRコードなど、多くの出力がスクロールして表示されます。 この時、携帯電話の認証アプリでQRコードを読み取るか、シークレットキーを手動で入力してください。 QRコードが大きすぎてスキャンできない場合は、QRコードの上にあるURLを使って小さいバージョンを取得することができます。 追加されると、アプリに30秒ごとに変わる6桁のコードが表示されます。

注意：シークレットキー、認証コード、リカバリーコードは、パスワードマネージャーなど安全な場所に必ず記録しておいてください。 回復コードは、たとえば、TOTP アプリへのアクセスを失った場合にアクセスを回復する唯一の方法です。

残りの質問は、PAM がどのように機能するかを通知します。 

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

これは、キーとオプションを.google_authenticatorファイルに書き込むものです。 

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

ここで「はい」と答えると、各コードを使用後すぐに期限切れにしてリプレイ攻撃を防いでいます。 

Output
By default, tokens are good for 30 seconds. In order to compensate forpossible time-skew between the client and the server, we allow an extratoken before and after the current time. If you experience problems withpoor time synchronization, you can increase the window from its defaultsize 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つの有効なコードに制限されます。 

Output
If the computer that you are logging into isn't hardened against brute-forcelogin 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

速度制限とは、リモート攻撃者がブロックされる前に、特定の数の推測を試みることができることを意味します。

注意: この設定が完了したら、秘密鍵をバックアップしたい場合は、~/.google-authenticator ファイルを信頼できる場所にコピーしてください。 そこから、追加のシステムに展開したり、バックアップ後に再展開したりできます。

さて、Google の PAM がインストールされ設定されたので、次のステップは、SSH が TOTP 鍵を使用するように設定することです。 SSH に PAM のことを伝え、それを使用するように SSH を設定する必要があります。

ステップ2 – OpenSSHの設定

SSH上でSSHの変更を行うので、最初のSSH接続は決して閉じないことが重要です。 その代わり、テストを行うために2つ目のSSHセッションを開いてください。 これは、SSHの設定に間違いがあった場合に、自分自身をサーバーから締め出すことを避けるためです。

最初に、sshd設定ファイルを編集します。 ここでは、CentOSにデフォルトでインストールされていないnanoを使用しています。

/etc/pam.d/sshd
. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

最後の行の最後にある nullok の単語は、この認証方法がオプションであることを PAM に知らせます。 これにより、OATH-TOTP トークンを持たないユーザでも、SSH 鍵を使ってログインすることができます。

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

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

  • sudo nano /etc/ssh/sshd_config

ChallengeResponseAuthentication行を探します。 no 行をコメントアウトし、no 行をコメント解除します。

/etc/ssh/sshd_config
. . .# Change to no to disable s/key passwordsChallengeResponseAuthentication yes#ChallengeResponseAuthentication no. . .

保存してファイルを閉じたら、SSH を再起動して設定ファイルを再読み込みしてください。 sshd サービスを再起動しても、開いている接続は閉じないので、このコマンドで自分自身をロックアウトする危険はありません。

  • sudo systemctl restart sshd.service

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

これまでに行ったことが機能するかどうかを確認するには、開いている SSH セッションで ~/.ssh/ に移動して authorized_keys ファイルの名前を一時的に変更し、新しいセッションを開いてパスワードと認証コードでログインしてください。

  • mv authorized_keys.bak authorized_keys

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

Step 3 – SSH に MFA を認識させる

sshd設定ファイルを再度開き、

  • sudo nano /etc/ssh/sshd_config

ファイルの最後に次の行を追加してください。 これは SSH にどの認証方法が必要かを伝えるものです。

/etc/ssh/sshd_config
. . .# Added by DigitalOcean build processClientAliveInterval 120ClientAliveCountMax 2AuthenticationMethods publickey,password publickey,keyboard-interactive

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

次に、PAM sshd 設定ファイルをもう一度開きます。

  • sudo nano /etc/pam.d/sshd

ファイルの先頭の auth substack password-auth 行を探します。 その行の最初の文字として # を追加して、コメントアウトします。

/etc/pam.d/sshd
. . .#auth substack password-auth. . .

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

  • sudo systemctl restart sshd.service

次に、別のセッションでサーバーに再度ログインしてみます。 前回とは異なり、SSHは認証コードを要求してくるはずです。 それを入力すると、ログインされます。 SSHキーが使われたという表示がなくても、あなたのログイン試行には2つの要素が使われています。 もし確認したい場合は、SSHコマンドの後に-v（冗長）を追加してください：

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

出力の最後に、SSHがあなたのSSHキーを使用し、その後認証コードを要求しているのがわかります。 これで、SSHキーとワンタイムパスワードでSSHログインができるようになりました。 もし、3つの認証タイプをすべて実施したい場合は、次のステップに進んでください。

ステップ 4 – 第三の要素の追加 (オプション)

ステップ 3 では、sshd_config ファイルに承認された認証の種類を一覧表示しました。

  1. publickey (SSH キー)
  2. password publickey (パスワード)
  3. keyboard-interactive (検証コード)

3 つの要素をリストしましたが、これまでのオプションでは、SSH キーと検証コードのみが許可されています。 3 つの要素 (SSH キー、パスワード、および検証コード) すべてを使用したい場合は、1 つの簡単な変更で 3 つすべてを有効にできます。

PAM sshd 設定ファイルを開きます。

  • sudo nano /etc/pam.d/sshd

前にコメントアウトした行、#auth substack password-auth を見つけ、# 文字を取り除いて、その行のコメントを解除します。 ファイルを保存して閉じます。 

  • sudo systemctl restart sshd.service

オプション auth substack password-auth を有効にすることで、PAM は以前動作していた SSH キーのチェックと確認コードの要求に加えて、パスワードを要求するようになりました。

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

Tip 1 – アクセスの回復

強化および保護したシステムと同様に、そのセキュリティを管理する責任が生じます。 この場合、SSH キーや TOTP 秘密鍵を失わないこと、および TOTP アプリにアクセスできることを確認することを意味します。 しかし、時には物事が起こり、侵入するために必要なキーやアプリのコントロールを失うことがあります。

Losing an SSH Key or TOTP Secret Key

SSH キーまたは TOTP 秘密鍵を紛失した場合、回復はいくつかのステップに分けることができます。

DigitalOceanのDropletで認証コードを生成する秘密鍵を紛失した後にログインするには、単にダッシュボードから仮想コンソールを使用して、ユーザー名とパスワードを使用してログインすることも可能です。 あなたや他のユーザーが秘密鍵を紛失してログインできない場合、管理ユーザーはログインして、sudo を使用しているすべてのユーザーの鍵を回復または再生成するのを助けることができます。

一度ログインしたら、TOTP 秘密鍵の取得を支援する 2 つの方法があります。

  1. 既存の鍵を回復する
  2. 新しい鍵を生成する

各ユーザーのホーム ディレクトリの ~/.google-authenticator には秘密鍵と Google 認証システムの設定値が保存されています。 このファイルの一番最初の行がシークレットキーになります。 このキーを取得する簡単な方法は、次のコマンドを実行すると、google-authenticatorファイルの1行目（つまりシークレットキー）が表示されます。 

  • head -n 1 /home/sammy/.google_authenticator

既存のキーを使用しない理由がある場合 (たとえば、影響を受けるユーザーと秘密キーを簡単に安全に共有できない、または既存のキーが侵害された)、~/.google-authenticator ファイルを完全に削除することが可能です。 これにより、「/etc/pam.d/sshd」ファイル内の「nullok」を削除してMFAを実施していないユーザーは、単一要素のみを使用して再度ログインすることができます。

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

サーバーにログインする必要があるが、検証コードを取得するための TOTP アプリにアクセスできない場合、秘密鍵を最初に作成したときに表示されたリカバリ コードを使用してログインすることは可能です。 なお、これらのリカバリーコードは1回限りの使用です。

Tip 2 – 認証設定の変更

初期設定後に MFA 設定を変更したい場合、更新した設定で新しい設定を生成するのではなく、~/.google-authenticator ファイルを編集するだけで可能です。 このファイルは次のようにレイアウトされています:

.google-authenticator layout
<secret key><options><recovery codes>

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

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

  • 時間ベースのコードの代わりに連続コードを有効にするには、行 " TOTP_AUTH を " HOTP_COUNTER 1 に変更します。
  • 単一のコードの複数の使用を許可するには、行 " DISALLOW_REUSE を削除します。
  • コードの有効期限を 4 分に拡張するには、行 " WINDOW_SIZE 17 を追加します。
  • 複数回のログイン失敗（レート制限）を無効にするには、" RATE_LIMIT 3 30行を削除します。
  • レート制限の閾値を変更するには、" RATE_LIMIT 3 30行を見つけて数字を調整します。 原文の3は一定期間の試行回数、30は一定期間（秒）を示します。
  • リカバリーコードを使用しないようにするには、ファイル下部の8桁のコード5個を削除してください。

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

単一のユーザーまたは少数のサービス アカウント (人間ではなくアプリケーションによって使用されるアカウント) が、MFA を有効にせずに SSH アクセスを必要とする状況があるかもしれません。 例えば、いくつかの FTP クライアントのような SSH を使用するアプリケーションは、MFA をサポートしていない場合があります。 アプリケーションが検証コードを要求する方法を持たない場合、SSH 接続がタイムアウトするまで要求が行き詰まることがあります。

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

一部のアカウントで MFA を許可し、他のアカウントでは SSH 鍵のみを許可するには、/etc/pam.d/sshd の次の設定が有効であることを確認します。

/etc/pam.d/sshd
#%PAM-1.0auth required pam_sepermit.so#auth substack password-auth. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

ここで、auth substack password-auth はパスワードが無効にする必要があるのでコメントアウトしています。

この設定を行った後、MFA が必要なすべてのユーザーとして google-authenticator を実行し、SSH 鍵のみが使用されるユーザーに対しては実行しないようにするだけです。 このようなシステムを使用して、新しいユーザーのアカウントが作成されたときに秘密鍵をインストール設定したい場合、その方法があります。

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

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

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

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

警告です。 これは、誰もが同じ第 2 因子を共有するため、セキュリティ上のリスクとなる可能性があります。 これは、もしそれが漏れた場合、すべてのユーザーが 1 つの要素しか持っていないのと同じことになることを意味します。

  1. TOTP トークンを作成し、
  2. Google Authenticator アプリをダウンロードして表示される QR コードをスキャンするようユーザーに促し、
  3. .google-authenticator ファイルがすでに存在するかチェックしてから google-authenticator アプリケーションを実行する bash スクリプトも使用できます。

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

Conclusion

つまり、2 つの要素 (SSH キー + MFA トークン) が 2 つのチャネル（コンピューター + スマホ）で存在すれば、外部のエージェントがブルート フォースによってあなたのコンピューターに入ることは非常に難しく、あなたのコンピューターのセキュリティは大幅に強化されていると言えます。

コメントを残す

メールアドレスが公開されることはありません。