1. はじめに
前回は、ssh接続を前提としたファイル転送について、sftpおよびscpを使用した転送の実際を解説しました。また、接続時のパスワードを指定できるlftpについても取り上げました。ssh接続の暗号化トンネルを使うことにより、安全にファイルを送受信できることがお分かりいただけたと思います。
また、ssh + sftp / scpを使えば、PCとIBM i 間や、IBM i 同士だけでなく、sshをサポートしているクラウド・サーバーやサービスなどともデータ交換を行うことができそうだということも実感いただけたのではないでしょうか。外部サーバーとの連携は、基幹システムであるIBM i にとっても既に必須の機能です。既存システムを利用しつつ、外部サーバーとのデータ連携を IBM i の OSS 機能だけで実現できるということを理解しておくことは、これからも IBM i を使用していく上でとても重要な視点だと考えています。
さて、今回は「クライアント認証とsyslog」と題して、皆さんに情報をお届けしていきたいと思います。よりセキュリティーを重視したssh接続の方法と、セキュリティーの観点におけるログの重要性を理解していただき、ssh接続ログを収集するsyslogの仕組みと設定方法について解説します。
それでは始めていきましょう。
2. sshのパスワード認証の問題点
ssh接続時の認証については、［sshの仕組みをきちんと理解する］で解説しましたが、ここで少し復習をしておきましょう。
ssh は接続時にサーバーの認証およびクライアントの認証を行います。これは、
- 現在接続しているサーバーが、正しいサーバーか（クライアント側で認証）
- 現在接続要求をしてきているクライアントは、正しいユーザーか（サーバー側で認証）
を確認するためのものです。
サーバー認証
サーバー認証に関しては、［sshの仕組みをきちんと理解する］で解説した通り、以下の手順で正しいサーバーであることを確認します。
- 事前に、サーバーの公開鍵のフィンガー・プリントを入手する
- sshでサーバーに初回接続時に表示されるフィンガー・プリントと、事前に入手したフィンガー・プリントが同一かを確認する
フィンガー・プリントが同一であれば、事前に確認したサーバーそのものに、クライアント側がsshで接続していると確信できます。
さらに、接続時に送られてきたサーバーの公開鍵をクライアント側で同じ一方向性ハッシュ関数で計算し、上記のそれと同じであればその公開鍵は改ざんされていないサーバーの公開鍵であることが確認できます（フィンガー・プリントは一方向性ハッシュ関数で求められることを思い出してください）。
この時点で送信されてきたサーバーの公開鍵を、クライアントの ~/.ssh/known_hosts ファイルに保存します。
2回目以降は、サーバー側の公開鍵を known _hosts ファイルに持っているので、
- クライアントが乱数を生成してサーバーに送付
- サーバーは自分の秘密鍵を使って乱数を暗号化しクライアントに送り返す
- クライアントはサーバーの公開鍵を使って受け取ったデータを復号化し、自分が送った乱数と比較する
そして、比較の結果が同じであれば、自分が持っているサーバーの公開鍵とペアの秘密鍵を、現在アクセスしているサーバーが持っているということになり、これが正しいサーバーにアクセスしていることの証明となるのです。ここまでの手順が、サーバー認証です。
クライアント認証
次に、クライアント認証について考えましょう。
先ほども書いた通り、クライアント認証とは、サーバー側が「現在接続しているユーザーが、正しいユーザーか」を検証するステップです。IBM i では、あらかじめ作成されたユーザー・プロファイルに設定されているパスワードを知っていることを「正しいユーザーである」根拠として、サインオン等で使用されています。
これまでの連載でも ssh接続する際には
C:¥Users¥ogawa>ssh ogawa@172.23.0.238 ogawa@172.23.0.238's password: $
のように、ssh接続後にパスワード入力が求められていました。ここで、「正しいパスワードを知っている人」＝「正しいユーザー」であるとの仮定のもと、ssh接続が許可されていました。これを、パスワード認証といいます。
しかし、パスワード認証は、厳密には問題があります。それは、総当たり攻撃（ブルートフォース攻撃）の可能性です。パスワード認証の場合は、ユーザーのパスワードを知らない（そのユーザー自身ではない）としても、パスワードの組み合わせを試すことで認証されてしまう可能性が、僅かであるにせよ残されています。
IBM i は、設定により最大128文字のパスフレーズをパスワードとして利用することが可能ですが、多くのユーザーはパスワードの桁数を最大10文字で運用しているのが現状です。この「最大」というところが重要で、10文字分を使ってパスワードを設定しているという方は、もしかすると多くはないかもしれません。そして、使用している文字数が少なければ、当然ながら総当たりの回数も少なくて済んでしまいます。
IBM i の場合は、最大サインオン試行回数を設定する QMAXSIGN システム値があり、設定された回数サインオンを失敗すると、ユーザーそのものを使用不可にする（QMAXSGNACN システム値で制御）機能があります。これは、ssh接続時のパスワード入力にも適用されるため、ブルートフォース攻撃を無制限に試すことは事実上できません。QMAXSIGN に 3 が設定されていれば、3 回パスワードを間違えればユーザーが使用不能になり、権限のあるユーザーがそのユーザーを再度使用可能に設定しない限り、そのユーザーを使って ssh で接続することができなくなります。
C:\Users\ogawa>ssh ogawa@172.23.0.238 ogawa@172.23.0.238's password: Permission denied, please try again. ogawa@172.23.0.238's password: Permission denied, please try again. ogawa@172.23.0.238's password: ogawa@172.23.0.238: Permission denied (publickey,password,keyboard-interactive). C:\Users\ogawa>
（この時点で、ユーザー ogawa は使用不能）
とはいえ、可能性は僅かとはいえ、ほんの3回の試行で正しいパスワードに当たることだってありえます。パスワードに「Q1」と設定しているユーザーがサインオンしているのを、たまたま背後で見ていれば…。IBM i ユーザーの方であればお分かりですよね。
このような「何を知っているか」を拠り所にしたパスワード認証方式には、問題があることがお分かりいただけたと思います。
では、それ以外の方法があるのでしょうか。それが、公開鍵認証です。サーバー認証で使用したのと同じ認証方法を、クライアント認証でも使用できるのです。
3. 公開鍵認証
先ほど復習で、クライアントがサーバー認証をどのように行っているかを復習しました。同じ方法は、サーバーがクライアントを認証する際にも用いることができます。
サーバー認証は、
- サーバーが秘密鍵を持っている
- クライアントはサーバーの公開鍵を持っている
- その公開鍵が確かにサーバーのものであるとの検証を行う
というステップで行われました。これをクライアント認証に当てはめると、
- クライアントが、秘密鍵を持っている
- サーバーは、クライアントの公開鍵を持っている
- その公開鍵が、確かにクライアントのものであるという検証を行う
ということができれば良いことになります。この公開鍵認証ができれば、パスワード認証である「何を知っているか」ではなく、「何を持っているか（ユーザーごとの秘密鍵）」による認証が可能となり、より高いレベルのセキュリティーでユーザー認証を行えるわけです。
それでは、クライアント認証を公開鍵で行うための準備をしていきましょう。
鍵ペアの作成
サーバーの鍵ペアは、最初にsshデーモンを開始する際に自動的に作成されますが、クライアントの鍵ペアは手動で作成しなければなりません。ここでは、Windows 10での鍵ペアの作成手順を見ていきましょう。
まず、コマンドプロンプト画面で ssh-keygen を実行します。
C:\Users\ogawa>ssh-keygen -t ed25519 Generating public/private ed25519 key pair. Enter file in which to save the key (C:\Users\ogawa/.ssh/id_ed25519):
オプション -t に続いて暗号化方式を指定します。ここでは ed25519 を指定しています。デフォルトでは、~/.ssh/id_ed25519 という名称で秘密鍵が作成されますが、ここで名前を指定することも可能です。今回はデフォルトの名称で先に進むのでそのまま enter キーを押します。
Enter passphrase (empty for no passphrase):
続いて、秘密鍵にアクセスする際のパスフレーズの入力が求められます。パスフレーズを指定しない場合は、そのままEnterキーを押します（本来は設定すべきですが、今回は割愛します）。
Enter same passphrase again:
もう一度入力が求められるので、そのままEnterキーを押します。
Your identification has been saved in C:\Users\ogawa/.ssh/id_ed25519. Your public key has been saved in C:\Users\ogawa/.ssh/id_ed25519.pub. The key fingerprint is: SHA256:1YafZHfCKVO7qOemZsscyTVM0IbsdBT+Lz03HJdrn14 ogawa@DESKTOP-1ODQCSM The key's randomart image is: +--[ED25519 256]--+ | ..+o.. | | +=+o o | | oooX * .| | ..B B +.| | S B oo.| | . + ..o+| | = . .*E| | oo+. ..B| | o=+. .o.| +----[SHA256]-----+ C:\Users\ogawa>
鍵ペアが作成され、公開鍵のフィンガー・プリントが表示されています。では、作成されたキーを見てみましょう。
C:\Users\ogawa>cd .ssh
C:\Users\ogawa\.ssh>dir
Volume in drive C is Windows
Volume Serial Number is 263A-9C54
Directory of C:\Users\ogawa\.ssh
2024/10/05 14:40 ＜DIR＞ .
2024/10/05 14:40 ＜DIR＞ ..
2024/10/05 14:40 419 id_ed25519
2024/10/05 14:40 105 id_ed25519.pub
2024/10/05 14:19 175 known_hosts
3 File(s) 699 bytes
2 Dir(s) 341,876,006,912 bytes free
~/.ssh ディレクトリーに以下2つのファイルが作成されました。
- id_ed25519
- id_ed25519.pub
拡張子 pub が付いてるのが公開鍵で、付いていないのが秘密鍵です。
では、作成された公開鍵のフィンガー・プリントを計算してみましょう（［sshの仕組みをきちんと理解する］を参照）。
C:\Users\ogawa\.ssh>ssh-keygen -l -f ./id_ed25519.pub 256 SHA256:1YafZHfCKVO7qOemZsscyTVM0IbsdBT+Lz03HJdrn14 ogawa2@DESKTOP-1ODQCSM (ED25519)
鍵ペア作成時に表示されたフィンガー・プリント 1YafZHfCKVO7qOemZsscyTVM0IbsdBT+Lz03HJdrn14 と同じものであることが分かります。
拡張子のない秘密鍵は名前の通り秘密にするべきものであり、作成した本人のみが持っておくべきものです。バックアップ以外の用途でファイルをコピーしたり、他の人に渡したりすることがないように注意しましょう。
この章の冒頭で、パスワード認証は「何を知っているか」、公開鍵認証は「何を持っているか」で認証を行うと述べましたが、この秘密鍵がそれに相当します。ssh において個人を証明するものなので大切に保管してください。
公開鍵を、IBM i 側にプッシュ
IBM i の公開鍵は、クライアントの ~/.ssh/known_hosts ファイルに保存しましたが、クライアントの公開鍵は、IBM i の ユーザーのホームディレクトリーである ~/.ssh 内の authorized_keys というファイルに保管します。ファイル名は authorized_keys なので、間違えないようにしてください（厳密には sshd_config で指定）。
では、scpを使用して、作成したユーザーの公開鍵をサーバーの /home/OGAWA/.ssh 内に、authorized_keys というファイル名でコピーしてみましょう。
C:\Users\ogawa>cd .ssh C:\Users\ogawa\.ssh>scp ./id_ed25519.pub ogawa@172.23.0.238:/home/OGAWA/.ssh/authorized_keys ogawa@172.23.0.238's password: id_ed25519.pub 100% 105 6.4KB/s 00:00 C:\Users\ogawa\.ssh>
では、正しくコピーされたか、ssh接続して確認してみましょう。
C:\Users\ogawa\.ssh>ssh ogawa@172.23.0.238 ogawa@172.23.0.238's password: -bash-5.2$ pwd /home/OGAWA -bash-5.2$ cd .ssh -bash-5.2$ ls -la total 32 drwx--S--- 2 ogawa 0 8192 Oct 5 15:00 . drwxrwsrwx 6 ogawa 0 8192 Oct 5 14:56 .. -rw-r--r-- 1 ogawa 0 105 Oct 5 15:00 authorized_keys -rw-r--r-- 1 ogawa 0 943 Sep 5 15:00 known_hosts -bash-5.2$
authorized_keys という名称でコピーされているのが確認できました。
接続確認
では、公開鍵認証で接続できるかを検証します。接続時には、使用する秘密鍵を指定する必要があり、これは、ssh コマンドで -i を使用して指定します。
C:\Users\ogawa>ssh -i ./.ssh/id_ed25519 ogawa@172.23.0.238 ogawa@172.23.0.238's password:
実行した結果、これまで通りパスワードの入力が求められています。これは、秘密鍵を使用した公開鍵認証を試みたが実施できなかったため、パスワード認証に切り替えられたことを意味します。
権限設定
公開鍵認証で接続する場合、サーバー側の各ディレクトリーおよびファイルの権限設定が重要になってきます。基本的に以下の設定になっていなければなりません。
| ディレクトリー / ファイル | 権限設定 |
|---|---|
| /home/xxxxx | 755 |
| /home/xxxxx/.ssh | 700 |
| /home/xxxxx/.ssh/authorized_keys | 644 |
（上記 xxxxx はユーザー・プロファイル名）
上記表の権限設定の数値は、所有者権限 / グループ権限 / その他のユーザー権限です。数値は 0 から 7 まで指定できますが、それぞれの意味は以下の通りです。
（r = read, w = write, x = execute）
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|
| — | –x | -w- | -wx | r– | r-x | rw- | rwx |
例えば、
-bash-5.2$ ls -la total 300 drwxrwsrwx 3 qsys 0 8192 Aug 3 12:50 . drwxrwsrwx 20 qsys 0 290816 Jul 31 11:55 .. drwxrwsrwx 6 ogawa 0 8192 Oct 5 14:56 OGAWA
と表示された場合、OGAWA ディレクトリーは drwxrwsrwx で、ユーザー、グループ、その他ユーザーが全権限を持っていることを意味します（先頭の d はディレクトリーの意味）。
| 対象 | 設定値 | 意味 |
|---|---|---|
| rwx | ユーザー権限 | 全権限 |
| rws | グループ権限 | 全権限（ s は SGID） |
| rwx | その他ユーザーの権限 | 全権限 |
ssh接続を許可するためには、そのユーザーの /home/xxxxx ディレクトリーは 755（rwxr-xr-x）でなければならないのですが、今回はそうなっていないので先ほどの接続確認では公開鍵認証ができなかったわけです。
では、権限設定変更を行いましょう。権限設定を行うには chmod を使用します。
使い方は chmod xyz ＜対象ディレクトリーあるいはファイル＞ です。
x、y、z はそれぞれ
| x | y | z |
|---|---|---|
| 所有者権限 | グループ権限 | その他のユーザー権限 |
を表し、数字は上記表の値に従います。
では、各ディレクトリーおよびファイルの権限設定を行いましょう。
-bash-5.2$ pwd /home/OGAWA -bash-5.2$ chmod 755 /home/OGAWA -bash-5.2$ chmod 700 /home/OGAWA/.ssh -bash-5.2$ chmod 644 /home/OGAWA/.ssh/authorized_keys -bash-5.2$
権限設定が終わったら、一旦ssh接続を終了し、再度秘密鍵を指定してssh接続してみましょう。
C:\Users\ogawa>ssh -i ./.ssh/id_ed25519 ogawa@172.23.0.238 -bash-5.2$
今度はパスワードを求められることなく、公開鍵認証で認証され、ログインできました。
ACSのOSSパッケージ管理
第4回「OSS Part-1」の『ACSを使用したOSS環境の導入』で、オープン・ソース・パッケージ管理機能で IBM i に接続する際に、パスワード認証で接続設定を行いました。その際、認証メカニズムのところで「SSH 鍵（オプション）」のチェックを外してもらいましたが、今回鍵ペアを作成したので「SSH 鍵（オプション）」を使った接続ができるかを確認してみましょう。
ACSの画面で「オープン・ソース・パッケージ管理」を選択します。
接続するシステムおよびユーザー名を指定し、「SSH鍵（オプション）」をチェックして参照ボタンをクリックします。
先ほど作成した秘密鍵（~/.ssh/id_ed25519）を選択して、「開く」をクリックします。
秘密鍵が絶対パスで指定されていることを確認後、 OK ボタンをクリックしましょう。公開鍵認証で ogawa ユーザーが認証され、オープン・ソース・パッケージ管理画面が表示されたと思います。
秘密鍵について
今回、~/.ssh に、秘密鍵と公開鍵のペアを作成しました。この２つのファイルは、とても重要なファイルです。特に秘密鍵に関しては、sshのクライアント認証で公開鍵認証を使用する場合に必ず必要になるものです（身分証明書のようなものだと思ってください）。このファイルを失くしてしまったら、文字通り「再発行」が必要になり、そうすると公開鍵も変わるので、各サーバーに配布した公開鍵もすべて更新する必要が出てきます。
2つのファイルは必ずバックアップをとって大切に保管するようにしてください。
4. config ファイル
公開鍵認証にて、IBM i に接続することが確認できましたが、接続のたびに秘密鍵を指定するのは面倒です。ユーザー名とIPアドレスあるいはホスト名も指定しなければなりませんし、sshdのポート番号が22以外に設定されていれば、それも指定しなければなりません。
例えば sshd のポート番号が 2211 の場合、
C:\Users\ogawa>ssh -i ./.ssh/id_ed25519 -p 2211 ogawa@172.23.0.238 -bash-5.2$
というように、-p に続けて接続するポート番号を指定する必要があるのです。sshdのポート番号はデフォルトが22番であり、このポート番号であれば省略することができます。つまり、以下のように指定しても問題ありません。
C:\Users\ogawa>ssh -i ./.ssh/id_ed25519 -p 22 ogawa@172.23.0.238 -bash-5.2$
ssh接続のたびにこれらをすべて指定するのはタイプ・ミスの可能性もあるし、覚えておくのも大変です。さらに、複数のサーバーにssh接続しなければならない場合（IBM i が複数ある場合や、いくつかのクラウド・サーバーに接続する場合など）は覚えておくことも大変です。
実は、sshにはこれらの情報をまとめて保管しておくconfigファイルがあります。これを使えば、ファイル内に指定したhost名だけでssh接続できるようになります。例えば、
C:\Users\ogawa>ssh olaf73
と指定するだけで、下記の設定値で接続できるようになるのです。
- 秘密鍵は ~/.ssh/id_ed25519 を使用
- サーバーのポートは、22
- ユーザーは、ogawa
- サーバーは、172.23.0.238
configファイル
上記設定は、~/.ssh/config ファイルに記述します。configファイルはテキスト・ファイルなので、メモ帳等で記述を行ってください。拡張子はありませんので注意してください（Windowsのメモ帳で新規作成した場合は、拡張子 txt が自動的に設定される場合があるので、その際は拡張子を削除してください）。
上記4つの設定を指定するには、以下を ~/.ssh/config に記述します。
Host olaf73 HostName 172.23.0.238 User ogawa Port 22 IdentityFile ~/.ssh/id_ed25519
では、Hostで設定したホスト名 olaf73 で、ssh接続してみましょう。
C:\Users\ogawa>ssh olaf73 -bash-5.2$
正しく接続できたことが確認できました。
~/.ssh/configに設定できるキーワードはたくさんあります（参考文献参照のこと）が、例えば、上記 config 設定で指定した秘密鍵が、何らかの問題で指定した場所に存在しなかった場合、公開鍵認証ができないのでパスワード認証を試みようとします（サーバーでパスワード認証が有効になっている場合）。
C:\Users\ogawa2>ssh olaf73 no such identity: C:\\Users\\ogawa2/.ssh/id_ed25519a: No such file or directory ogawa@172.23.0.238's password:
しかし、パスワード認証はセキュリティー上問題があるので、config ファイル内にキーワード PasswordAuthentication を使うことで、パスワード認証をさせないように設定することも可能です。
Host olaf73 HostName 172.23.0.238 User ogawa Port 22 IdentityFile ~/.ssh/id_ed25519a PasswordAuthentication no
上記設定だと、ssh 接続時に公開鍵認証できないと接続が終了します。
C:\Users\ogawa>ssh olaf73 no such identity: C:\\Users\\ogawa2/.ssh/id_ed25519a: No such file or directory ogawa@172.23.0.238: Permission denied (publickey,password,keyboard-interactive). C:\Users\ogawa>
サーバー側でパスワード認証を不可に設定
configファイル内の PasswordAuthentication キーワードは、クライアント単位でパスワード認証を使用するかどうかの設定でしたが、セキュリティーの観点からサーバー側で一切のパスワード認証を不可にすることも検討するべきです。
IBM i 側のsshdでパスワード認証を不可にするには、ファイル /QOpenSys/QIBM/ProdData/SC1/OpenSSH/etc/sshd_config 内でその旨を記載します。
： #PasswordAuthentication yes #PermitEmptyPasswords no ：
初期値では上記の設定になっているので、PasswordAuthentication のコメントをはずし、yes を no に変更します。この修正は、ssh接続後に、vim（第6回で解説）を使用して実施してみましょう。
： #PasswordAuthentication no #PermitEmptyPasswords no ：
設定を有効にするには、sshdを再起動する必要があります。ssh接続を終了して、5250画面にて再起動してください。詳細については、 ［シェルと基本コマンド］を参照してください。
再起動後は、クライアントのconfigに PasswordAuthentication no の設定がなくても、公開鍵認証ができなければ接続が終了します。
C:\Users\ogawa>ssh olaf73 no such identity: C:\\Users\\ogawa2/.ssh/id_ed25519a: No such file or directory ogawa@172.23.0.238: Permission denied (publickey,keyboard-interactive).
5. syslog
ssh接続するユーザーが増えてくると、各ユーザーの設定等の問題により接続することができないなどの問題が多く発生することでしょう。その際に、ssh接続時に -v パラメーターを使用することで、ユーザーが独自に何が悪かったのかを確認するとともに、問題を解決することも可能です。ただし、ログはすべて英語なので難しさはあるかもしれません。
ssh接続できない問題の多くは
- 公開鍵を保存する authorized_keys のファイル名を間違えている
- 関連する各ディレクトリーおよびファイルの権限設定が間違っている
- sshで指定した秘密鍵のパスあるいはファイル名が間違っている
- configファイルのキーワードの入力ミス、もしくは値の指定ミス
運用段階になると、今度はサーバー側でのログ取得も重要になってきます。例えば、
- どのユーザーが、いつ、ssh接続したか
- いつ、 ssh接続を切断したか
- 不正アクセスがないか
などは、最低限、確認する術が無くてはなりません。これらの情報は、PASE環境でログを収集するために実行できる syslogd を利用することで収集できます。
関連ファイルの準備
syslogdは、/usr/sbin（シンボリック・リンク / QOpenSys/usr/sbin を参照）内にあり、起動時に /QOpenSys/etc/syslog.conf ファイルを参照します。syslogdで収集したログを、どのファイルに出力するかも syslog.conf ファイルに記載します。
| ファイル | 内容 | 備考 |
|---|---|---|
| syslog.conf | デーモンが起動時に参照 | ログレベルや、どのファイルにログを出力するか等を設定 |
| syslog.log | デーモンがログを記録するファイル | /var/log ディレクトリーに作成 |
上記ファイルは、事前に作成および内容を設定しておく必要があります。ファイル作成には、touchコマンドを使用してください。ssh接続後、以下を実行して各ファイルを作成します。
-bash-5.2$ touch /QOpenSys/etc/syslog.conf
touchで指定したパス内のディレクトリーが存在しない場合、logディレクトリーは自動的には作成されせんので、事前に mkdir で作成してください。今回の環境では、/varディレクトリー内に、logディレクトリーが無かったので、touch実行前に logディレクトリーを作成しています。
-bash-5.2$ cd /var -bash-5.2$ ls -l total 12 lrwxrwxrwx 1 qsys 0 36 Jul 31 11:51 krb5 -> /QOpenSys/var/krb5 lrwxrwxrwx 1 qsys 0 44 Jul 31 11:38 preserve -> /QOpenSys/var/preserve lrwxrwxrwx 1 qsys 0 34 Jul 31 11:38 tmp -> /QOpenSys/var/tmp -bash-5.2$ mkdir log -bash-5.2$ ls -l total 20 lrwxrwxrwx 1 qsys 0 36 Jul 31 11:51 krb5 -> /QOpenSys/var/krb5 drwxr-sr-x 2 ogawa 0 8192 Oct 6 08:57 log lrwxrwxrwx 1 qsys 0 44 Jul 31 11:38 preserve -> /QOpenSys/var/preserve lrwxrwxrwx 1 qsys 0 34 Jul 31 11:38 tmp -> /QOpenSys/var/tmp -bash-5.2$ touch /var/log/syslog.log -bash-5.2$
続いて /QOpenSys/etc/syslog.conf に取得するログの種類を記述します。
今回記述する内容は、
authpriv.info /var/log/syslog.log
です。authpriv.infoをセレクター、/var/log/syslog.log をアクションと言います。それをブランクで区切って指定します。
セレクターは更にファシリティとプライオリティを . で区切って指定します。
| 内容 | 値 | 意味 |
|---|---|---|
| ファシリティ | authpriv | 認証サービスのメッセージ |
| プライオリティ | info | 情報 |
（ファシティとプライオリティについての詳細は、参考文献を参照してください。）
アクションには、ログを出力するファイルを絶対パスで指定しています。つまり、今回の記述は、「認証サービス・メッセージの情報レベルを、ファイル /var/log/syslog.log に記録する」という意味になります。
echoを使用して、上記セレクターおよびアクションの行を /QOpenSys/etc/syslog.conf にリダイレクトして書き込みましょう（［シェルと基本コマンド］の「リダイレクト」を参照）。
-bash-5.2$ echo 'authpriv.info /var/log/syslog.log' > /QOpenSys/etc/syslog.conf -bash-5.2$ tail /QOpenSys/etc/syslog.conf authpriv.info /var/log/syslog.log -bash-5.2$
sshdのログ関連の設定
syslog機能を使用する各サービスは、どのメッセージをどのレベルで出力するかを個別に設定しています。例えば、今回使用するsshdは、構成ファイル /QOpenSys/QIBM/ProdData/SC1/OpenSSH/etc/sshd_config 内に、以下の記述があります。
#SyslogFacility AUTH #LogLevel INFO
デフォルトでは、SyslogFacilityがAUTHになっていますが、現在は非推奨なので、vimを使用してAUTHPRIVに変更してください。
#SyslogFacility AUTH #LogLevel INFO
syslogの開始
では、syslogデーモンを開始しましょう。ssh接続後、systemコマンドを使用して、IBM i のSBMJOBコマンドを実行します。下記例では、サブミットするのはQSHコマンドで、 /usr/sbin/syslogd を実行しています。
-bash-5.2$ system "SBMJOB CMD(QSH CMD('/usr/sbin/syslogd')) JOBQ(QUSRNOMAX)"
CPC1221: ジョブ009348/OGAWA/QDFTJOBDがライブラリーQSYSのジョブ待ち行列QUSRNOMAXに投入された。
-bash-5.2$
syslogdが開始されたかどうかは WRKACTJOB SBS(QUSRWRK) で確認できます。
syslogdを起動したら、sshdを再起動します。sshdの再起動は、5250画面にて行います（［sshの仕組みをきちんと理解する］を参照）。
syslog.confおよびsshd_configの各設定が正しく行われていれば、/var/log/syslog.logに以下のようなログが記録されているはずです。IBM i のEDTFコマンド、あるいは ssh 接続後のtaiコマンドで確認してください。
Oct 6 12:07:31 OLAF73 authpriv:info sshd[1772]: Server listening on 0.0.0.0 port 22. Oct 6 12:07:31 OLAF73 authpriv:info sshd[1772]: Server listening on :: port 22.
sshd が開始され、ポート番号 22 をリッスンしているというログが書き出されています。それでは、ユーザーが ssh 接続および切断した時のログはどうなるのかを見てみましょう（接続日時等の情報は削除）。
Accepted publickey for ogawa from 172.23.1.209 port 61171 ssh2: ED25519 SHA256:xxxxxxx Received disconnect from 172.23.1.209 port 61171:11: disconnected by user Disconnected from user ogawa 172.23.1.209 port 61171
公開鍵認証が行われて接続および切断されたログが記録されています。
パスワード認証の場合もその旨ログに記録されます。
Accepted password for ogawa from 172.23.1.209 port 61174 ssh2
パスワードを間違えた場合のログは以下の通りです。
Failed password for ogawa from 172.23.1.209 port 61177 ssh2 last message repeated 2 times Connection reset by authenticating user ogawa 172.23.1.209 port 61177 [preauth]
この例では、パスワードを３回間違えて、接続がリセット（切断）されたことが確認できます。
syslogdについて
syslogdに関する設定について、最低限必要なもののみを解説しました。syslogdはネット上に多くの情報がありますので、参考文献で紹介しているサイトや、その他のサイトなど色々と調べていただき、皆さんの業務にあった運用とログレベルを選択していただければと思います。
6. おわりに
今回は、ssh接続におけるクライアント認証を中心に解説しました。何を知っているかでユーザーを認証するパスワード認証ではなく、何を持っているかで認証する公開鍵認証について、その利点と設定方法およびconfigファイルを使用した便利な使い方などを理解していただけたのではないかと思います。
本文では触れませんでしたが、公開鍵認証は sftp や scp でももちろん使用することができます。
例えば、パスワード認証で、
-bash-5.2$ sftp ogawa@172.23.0.238 ogawa@172.23.0.238's password: Connected to 172.23.0.238. sftp>
と接続していたところを、公開鍵認証 + configファイル設定で、
C:\Users\ogawa2>sftp olaf73 Connected to olaf73. sftp>
というように、接続できるのです。もちろん、scpでもconfigファイルで指定したホスト名でファイル転送が可能です。公開鍵認証では、パスワードのように追加で入力要求されるものはないので、プログラムに組み込んだり、バッチ的に利用したりすることがより簡単にできますね。
外部サーバー、外部サービスとの連携が、これからますます必要になってきます。その時の接続手段としては、恐らく ssh + 公開鍵認証が第一候補になることは間違いありません。既存のIBM i のユーザーの方にとって難しいと感じる点が多々あると思いますが、理屈をしっかり理解して積極的に使用して慣れていくことで、IBM i の基幹システムと外部との連携のアイデアが多く浮かんでくるはずです。
まずは、ssh + 公開鍵認証 + sftp / scp でのファイル転送で Linux 系のツールに慣れていってください。
オープン系の開発者の方にも、「IBM i も今までの知識を活かして使うことができそう」と感じていただければ幸いです。
次回からは、IBM i のOSSで便利そうなツールを紹介していきたいと思います。どんなお宝が隠れているのか、ご期待ください！
参考文献
- エンジニアの入口『【Linuxパーミッション】SGIDとは？』
- Qiita『~/.ssh/configについて』
- IBM Support『The SSHD Can Use the UNIX Syslog Facilities for Logging』
- @IT『システム管理の基礎 syslogdの設定をマスターしよう』
- FreeBSD『SSHD_CONFIG(5)』
