テクノロジーガイド

CentOS 7でWiKID二要素認証を使ってSSHを強化する

2 min read セキュリティ 更新されました 03 Oct 2025
CentOS 7でWiKID二要素認証によるSSH強化
CentOS 7でWiKID二要素認証によるSSH強化

概要

SSHはリモート管理の標準手段ですが、監査(例: PCIなど)では認証周りの制約が問題になることがあります。代表的な課題:

  • 公開鍵認証を持つユーザーの管理が難しい
  • パスフレーズの複雑さや存在を強制できない
  • 公開鍵の有効期限を設定できない

このガイドでは、WiKID Strong Authentication Systemを用いてCentOS 7(RHEL系)上でSSHに二要素認証を導入する手順を示します。手順は以下の流れです:

  1. WiKIDサーバーでドメインを作成
  2. そのドメインに対してネットワーククライアント(対象サーバー)を登録
  3. CentOS 7側でpam_radiusをインストールしてPAM設定を行う

重要: 本手順はシステム構成や運用ポリシーによって調整が必要です。事前にバックアップとリカバリ手順を用意してから実施してください。


前提条件

  • CentOS 7が稼働していること
  • 管理者権限(sudo)が使えること
  • WiKIDサーバーがネットワーク上で到達可能であること
  • WiKIDの管理者アクセス情報があること

WiKIDサーバーにドメインを追加する

まずWiKID管理画面で新しいドメイン(domain)を作成します。ドメインのServer Codeは外部IPアドレスをゼロパディングした形式で指定します。例: IPが54.83.0.181ならServer Codeは054083000181です。

WiKID管理画面でドメインを追加するスクリーンショット

重要: Server Codeの形式はWiKIDの仕様に従ってください。ドメイン定義はユーザーやトークンの管理境界になります。

ネットワーククライアントを作成する

ドメインを保存したら「Network Client」タブで新しいネットワーククライアントを作成します。以下を指定します:

  • Name: 任意の識別名
  • IP Address: SSHゲートウェイまたは対象サーバーの内部IP
  • Protocol: Radius
  • Domain: 先ほど作成したドメイン

WiKIDでネットワーククライアント作成画面のスクリーンショット

Addをクリックして次へ進み、RADIUS共有シークレットを設定します。

RADIUS共有シークレット入力画面のスクリーンショット

この操作をネットワーク内の対象ホストごとに繰り返します。

重要: 共有シークレットは各ネットワーククライアントごとに安全に管理してください。運用上はシークレットのローテーション計画を用意します。

CentOS 7でSSHを設定する

ここから対象CentOS 7マシン上でpam_radiusをビルド/インストールしてPAM連携を行います。各ディストリビューションでPAMの扱いが微妙に異なる点に注意してください。

まずソースのtarファイルをダウンロードします(現時点の記事ではバージョン1.3.17を例示)。

$ wget ftp://ftp.freeradius.org/pub/radius/pam_radius-1.3.17.tar.gz

展開します:

$ tar -xzvf pam_radius-1.3.17.tar.gz

PAM開発ヘッダをインストールします:

$ sudo yum install pam-devel

ソースディレクトリに移動してmakeします:

$ make

ビルド中に警告やエラーが出る場合がありますが、pam_radius_auth.soが生成されていれば次へ進めます。アーキテクチャに応じてライブラリを配置します。

32ビットの場合:

$ sudo cp pam_radius_auth.so /lib/security/

64ビットの場合:

$ sudo cp pam_radius_auth.so /usr/lib64/security/

SSHでRADIUSを使うように設定する

SSHのPAM設定にRADIUSを追加します。sshdが参照するPAMファイル(/etc/pam.d/sshd)を編集します。 auth行の先頭に以下を追加すると、RADIUSを認証方法に含めます(行頭に追加する位置は既存のPAM設定との兼ね合いで調整してください)。

auth    sufficient    /lib/security/pam_radius_auth.so

解説:

  • sufficient: この行で認証に成功すれば以後のauthスタックはスキップされ、ログインが許可されます。テスト中はsufficientのままにしておくのが安全です。
  • required: 必ずこのモジュールを通す場合に使います。既存のパスワード認証を無効にしたい場合はrequiredに変更しますが、遠隔サーバーでは接続不能リスクが高まるため慎重に。

重要: この設定はまだローカルアカウントの存在を前提としています。中央LDAP/ADでアカウント管理する場合はpam_ldap等のモジュールと組み合わせてください。

PAMにRADIUSサーバー情報を登録する

pam_radiusが参照する設定ファイルは通常 /etc/pam_radius_auth.conf です。ファイルがない場合は作成します。

例(行の書式):

 <共有シークレット> 3

例:

192.0.2.10 my_shared_secret 3

ここで最後の数字はタイムアウトやリトライの意味合いで利用されます(実装による)。WiKIDサーバーのIPと先ほど設定した共有シークレットを正しく記載してください。

