LinOTP + RADIUS。 ワンタイムパスワード認証

1.基本情報

このマニュアルでは、CentOSベースのマシンでLinOTPとFreeRadiusを統合する方法、およびGoogle Authenticatorソフトウェア（または同様のアルゴリズムを使用する人）を使用して生成されたOTPを使用してSSHユーザー認証を構成する方法について説明します。

2.ソースデータ

このマニュアルは、CentOS 6.7を実行する3台のマシンがあることを意味します。 それらは同じサブネット上にあり、それらの間でネットワーク接続が構成されています。 マシンの名前とアドレスは次の表に示されています。

 ホスト名IPアドレス条件名オペレーティングシステム
 linotp 10.1.0.114 LinOTP CentOS 6.7サーバー
 radius-p 10.1.0.122 RADIUS CentOS 6.7サーバー
クライアント10.1.0.113クライアントCentOS 6.7
 admin-PC 10.1.0.120 Workstation（AWP）Windows 7 

Linotpソフトウェアは、公式Webサイトの指示に従ってLinOTPサーバーに展開されます（ 「LinOTPサーバーのインストール」ドキュメント ）。 Linotpソフトウェアバージョン2.7.2。



RADIUSサーバーにfreeradiusサーバーが展開されます。 パッケージのインストールについては詳しく説明しません。 yumマネージャーで簡単に実行されます。 インストールに必要なパッケージの完全なリストを以下に示します。

• freeradius-2.2.6-6.el6_7.i686;
• freeradius-perl-2.2.6-6.el6_7.i686;
• perl-devel-5.10.1-141.el6.i686;
• perl-Pod-Escapes-1.04-141.el6.i686;
• perl-version-0.77-141.el6.i686;
• perl-Test-Harness-3.17-141.el6.i686;
• perl-ExtUtils-ParseXS-2.2003.0-141.el6.i686;
• perl-Digest-SHA-5.47-141.el6.i686;
• perl-libs-5.10.1-141.el6.i686;
• perl-Module-Pluggable-3.90-141.el6.i686;
• perl-5.10.1-141.el6.i686;
• perl-ExtUtils-MakeMaker-6.55-141.el6.i686;
• perl-DBI-1.609-4.el6.i686;
• perl-CPAN-1.9402-141.el6.i686;
• perl-Pod-Simple-3.13-141.el6.i686

クライアントマシンは、OTP認証が行われるRADIUSクライアントです。 RADIUS認証をサポートするために、pam_radius-1.3.17-2.el5パッケージがマシンにインストールされます。

Windows自動ワークステーションマシンは、OTPを使用してSSH経由でクライアントマシンにアクセスする管理者ワークステーションを模倣します。 このマシンにはWindows 7、SSHパテクライアントおよびGAUTHソフトウェア-OTPジェネレーターがあります。

3.結果として得られるもの

この作業の目的は、OTP（LinOTPサーバーで生成）を使用して、RADIUSサーバーを介してクライアントで認証を構成することです。



この構成のRADIUSサーバーは、ユーザーアカウントをデータベースに保存しません-このタスクはLinOTPサーバーに割り当てられます。 RADIUSサーバーは、NASベース、つまり ユーザーを認証するサーバーとネットワーク機器のリスト。 この構成では、構成テキストファイル/etc/raddb/clients.confがこれに使用されます。



この構成のLinOTPサーバーは、ユーザートークンの管理に役立ちます。 ユーザーとそのトークンに関する情報は、MySQLデータベースに保存されます。MySQLデータベースはLinOTPサーバーにも展開されます。 linotpソフトウェア自体にはUZユーザーを管理する機能がないため、ユーザーとそのデータをMySQLテーブルに手動で追加する必要があります。

4.セットアップ手順

4.1。 RADIUS設定手順

このセクションで説明する設定は、RADIUSサーバーで行われます。 radius-pマシン。

4.1.1。 追加のPerlモジュールのインストール

# perl -MCPAN -e shell cpan[1]> install LWP cpan[1]> install LWP:UserAgent cpan[1]> install LWP:UserAgent:Determined cpan[1]> install LWP::Protocol::https
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インストールされているモジュールの一部は、インストール中に次のエラーを生成する場合があります。

  make installを実行する
   makeテストが不良ステータスを返したため、強制的にインストールしない
