X2GoをUbuntu PreciseでWiKID二要素認証で保護する
概要
このドキュメントは、WiKID Strong Authentication（商用/オープンソースの二要素認証ソリューション）を使って、X2Goベースのリモートデスクトップ接続に二要素認証を追加する方法を説明します。手順は以下の流れです。
- WiKIDサーバーにドメインを作成する
- WiKIDサーバーに対象のX2Goサーバーをネットワーククライアントとして追加する
- Ubuntu（Precise）側でX2Goをインストールし、PAMでlibpam-radius-authを設定する
用語定義（1行）: WiKID — ワンタイムパスワード生成・検証を行う二要素認証サーバー。PAM — Pluggable Authentication Modules、Linuxの認証モジュール。
重要: 既にSSHゲートウェイでpam-radiusを使用しているサーバーがある場合、同じ設定をX2Goに追加するだけで動作することが多いです。
前提条件
- WiKID Strong Authenticationサーバーがインストールされ、稼働していること（.debパッケージのインストールとセットアップはWiKIDのドキュメント参照）。
- X2Goサーバーとして機能するUbuntu 12.04（Precise）があること。
- 管理者アクセス（sudo）と、対象ユーザーがLinux上にローカルアカウントを持っているか、別途LDAP/AD連携が設定されていること。
- ネットワーク間でUDP/TCPの必要ポート（RADIUSのポート等）が到達可能であること。
WiKIDサーバーにドメインを追加する
まずWiKID管理画面でドメイン（組織や認証の論理的な区切り）を作成します。作成手順の詳細はWiKIDの管理者マニュアルに従ってください。
説明: 上図はWiKID管理画面のドメイン作成フォームのサンプル画面です。ドメイン名や説明を入力して保存します。
ネットワーククライアントの作成
ドメインを保存したら、Network Client タブを開き、Create New Network Client をクリックします。クライアント名と、X2Goサーバーの内部ネットワーク上のIPアドレスを入力します。プロトコルは「Radius」を選択し、先ほど作成したドメインを選びます。
次ページで共有シークレット（shared secret）を設定します。この値は後でUbuntu側のpam_radius設定に入力します。
注意: 共有シークレットは強力なランダム文字列にしてください。ネットワーク上の盗聴対策として十分な長さを確保します。
Ubuntu上でのX2Goのインストール
X2Goサーバーと必要なコンポーネントをインストールします。公式PPAを利用する例を示します。
sudo apt-get install python-software-propertiessudo add-apt-repository ppa:x2go/stablesudo apt-get updatesudo apt-get install x2goserver x2goserver-xsession x2gobroker x2gobroker-daemon x2gobroker-authserviceデスクトップ環境がまだインストールされていない場合は、必要なデスクトップをインストールします（例: UbuntuデスクトップやGNOME）。
sudo apt-get install ubuntu-desktop gnomeユーザー側でクライアントを用意し、X2Goの接続設定でサーバーのIPとインストールしたデスクトップを指定して接続できるかテストします。クライアントは各OS向けのX2Goクライアントを使用してください。
apt-get install x2goclient初期確認は通常パスワード（OTP有効化前の静的パスワード）でログインできることを確認します。
X2GoサーバーでのPAMの設定
ここからはpam-radius（libpam-radius-auth）を導入してWiKIDと連携する手順です。Ubuntuでの手順を示します。
まずパッケージをインストールします。
$ sudo apt-get install libpam-radius-authインストール後、RADIUSサーバー情報を設定するために設定ファイルを編集します。
$ sudo vim /etc/pam_radius_auth.conf注: ファイル内に「/etc/raddb/serverにコピーせよ」といった指示があっても、指示通りに移動しないでください（Ubuntuのパスを使います）。
設定ファイル中のサンプル行（例: “other-server; other-secret 3”）を編集します。’other-server’ をWiKIDサーバーのIPアドレスまたはホスト名に置き換え、 ‘other-secret’ をWiKID管理画面で指定した共有シークレットに変更します。複数サーバーを指定する場合は各行にそれぞれ記載します。
次に、PAMのSSHサービス設定を編集してRADIUS認証を組み込みます。
$ sudo vim /etc/pam.d/sshdそして次の行を追加します（追加場所は以下の指示どおり）。
auth sufficient pam_radius_auth.soこの行を以下の「Standard Un*x authentication.」ブロックの直前に配置します。
# Standard Un*x authentication.
@include common-auth構成のポイント:
- “sufficient” 指定により、RADIUS認証が成功すると残りのauthモジュールをスキップしてログインが許可されます。
- ユーザー名はLinux側とWiKID側で一致している必要があります（認証時の照合キーとして使われるため）。
テスト手順
- サーバー側でログを監視:
tail -f /var/log/auth.log- WiKIDソフトトークン（スマホアプリなど）を起動し、先ほど作成したドメインを選択してPINを入力してワンタイムパスワード（OTP）を取得。
- X2Goクライアントで通常どおりユーザー名を入力し、パスワード欄にOTPを入力して接続を試行。
- auth.logにRADIUS関連のエントリが出力され、認証成功であればログインできるはずです。
注意: ユーザーはローカルに存在する必要があります。LDAP/ADを使う場合はpam_ldap等のモジュールと併用し、認可はディレクトリで行う設計が望ましいです（後述）。
トラブルシューティングのヒント
- 認証失敗でもログに詳細が出ない場合は /var/log/auth.log とWiKIDサーバーのログの両方を確認してください。
- 共有シークレットの不一致、ネットワークフィルタ（ファイアウォール）、またはサーバー名解決の問題が多い原因です。
- PAMの順序ミスでlocal認証が先に実行され、期待するRADIUS動作にならないことがあります。設定箇所と順序を確認してください。
- ユーザー名の大小文字や末尾スペースに注意してください。WiKID側と完全一致である必要があります。
ベストプラクティスと設計上の考慮
- 認証と認可を分離する: RADIUSは認証（OTPの検証）をWiKIDへ委譲し、ディレクトリ（LDAP/AD）で認可（アカウントの有効/無効、グループ権限）を行う構成が管理しやすい。
- 障害時のロックアウト対策: WiKIDサーバーが利用できないとログインができなくなるため、管理用のフェイルオーバー手段（例: 管理者用のローカルアカウントや代替認証経路）を用意する。
- 監査ログとログ保持: auth.logやWiKIDのログを中央ログに集約し、ログ保持ポリシーに従って保全する。
- 共有シークレット管理: RADIUS共有シークレットは適切に保護し、運用変更時は安全にローテーションする。
ロール別チェックリスト
システム管理者:
- WiKIDサーバーの状態を確認（稼働/サービスOK）
- RADIUS共有シークレットを安全に設定
- /etc/pam_radius_auth.conf を編集し、IP/ホスト名とシークレットを正しく入力
- /etc/pam.d/sshd に auth sufficient の行を追加
- auth.log を監視して認証フローを確認
ネットワーク管理者:
- RADIUSのポート（UDP 1812/1813 または環境依存のポート）が到達可能か確認
- FW/NATでのパケット変換がないか確認
セキュリティ管理者:
- ユーザーアカウントの失効/復旧手順を文書化
- 監査・ログポリシーの適用
ミニSOP（運用手順）
- 新しいX2Goサーバーをセットアップし、デスクトップをインストールする。
- X2GoサーバーのIPをWiKID管理画面でNetwork Clientとして登録し、共有シークレットを設定する。
- Ubuntu側で libpam-radius-auth をインストールし、 /etc/pam_radius_auth.conf を編集する。
- /etc/pam.d/sshd に auth sufficient の行を追加する。
- テストユーザーでOTPログインを試行し、auth.logで確認する。
- 問題があればログを確認し、必要に応じてWiKID側の設定（トークンの有効化、ユーザーの状態）を確認する。
Критерии приёмки
- 管理者ユーザーがWiKIDトークンで正常にX2Go接続できること。
- auth.log およびWiKIDサーバーのログで認証成功が確認できること。
- 共有シークレットが安全に保存され、設定ファイルに反映されていること。
- 事業継続計画に基づくフェイルオーバーまたは管理者用の代替アクセス手段が文書化されていること。
リスクと緩和策
リスク: WiKIDサーバー障害により全ユーザーがログインできなくなる。
- 緩和策: 管理者用ローカルアカウント保持、WiKIDの冗長構成、RADIUSフェイルオーバー設定。
リスク: 共有シークレットが漏洩。
- 緩和策: シークレットの運用ポリシー、定期ローテーション、アクセス制御。
リスク: ユーザー名不一致による認証失敗。
- 緩和策: ユーザープロビジョニング手順の整備、ディレクトリ連携の標準化。
追加の運用上メモ
- ディレクトリと連携する場合: PAM RADIUS は認証のみを担当し、ディレクトリ（LDAP/AD）での認可を行う設計が望ましい。これにより、ユーザー無効化やグループベースの権限管理が容易になります。
- セキュリティ強化: SSHの設定（PermitRootLoginの無効化、公開鍵認証との併用など）も併せて検討してください。
まとめ
- WiKIDとX2Goの組み合わせで、リモートデスクトップに有効な二要素認証を導入できます。
- 主な作業はWiKID側でのネットワーククライアント設定と、Ubuntu側でのlibpam-radius-auth設定の2点です。
- 運用上は認証と認可の分離、ログ監査、フェイルオーバー対策を講じてください。
重要: 本手順はUbuntu 12.04（Precise）向けの手順を前提としています。ディストリビューションやバージョンが異なる場合は、パッケージ名やパスが異なる可能性があるため注意してください。
