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

著者は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クライアントの強化に関するこれらのチュートリアルを確認してください。

前提条件

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

• sudo非rootユーザーとSSHキーを備えた1台のCentOS8サーバー。これは、この初期サーバーセットアップチュートリアルに従ってセットアップできます。
• Google Authenticator（ iOS 、 Android ）などのOATH-TOTPアプリがインストールされたスマートフォンまたはタブレット。
• または、「oathtool」というLinuxコマンドラインアプリを使用して、OATH-TOTPコードを生成することもできます。 さまざまなディストリビューションリポジトリで利用可能です
• SSH接続を本当に安全にしたい場合は、この SSH Essentials の記事で概説されている、ユーザーのホワイトリストへの登録、rootログインの無効化、SSHが使用するポートの変更などのいくつかの良い手順があります。

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

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

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

まず、EPEL（Enterprise Linux用の追加パッケージ）リポジトリを追加します。

sudo yum search epel

リポジトリにEPELインストールパッケージがある場合は、次の出力が表示されます。

Output
===== Name Matched: epel =====
epel-release.noarch : Extra Packages for Enterprise Linux repository configuration

次に、epel-releaseパッケージをインストールして、EPELリポジトリを有効にします。

sudo yum install epel-release

ただし、パッケージepel-releaseがない場合は、リポジトリ情報を手動でインストールできます。

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

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

sudo yum install google-authenticator qrencode-libs

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

次の2つのコマンドを実行して、アプリを初期化します。

google-authenticator -s ~/.ssh/google_authenticator

通常、必要なのは引数なしでgoogle-authenticatorコマンドを実行することだけですが、SELinuxは、sshデーモンがホームフォルダー内の.sshディレクトリ外のファイルに書き込むことを許可しません。 これにより、認証ができなくなります。

SELinuxは、潜在的な攻撃からシステムを保護する強力なツールであり、強制モードで実行する価値があります。 そのため、SELinuxをオフにすることはベストプラクティスとは見なされません。 代わりに、google_authenticatorファイルのデフォルトの場所を~/.sshディレクトリに移動します。

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

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

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

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

残りの質問は、機能する方法について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 authentication server and client. If you
experience problems with poor time synchronization, 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 8 previous codes, the current
code, and the 8 next codes). This will permit for 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 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

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

この設定が完了したら、秘密鍵をバックアップする場合は、~/.ssh/google-authenticatorファイルを信頼できる場所にコピーできます。 そこから、追加のシステムにデプロイするか、クリーンインストール後に再デプロイできます。 複数のマシンで同じキーを使用すると、攻撃者が1つのサーバーのトークンを盗聴し、有効なウィンドウ内で別のサーバーに対してトークンを使用できる場合、リプレイ攻撃の可能性が生じることに注意してください。 すべてのシステムで異なるトークンを使用し、それらの異なるトークンを管理するのではなく、そのリスクの可能性を評価する必要があります。

設定ファイルを非標準の場所に保存したため、新しい場所に基づいてSELinuxコンテキストを復元する必要があります。

これを行うには、次のコマンドを使用します。

restorecon -Rv ~/.ssh/

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

ステップ2— MFA/2FAを使用するようにOpenSSHを構成する

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

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

ファイルをバックアップしてから開きます。

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

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

auth       required     pam_google_authenticator.so secret=/home/${USER}/.ssh/google_authenticator nullok
auth       required     pam_permit.so

google_authenticator構成ファイルを非標準の場所に配置する必要があったため、構成ファイルへのパスをPAMに提供する必要があります。 secretオプションは、構成ファイルのデフォルト以外の場所が保存されている場所をPAMに通知します。

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