このコマンド中に失敗しました：
  MSCHILLI / LWP-Protocol-https-6.06.tar.gz：make_test NO 

この場合、次のようにforce installコマンドを使用します。

 cpan[1]> force install LWP::Protocol::https
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のようなメッセージ：

 このコマンド中に失敗しました：
  MSCHILLI / LWP-Protocol-https-6.06.tar.gz：make_testは失敗しましたが、「force」が有効であるため失敗は無視されました 

4.1.2。 半径の設定

radiusクライアントNASを/etc/raddb/clients.confファイルに追加します。 私たちの場合、それは次のとおりです。

 クライアント10.1.0.113 {
        秘密= testing123
        ショートネーム=クライアント
 } 

ファイル/ etc / raddb / usersに次の行を追加します

 デフォルトの認証タイプ：= perl 

***ただし、これは最適なオプションではありません。 この場合、認証タイプを強制的に設定します。これにより、半径が、たとえばmysqlに保存され、linOTPを介して認証されたユーザーとともにRADIUSで構成されたユーザーを認証できなくなります。

実際には、私はちょうどこの状況に直面しました。 この場合、このディレクティブ（DEFAULT Auth-type：= perl）を記述する必要はありませんが、代わりに条件がauthorizeセクションの/ etc / raddb / sites-enabled / defaultファイルに追加されました。

  if（Sql-Group == sql）{pap} 
           else {更新制御{ 
                                  Auth-Type：= perl 
                                  } 
                  } 

この条件（radiusに組み込まれたunlang言語で記述）には、sqlで認証されたユーザーグループのメンバーではないユーザーの認証タイプ「perl」のみが含まれます。