設定変更後はsshdを再起動する前に、別セッションでテストを行うか、保険としてroot用の別接続経路を確保してください。

テストとトラブルシューティング

テスト手順の一例:

  1. 管理端末でローカルからSSH接続を試す
  2. 同時に別端末でログを監視する:
$ sudo tail -f /var/log/secure
  1. WiKIDトークン(ワンタイムパスコード)とPINを使ってログインしてみる

トラブルシュートのヒント:

  • /var/log/secureに拒否理由が出力されることが多い
  • ネットワーク接続(UDP/TCPのポートやファイアウォール)を確認する
  • 共有シークレットが一致しているか確認する
  • pam_radius_auth.soが正しいパスに置かれているか確認する

ロールバック手順(万が一アクセス不能になった場合):

  • コンソールアクセスや別の管理経路(KVM、クラウドのシリアルコンソール)から /etc/pam.d/sshd を元に戻す
  • 事前に設定ファイルのバックアップを取ること

運用上のベストプラクティス

  • WiKID側でユーザー無効化が容易なので、退職者や不正検出時は即時無効化する
  • 共有シークレットは強力に管理し、定期的にローテーションする
  • RADIUSサーバーの冗長化を検討する(単一障害点にならないように)
  • ログの保管と監査証跡を整備する

運用者・監査人・管理者別チェックリスト

管理者チェックリスト:

  • WiKIDでドメインとネットワーククライアントを作成した
  • 各サーバーにpam_radius_auth.soを設置した
  • /etc/pam_radius_auth.confに正しいRADIUS情報を記載した
  • 設定変更前にバックアップを取得した

運用者チェックリスト:

  • ログ監視(/var/log/secure)を設定した
  • 認証失敗アラートを設定した
  • 障害発生時のロールバック手順を把握している

監査人チェックリスト:

  • 二要素認証が有効なことを確認した
  • ユーザーの無効化/認可フローを確認した
  • ログ保管ポリシーとアクセス証跡を確認した

簡易判断ツリー

以下はRADIUSをsufficientのままにするかrequiredにするかの判断の簡易フローです。Mermaidでの図:

flowchart TD
  A[テスト環境で動作確認済み?] -->|いいえ| B[継続してsufficientのままテスト]
  A -->|はい| C[運用で切替の準備ができている?]
  C -->|いいえ| B
  C -->|はい| D[switch to required の実施]
  D --> E[モニタで成功を確認]
  E --> F[本番切替完了]

受け入れテスト(サンプル)

  • 正常系: ローカルアカウントによるSSHログインでWiKIDトークン+PINでログインできる
  • 異常系: 共有シークレットが不一致の場合、ログにRADIUSエラーが出る
  • フェイルオーバー: RADIUS無応答時にロールバック手順で接続復旧ができる

代替アプローチと考慮点

  • LDAP/ADと連携して認可(アカウントの有効/無効)を集中管理する
  • 公開鍵 + RADIUS OTPを組み合わせる(公開鍵で第1要素、RADIUSで第2要素)
  • 商用の二要素ソリューション(既存のIDプロバイダ)を検討する

利点と限界:

  • 利点: ワンタイムパスコードとPINで強力な二要素が実現できる。ユーザーの無効化が容易。
  • 限界: RADIUSサーバーの可用性やネットワーク要件が追加される。導入時に十分なテストが必要。

まとめ

CentOS 7におけるSSHの二要素化は、WiKIDとpam_radiusを組み合わせることで比較的短時間に導入できます。本番適用前にテスト環境で十分な検証を行い、監査要件や運用フローに合わせてRADIUSの権限境界とログ保管を整備してください。

重要: 本手順は事前にバックアップとリカバリ手順を準備した上で実行してください。遠隔サーバーでは接続不能リスクを常に考慮すること。


参考リンク:

共有する: X/Twitter Facebook LinkedIn Telegram
著者
編集

類似の素材

Debian 11 に Podman をインストールして使う
コンテナ

Debian 11 に Podman をインストールして使う

Apt-pinning入門:Debianで複数リポジトリを管理
Linux

Apt-pinning入門:Debianで複数リポジトリを管理

OptiScalerでFSR 4を全対応ゲームに導入する方法
ゲーム

OptiScalerでFSR 4を全対応ゲームに導入する方法

Dansguardian と Squid(NTLM)を Debian Etch に導入する方法
ネットワーク

Dansguardian と Squid(NTLM)を Debian Etch に導入する方法

AndroidでSDカードのインストールエラーを修正する方法
トラブルシューティング

AndroidでSDカードのインストールエラーを修正する方法

KNetAttach と KDE の remote:/ でネットワークフォルダーを設定
Linux ネットワーク

KNetAttach と KDE の remote:/ でネットワークフォルダーを設定