ユーザーがログインにMFAトークンを使用しない場合に認証を許可するには、pam_permit.soの2行目が必要です。 各メソッドにログインするときは、認証を許可するためにSUCCESSが必要です。 ユーザーがnullokオプションを使用してMFA認証ツールを使用しない場合、インタラクティブキーボード認証のIGNOREを返します。 したがって、その行が無視されると、次の行がトリガーされ、pam_permit.soがSUCCESSを返し、認証を続行できるようになります。

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

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

SSH構成ファイルをバックアップし、編集のために開きます。

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

ChallengeResponseAuthenticationで始まる行を探します。 no行をコメントアウトし、yes行のコメントを解除します。

ファイルは次のようになります。

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

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

sudo systemctl restart sshd.service

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

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

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

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

sudo nano /etc/ssh/sshd_config

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

. . .
AuthenticationMethods publickey,password publickey,keyboard-interactive

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

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

sudo nano /etc/pam.d/sshd

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

. . .
#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つの認証タイプすべてを適用する場合は、次の手順に従うことができます。

これで、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構成ファイルを開きます。

sudo nano /etc/pam.d/sshd

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

sudo systemctl restart sshd.service

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

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

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

秘密鍵へのアクセスを失う

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

DigitalOcean DropletでTOTP秘密鍵を紛失した後に入るには、ダッシュボードから仮想コンソールを使用して、ユーザー名とパスワードを使用してログインするだけです。 これは、ssh接続用にMFAでのみユーザーアカウントを保護したために機能します。 コンソールログインなどの非ssh接続は、Google認証システムPAMモジュールを使用しません。

Droplet以外のシステムを使用している場合は、アクセスを回復するための2つのオプションがあります。

1. システムへのコンソール（ローカル/非ssh）アクセス（通常は物理的またはiDracなどを介して）
2. MFAが有効になっていない別のユーザーがいる

2番目のオプションは安全性の低いオプションです。MFAを使用するポイントはすべてのssh接続を強化することですが、MFAオーセンティケーターアプリにアクセスできなくなった場合のフェイルセーフの1つです。

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

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

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

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

既存のキーを復元したら、オーセンティケーターアプリに手動で入力してからビジネスに戻るか、以下のURLに関連する詳細を入力して、スキャンするQRコードをGoogleに生成させることができます。 。 このキーと異なるTOTPトークン：

https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/username@hostname%3Fsecret%3D16-char-secret%26issuer%3Dentry-name-in-auth-app

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

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

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

手順6—認証設定の変更（オプション）

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

<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桁のコードを削除します。

手順7—一部のアカウントでMFAを回避する（オプション）

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

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

一部のアカウントにMFAを許可し、他のアカウントにのみSSHキーを許可するには、/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キーのみが使用されるユーザーには実行しないでください。

ステップ8—構成管理によるセットアップの自動化（オプション）

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

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

google-authenticator -t -d -f -r 3 -R 30 -w 3 -s ~/.ssh/google_authenticator

上記で参照されているオプションは次のとおりです。

• -t=>時間ベースのカウンター
• -d=>トークンの再利用を禁止する
• -f=>ユーザーにプロンプトを表示せずに設定をファイルに強制的に書き込む
• -r=>正しいコードの入力を何回試行したか
• -R=>ユーザーが正しいコードの入力を試行できる秒数
• -w =>一度に有効なコードの数（これは、有効なコードの1:30分-4分のウィンドウを参照します）
• -s=>認証ファイルを保存する場所へのパス

これらは、手動で回答したすべての質問に回答し、ファイルに保存してから、秘密鍵、QRコード、および回復コードを出力します。 （フラグ-qを追加すると、出力はありません。）このコマンドを自動化された方法で使用する場合は、秘密鍵や回復コード、あるいはその両方をキャプチャして使用可能にしてください。ユーザーに。 また、自動化によって「.ssh」ディレクトリ（restorecon -Rv ~/.ssh/）のSELinuxコンテキストをリセットすることを忘れないでください。

ステップ9—すべてのユーザーにMFAを強制する（オプション）

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

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

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

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

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

結論

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

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