ファイル/ etc / freeradius / modules / perlで、次のディレクティブを変更します。

  perl {
          module = <linotp_radius.pmファイルへのパス> 

ファイル/ etc / freeradius / sites-enabled / defaultで、「認証」セクションを次のように変更します。

 認証する{
 perl 

4.1.3。 linotp_radius.pmコネクタファイルの作成

次の内容のlinotp_radius.pmファイルを作成します。

 #________START______ use strict; use LWP; use LWP::UserAgent::Determined; # use ... # This is very important ! Without this script will not get the filled hashesh from main. use vars qw(%RAD_REQUEST %RAD_REPLY %RAD_CHECK $URL); use Data::Dumper; $ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0; $URL = "https://<IP   LinOTP>/validate/simplecheck"; # This is hash wich hold original request from radius #my %RAD_REQUEST; # In this hash you add values that will be returned to NAS. #my %RAD_REPLY; #This is for check items #my %RAD_CHECK; # # This the remapping of return values # use constant RLM_MODULE_REJECT=> 0;# /* immediately reject the request */ use constant RLM_MODULE_FAIL=> 1;# /* module failed, don't reply */ use constant RLM_MODULE_OK=> 2;# /* the module is OK, continue */ use constant RLM_MODULE_HANDLED=> 3;# /* the module handled the request, so stop. */ use constant RLM_MODULE_INVALID=> 4;# /* the module considers the request invalid. */ use constant RLM_MODULE_USERLOCK=> 5;# /* reject the request (user is locked out) */ use constant RLM_MODULE_NOTFOUND=> 6;# /* user not found */ use constant RLM_MODULE_NOOP=> 7;# /* module succeeded without doing anything */ use constant RLM_MODULE_UPDATED=> 8;# /* OK (pairs modified) */ use constant RLM_MODULE_NUMCODES=> 9;# /* How many return codes there are */ # Function to handle authorize sub authorize { # For debugging purposes only # &log_request_attributes; # Here's where your authorization code comes # You can call another function from here: &test_call; return RLM_MODULE_OK; } # Function to handle authenticate sub authenticate { # For debugging purposes only # &log_request_attributes; my $ua = LWP::UserAgent->new(); my $req = HTTP::Request->new(GET => $URL . "?user=" . $RAD_REQUEST{'User-Name'} . "&pass=" . $RAD_REQUEST{'User-Password'} ); my $response = $ua->request( $req ); die "Error at $URL\n ", $response->status_line, "\n Aborting" unless $response->is_success; if($response->content =~ m/:\-\)/i) { return RLM_MODULE_OK; } else { $RAD_REPLY{'Reply-Message'} = "LinOTP server denied access!"; return RLM_MODULE_REJECT; } } # Function to handle preacct sub preacct { # For debugging purposes only # &log_request_attributes; return RLM_MODULE_OK; } # Function to handle accounting sub accounting { # For debugging purposes only # &log_request_attributes; # You can call another subroutine from here &test_call; return RLM_MODULE_OK; } # Function to handle checksimul sub checksimul { # For debugging purposes only # &log_request_attributes; return RLM_MODULE_OK; } # Function to handle pre_proxy sub pre_proxy { # For debugging purposes only # &log_request_attributes; return RLM_MODULE_OK; } # Function to handle post_proxy sub post_proxy { # For debugging purposes only # &log_request_attributes; return RLM_MODULE_OK; } # Function to handle post_auth sub post_auth { # For debugging purposes only # &log_request_attributes; return RLM_MODULE_OK; } # Function to handle xlat sub xlat { # For debugging purposes only # &log_request_attributes; # Loads some external perl and evaluate it my ($filename,$a,$b,$c,$d) = @_; &radiusd::radlog(1, "From xlat $filename "); &radiusd::radlog(1,"From xlat $a $b $c $d "); local *FH; open FH, $filename or die "open '$filename' $!"; local($/) = undef; my $sub = <FH>; close FH; my $eval = qq{ sub handler{ $sub;} }; eval $eval; eval {main->handler;}; } # Function to handle detach sub detach { # For debugging purposes only # &log_request_attributes; # Do some logging. &radiusd::radlog(0,"rlm_perl::Detaching. Reloading. Done."); } # # Some functions that can be called from other functions # sub test_call { # Some code goes here } sub log_request_attributes { # This shouldn't be done in production environments! # This is only meant for debugging! for (keys %RAD_REQUEST) { &radiusd::radlog(1, "RAD_REQUEST: $_ = $RAD_REQUEST{$_}"); } } 1; #___________END
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このファイルは/ etc / raddb /フォルダーに配置されましたが、別の場所に配置することができます。覚えておくべき主なことは、このファイルへのパスを/ etc / freeradius / modules / perl（上記）に書き込む必要があることです。



この段階で、コマンド/ usr / sbin / radiusd –Xを使用してradiusを正常に開始し、radiusクライアントに接続しようとすると、LinOTPサーバーに要求を送信する必要があります。 これは、sshを介してクライアントに接続し、同時にTCPDUMPを使用してLinOTPサーバー上のトラフィックをリッスンすることで確認できます。 ポート443 TCPでパケットが表示されるはずです。

4.2。 LinOTPのセットアップ手順

LinOTPは、開発者の公式ドキュメントに従って構成されました（ LinOTPドキュメント-クイックスタートガイドを参照 ）。



LinOTP自体にはユーザーを作成する機能はありません。LDAP、MySQL、またはテキストファイルからユーザーのKM（ユーザーアカウント）に関する情報のみを読み取ることができます。 この指示は、米国の拠点としてLinOTPと同じサーバーにデプロイされたMySQLを使用することを前提としています。

4.2.1。 ユーザー超音波のベースの形成

LinOTPサーバーの初期初期化中にuseridresolver（これは単なる指示、KMデータベースへの一種の「コネクタ」であり、LinOTPがユーザーデータを取得する）を作成する場合、SQLデータテーブルとユーザーデータ「password」のマッピングでパスワードフィールドを指定する必要があります。 このパスワードは、セルフサービスポータルへのユーザーアクセスにのみ必要です。 このポータルを使用する予定がない場合は、これを省略できます。



これが初期化段階で行われなかった場合は、accを追加できます。 テーブルの列。 例：

ALTER TABLE usertable ADD password VARCHAR（200）;



次に、コマンドを使用してユーザーのパスワードハッシュを生成します。

 /opt/LINOTP/bin/linotp-create-sqlidresolver-user -u < > -i <  id  > -p < >
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

出力では、次の形式の行を取得します。

  user7; 2; {SSHA512} 3QWyB5u2TkPLDc2mjIJxtcCLOVHSjLS / MyYjPGNIENchm5riFHF3M9CW7csaxADAFml8WkH / Whd1A047nUAaeWk2dFZod1ZhYzN3cTRNUkpRdlhrLmVsdFVSeUNIaUdWVEZVT1ZycW5BSlVXajVHbHVvckhHSmNYOWp5M3FQLi8 =。 

黄色で強調表示されているのは、受信したパスワードハッシュのみです。 次に、テーブルの適切なフィールドに追加します。

 ユーザーテーブルの設定パスワードを更新= <hashの取得方法> where user = 'user7'; 

私の例では、useridresolverの構成は次のようになります。





図1-Useridresolverの構成例



図では完全に表示されていない「属性マッピング」フィールドに特に注意を払う必要があります。 その内容は次のとおりです。

  {"userid"： "id"、 "username"： "user"、 "email"： "mail"、 "surname"： "sn"、 "givenname"： "givenName"、 "password"： "password"} 

以下はMySQLテーブル（LinOTPサーバーにあります）で、UZユーザーが保存され、マッピングが構成されています。

  mysql> select * from usertable;
 + ---- + ------- + ------------------------ + -------- +- --------- + ----------- +
 |  id | ユーザー| メール|  sn |  givenName |パスワード|
 + ---- + ------- + ------------------------ + -------- +- --------- + ----------- +
 |  1 |  user6 |  user6@loc​​aldomain.mail | イワン| ペトロフ| <ハッシュ> |
 |  2 |  user7 |  user7@localdomain.mail | セルゲイ|  fedorov | <ハッシュ> |
 + ---- + ------- + ------------------------ + -------- +- --------- + ----------- + 

追加のコメントは不要だと思います。 useridresolverの「userid」フィールドは、MySQLデータベースの「id」フィールドにマップされます。 useridresolverのユーザー名フィールドは、MySQLデータベースなどのユーザーフィールドです。

そして最後に、「ユーザービュー」タブに移動して、LinOTPインターフェイスに表示されるものを次に示します。





図2-LinOTPインターフェースでのユーザーの表示

4.2.2。 LinOTPポリシーを構成する

ポリシーはLinOTPの重要な要素であり、認証オプション、トークンの数の種類と制限などを柔軟に構成できます。



LinOTPの動作を実証するには、次の一連のポリシーで十分です。





図3-トークン割り当てポリシー



このポリシーは、ユーザーに発行できるトークンの最大数-「maxtoken」パラメーターを定義します。





図4-セルフサービスポータルポリシー



このポリシーは、ユーザーがセルフサービスポータルを介して独立して実行できるトークンとトークンの操作の種類を規制します。





図5-システムポリシー



管理者によるシステム設定の読み取りと変更に必要な権限（scope = systemに追加設定を設定して管理者を制限することは理にかなっています）。





図6-認証ポリシー



このポリシーでは、ターゲットシステム（クライアント）での認証中にOTP-PINとOTPのエントリが必要です。 これは、otppin = 0パラメーターが原因です。 「2」に設定すると、認証はOTPのみを通過します。 「1」に設定すると、ユーザーパスワードとOTPの組み合わせを使用して認証が行われます（パスワードはセルフサービスポータルへのアクセスと同じです）。



例：パラメーターotppin = 0; ユーザーuser3には、OTP-PIN = 123456で生成されたOTP = 234567のトークンがあります。 この場合、クライアントssh経由でアクセスするときのuser3のパスワードは、<OTP-PIN>のようになります。 123456234567。

4.2.3。 ユーザー用のトークンの作成

LinOTPがユーザーKDデータベースに接続され（useridresolverが構成され）、ポリシーの最小セットが作成された後、ユーザーのトークンの作成に進むことができます。

[ユーザービュー]タブに移動し、トークンを作成するユーザーを選択します。 左側のメニューで、[登録]ボタンをクリックします。 ウィンドウが開き、新しいトークンの設定が表示されます。





図8-トークンの作成



トークンタイプ -トークンタイプ。 多くの異なるトークンがサポートされています。 （この例で使用する）Google認証システムをサポートするには、「HMAC時間ベース」を選択します。 このタイプのトークンは、現在の時刻（TOTRと呼ばれることもある）に関連付けられたワンタイムパスワード（OTP）を生成します。 ここから、すべてのマシン（RADIUSサーバー、LinOTPサーバー、クライアント）の時刻同期の要件に従います。

トークンシード -ランダムシーケンス（この例で行われた）の生成を要求できます-「ランダムシードの生成」または独自の「シードの入力」を設定します。

トークン設定-Google認証システムをサポートするには、「Google認証システムに準拠」チェックボックスをオンにします。そうでない場合は、OTPトークン「OTPディジット」によって生成されるOTPトークンの長さを設定できます。使用されるアルゴリズムは「ハッシュアルゴリズム」です。 「タイムステップ」。

トークンの任意の説明-「説明」-空白のままにすることができますが、影響はありません。

トークンピン -このトークンのピンコード。 Google認証システムで少なくとも6桁。

必要なデータをすべて入力したら、[登録]ボタンをクリックします。 トークンが作成されました。



トークンに関する情報を示すウィンドウが表示されます。モバイルデバイスにインストールされたGoogle認証システムアプリケーションによって読み取られるトークンのQRコード、およびWindowsで実行されているGAUTHソフトウェアクライアントにトークンをインポートするために必要なシークレットを含む行。

ウィンドウの下部にある「otpauth：// totp / TOTP ....」という形式の行をコピーして保存します。 WindowsでOTPクライアントを構成するときに必要になります。





図9-作成されたトークン



その後、ウィンドウを閉じることができます。 このトークンは、LinOTPインターフェイスの「トークンビュー」タブのトークンのリストに表示されます。

4.3。 顧客のセットアップ手順

4.3.1。 必要なソフトウェアをインストールする

RADIUSを介したクライアント認証をサポートするには、クライアントにlibpam-radius-authパッケージをインストールする必要があります（この例では10.1.0.113）。 これもyumマネージャーを使用して行われます。

4.3.2 RADIUSを介したクライアント認証の構成

RADIUSサーバーを介して認証を構成する必要があります。 これを行うには、/ etc / pam_radius_auth.confファイルの「other-server other-secret 3」の行を編集します。 「その他のサーバー」をRADIUSサーバーのIPアドレスに置き換えます。 10.1.0.122、およびセクション4.1.2で指定されたシークレットの「other-secret」、つまり 「Testing123」。 結果は次のとおりです。

  10.1.0.122 testing123 3 

ファイル/etc/pam.d/sshdを編集します。 次の行を追加します。

 十分な/lib/security/pam_radius_auth.so 

線の上

  ＃標準Un * x認証。
 @include common-auth 

また、トークンが作成されたLinOTP上のユーザーと同じ名前で、クライアント上にユーザーアカウントを作成する必要があります。 この例では、user7。

  useradd –m –d / home / user7 user7 

4.3.3。 ワークステーションのセットアップ手順

ワークステーションに、GAUTHなどのOTPジェネレーターをインストールする必要があります。 このソフトウェアはこちらから入手できます。 ダウンロードしたアーカイブに含まれるインストーラーファイルからインストールされます。 インストールプロセスは簡単です。

インストール後、以下の説明に従ってレジストリのキーを修正することをお勧めします。 この編集を行わなくても、ソフトウェアは動作しますが、起動時にエラーが発生し、目には喜ばれません。 これは、このソフトウェアのFAQに記載されているGAUTHバグです。

keyという名前のString型のパラメーターを次のブランチに追加する必要があります。

HKEY_CURRENT_USER \ Software \ GoogleAuth \ GoogleAuth \ 1.0.0。

その後、START-プログラム-Google Authを使用してGAUTHクライアントを起動します。 対応するアイコンがトレイに表示されます。 マウスの右ボタンでそれをクリックし、「キーの変更」を選択します。 開いたウィンドウで、トークンの作成中に保存された文字列からシークレットを挿入します。

サンプル行：otpauth：// totp / TOTP00013B2A？Secret = APY ***** JH＆counter = 0

この場合、挿入されるシークレットは次のとおりです。

APY ***** JH

「キーを保存」をクリックします。





図10-GAUTHへのシークレットのインポート



これで、トレイのアイコンにカーソルを合わせると、6桁のOTPが表示され、その横の括弧内にこのOTPが有効になる時間が表示されます。





図11-生成されたOTP

5. OTPを使用した認証の検証

クライアントワークステーションでSSH「putty」を起動します。 クライアントに接続されています（この例では10.1.0.113）。 トークンが作成されたユーザーの名前（この例ではuser7）を示し、パスワードとしてスペースとダッシュなしで<OTP-PIN>を1語で入力します（たとえば、123456665494、123456はPIN、665494は生成されたOTP）。

すべてが正しく行われた場合、すべてのサーバーとワークステーションのクロックが同期され、user7ユーザーアクセスが承認される必要があります。