開発者ドキュメント

Ubuntu20.04でSSHの多要素認証を設定する方法

getdocs

著者はCOVID-19救済基金を選択し、 Write forDOnationsプログラムの一環として寄付を受け取りました。

序章

SSHはデフォルトで認証にパスワードを使用し、ほとんどのSSH強化手順では、代わりにSSHキーを使用することを推奨しています。 ただし、SSHキーは、はるかに安全な要素ではありますが、それでも1つの要素にすぎません。 チャネルは、暗号化されたトンネルを介してリモートマシンにデータを送信するコンピューター上の端末です。 しかし、ハッカーがパスワードを推測できるように、SSHキーを盗むことができます。いずれの場合も、その1つのデータを使用して、攻撃者がリモートシステムにアクセスする可能性があります。

このチュートリアルでは、これに対抗するために多要素認証を設定します。 多要素認証（MFA）または二要素認証（2FA）では、認証またはログインに複数の要素が必要です。 これは、悪意のある攻撃者が侵入するために、コンピュータや電話などの複数のものを危険にさらす必要があることを意味します。 認証で使用される要素にはいくつかの種類があります。

  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のいくつかの追加の使用例と、役立つヒントやコツについても説明します。

また、SSH接続の保護に関する詳細なガイダンスが必要な場合は、OpenSSHの強化およびOpenSSHクライアントの強化に関するこれらのチュートリアルを確認してください。

前提条件

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

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

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

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

まず、Ubuntuのリポジトリキャッシュを更新します。

  1. sudo apt-get update

次に、PAMをインストールします。

  1. sudo apt-get install libpam-google-authenticator

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

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

  1. 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 "~/.google_authenticator" file (y/n) y

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

Output
Do 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

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

Output
By default, a new token is generated every 30 seconds by the mobile app.
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. This allows for a
time skew of up to 30 seconds between the authentication server and client. Suppose you
experience problems with poor time synchronization. In that case, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the eight previous codes, the current
code, and the eight next codes). This will permit a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) n

ここで「はい」と答えると、移動する4分間のウィンドウで最大17の有効なコードが許可されます。 「いいえ」と答えると、1：30分のローリングウィンドウで有効なコードが3つに制限されます。 1:30分の時間枠で問題が見つからない限り、「いいえ」と答えるのがより安全な選択です。 この設定は、後でホームディレクトリのルートに保存されている.google_authenticatorファイルで変更できます。

Output
If 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 three 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— MFA/2FAを使用するようにOpenSSHを構成する

SSHを介してSSHの変更を行うため、最初のSSH接続を絶対に閉じないことが重要です。 代わりに、2番目のSSHセッションを開いてテストを行ってください。 これは、SSH構成に誤りがあった場合に、サーバーから自分自身をロックアウトしないようにするためです。 すべてが機能したら、セッションを安全に閉じることができます。 もう1つの安全上の注意は、編集するシステムファイルのバックアップを作成することです。そのため、問題が発生した場合は、元のファイルに戻して、クリーンな構成で最初からやり直すことができます。

まず、sshd構成ファイルのバックアップを作成します。

  1. sudo cp /etc/pam.d/sshd /etc/pam.d/sshd.bak

次に、nanoまたはお気に入りのテキストエディタを使用してファイルを開きます。

  1. sudo nano /etc/pam.d/sshd

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

/etc/pam.d/sshd
. . .
# Standard Un*x password updating.
@include common-password
auth required pam_google_authenticator.so nullok
auth required pam_permit.so

最後の行の最後にあるnullokという単語は、この認証方法がオプションであることをPAMに通知します。 これにより、OATH-TOTPトークンを持たないユーザーでも、SSHキーを使用するだけでログインできます。 すべてのユーザーがOATH-TOTPトークンを取得したら、この行からnullokを削除して、MFAを必須にすることができます。 pam_permit.soの2行目は、ユーザーがMFAトークンを使用してログインしない場合に認証を許可するために必要です。 ログインするとき、認証を許可するには、各メソッドでSUCCESSが必要です。 ユーザーがMFA認証ツールを使用しない場合、nullokオプションを使用すると、対話型キーボード認証のIGNOREが返されます。 pam_permit.soは、SUCCESSを返し、認証を続行できるようにします。

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

次に、この種の認証をサポートするようにSSHを構成します。

まず、ファイルのバックアップを作成します。

  1. sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

  2.

次に、SSH構成ファイルを開いて編集します。

  1. sudo nano /etc/ssh/sshd_config

ChallengeResponseAuthenticationを探し、その値をyesに設定します。

/ etc / ssh / sshd_config
. . .
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes
. . .

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

  1. sudo systemctl restart sshd.service

これまでにすべてが機能していることをテストするには、別のターミナルを開き、SSH経由でログインしてみてください。 現在のSSHセッションを開いたままにして、追加のセッションでテストすることが非常に重要です。そうしないと、ある時点でロックアウトされ、Webコンソールを使用して元に戻る必要があります。

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

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

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

SSHキーを使用している場合、MFAはまだ機能していません。 SSHにMFAを認識させるには、sshd構成ファイルを再度開きます。

  1. sudo nano /etc/ssh/sshd_config

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

/ etc / ssh / sshd_config
. . .
AuthenticationMethods publickey,password publickey,keyboard-interactive

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

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

  1. sudo nano /etc/pam.d/sshd

@include common-auth行を見つけて、その行の最初の文字として#文字を追加してコメントアウトします。 これは、PAMにパスワードの入力を求めないように指示します。

/etc/pam.d/sshd
. . .
# Standard Un*x authentication.
#@include common-auth
. . .

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

  1. sudo systemctl restart sshd.service

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

-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 rsa-sha2-512 blen 279
Authenticated with partial success.
debug1: Authentications that can continue: password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Verification code:

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

おめでとうございます。SSH経由でサーバーにリモートログインするときに、2番目の要素が正常に追加されました。 これが必要な場合（SSHキーとTOTPトークンを使用してSSHのMFAを有効にする（ほとんどの場合、これが最適な構成です））、これで完了です。

以下は、リカバリ、自動使用などのヒントとコツです。

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

手順3では、承認された認証の種類をsshd_configファイルにリストしました。

  1. publickey（SSHキー）
  2. password publickey（パスワード）
  3. keyboard-interactive（確認コード）

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

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

  1. sudo nano /etc/pam.d/sshd

以前にコメントアウトした行#@include common-authを見つけ、#文字を削除してその行のコメントを解除します。 ファイルを保存して閉じます。 ここでもう一度、SSHを再起動します。

  1. sudo systemctl restart sshd.service

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

ステップ5— Google MFAへのアクセスを回復する（オプション）

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

TOTP秘密鍵を紛失する

TOTP秘密鍵を紛失した場合は、回復プロセスをいくつかのステップに分けることができます。 1つ目は、確認コードを知らずに戻ってくることです。2つ目は、秘密鍵を見つけるか、通常のMFAログイン用に再生成することです。 これは、新しい電話を入手し、秘密を新しい認証システムアプリに転送しない場合によく発生します。

DigitalOcean DropletでTOTP秘密鍵を紛失した後にログインするには、ダッシュボードから仮想コンソール

モバイルバージョンを終了