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

前書き

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

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

このチュートリアルでは、多要素認証を設定してそれに対処します。 多要素認証(MFA)は、認証またはログインするために複数の要素を必要とします。 これは、悪意のある攻撃者がコンピューターや携帯電話などの複数のものを侵害する必要があることを意味します。 多くの場合、さまざまなタイプの要因は次のように要約されます。

  1. パスワードやセキュリティの質問など、*知っている*もの

  2. オーセンティケーターアプリやセキュリティトークンなど、*持っている*もの

  3. 指紋や声など、あなたが*している*もの

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

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

前提条件

このチュートリアルを実行するには、次のものが必要です。

  • this Initialサーバーセットアップチュートリアル

  • Google Authenticator(https://itunes.apple.com/us/app/google-authenticator/id388497605?mt=8[iOS]、https://play.googleなどのOATH-TOTPアプリがインストールされたスマートフォンまたはタブレット.com / store / apps / details?id = com.google.android.apps.authenticator2&hl = en [Android])。

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

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

_Pluggable Authentication Module_の略であるPAMは、Linuxシステムでユーザーを認証するために使用される認証インフラストラクチャです。 GoogleはOATH-TOTPアプリを作成したため、TOTPを生成し、Google Authenticatorやhttps://www.authy.com/[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

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

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

このPAMでは、時間ベースまたはシーケンシャルベースのトークンを使用できます。 _sequential-based tokens_を使用すると、コードは特定のポイントで開始され、使用するたびにコードが増分されます。 _時間ベースのトークン_を使用すると、特定の時間が経過するとコードがランダムに変更されます。 それはGoogle Authenticatorのようなアプリが予想していることなので、時間ベースに固執します。そのため、「+ y +」と答えます。

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

残りの質問は、PAMに機能方法を伝えます。 それらを1つずつ確認します。

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

これにより、キーとオプションが `+ .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)

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

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)

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

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)

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

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

ステップ2-OpenSSHの構成

SSH経由でSSHを変更するため、最初のSSH接続を閉じないことが重要です。 代わりに、テストを行うために2番目のSSHセッションを開きます。 これは、SSH構成に間違いがあった場合にサーバーから身を締め出さないようにするためです。 すべてが機能したら、セッションを安全に閉じることができます。

まず、 `+ sshd `設定ファイルを編集します。 ここでは、デフォルトでCentOSにインストールされない「 nano 」を使用しています。 ` 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

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

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

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

sudo nano /etc/ssh/sshd_config

「+ ChallengeResponseAuthentication no」行を探します。 `+ no `行をコメントアウトし、 ` no +`行のコメントを解除します。

/ etc / ssh / sshd_config

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

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

次に、1つの要素としてSSHキーを有効にし、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

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

次に、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つの要因があります。 確認したい場合は、SSHコマンドの後に「+ -v +」(冗長)を追加できます。

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 +`ファイルにリストしました:

  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 +」を見つけ、「#+」文字を削除して行のコメントを解除します。 ファイルを保存して閉じます。 もう一度、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で検証コードを生成する秘密鍵を紛失した後に取得するには、https://www.digitalocean.com/community/tutorials/how-to-use-the-digitalocean-console-to-accessにアクセスするだけです。 -ダッシュボードのドロップレット[仮想コンソールを使用]からユーザー名とパスワードを使用してログインします。

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

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

  1. 既存のキーを回復する

  2. 新しいキーを生成する

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

head -n 1 /home//.google_authenticator

既存のキーを使用しない理由がある場合(たとえば、影響を受けるユーザーと秘密キーを簡単に安全に共有できない、または既存のキーが危殆化した)、 `〜/ .google-authenticator +`ファイルを削除できますまったく。 これにより、ユーザーは「/etc/pam.d/sshd」ファイルの「nullok」を削除してMFAを強制していないと仮定して、1つの要素のみを使用して再度ログインできます。 次に、 ` google-authenticator`を実行して新しいキーを生成できます。

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

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

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

初期設定後にMFA設定を変更する場合、更新された設定で新しい設定を生成する代わりに、 `+〜/ .google-authenticator +`ファイルを編集するだけです。 このファイルは、次の方法でレイアウトされます。

google-authenticator layout
<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 + `という行を見つけて、数値を調整します。 オリジナルの「+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 +」オプションを残します。

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

ヒント4-構成管理を使用したセットアップの自動化

多くのシステム管理者は、Puppet、Chef、Ansibleなどのhttps://www.digitalocean.com/community/tutorial_series/getting-started-with-configuration-management [構成管理ツール]を使用してシステムを管理します。 このようなシステムを使用して、新しいユーザーのアカウントが作成されたときにシークレットキーをセットアップする場合、それを行う方法があります。

`+ 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 + /にコピーして、作成時に新しいユーザーのホームディレクトリに自動的にコピーすることもできます。

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

  1. TOTPトークンを作成し、

  2. Google Authenticatorアプリをダウンロードし、表示されるQRコードをスキャンするように指示します。

  3. `+ .google-authenticator `ファイルが既に存在するかどうかを確認した後、 ` google-authenticator +`アプリケーションを実行します。

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

結論

とはいえ、2つのチャネル(コンピューター+電話)に2つの要素(SSHキー+ MFAトークン)を持たせることで、外部エージェントがSSHを介してマシンにブルートフォースすることを非常に難しくし、大幅に増加させましたマシンのセキュリティ。