aboutsummaryrefslogtreecommitdiff
path: root/ja_JP.eucJP/books/handbook/security/chapter.xml
diff options
context:
space:
mode:
Diffstat (limited to 'ja_JP.eucJP/books/handbook/security/chapter.xml')
-rw-r--r--ja_JP.eucJP/books/handbook/security/chapter.xml365
1 files changed, 162 insertions, 203 deletions
diff --git a/ja_JP.eucJP/books/handbook/security/chapter.xml b/ja_JP.eucJP/books/handbook/security/chapter.xml
index f4d9d93a6b..20e721c8eb 100644
--- a/ja_JP.eucJP/books/handbook/security/chapter.xml
+++ b/ja_JP.eucJP/books/handbook/security/chapter.xml
@@ -10,19 +10,14 @@
should skip translating this section until rev.1.150.
$FreeBSD$
-->
-
-<chapter id="security">
- <chapterinfo>
+<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="security">
+ <info><title>セキュリティ</title>
<authorgroup>
- <author>
- <firstname>Matthew</firstname>
- <surname>Dillon</surname>
- <contrib>本章の基にした security(7) マニュアルページの執筆: </contrib>
- </author>
+ <author><personname><firstname>Matthew</firstname><surname>Dillon</surname></personname><contrib>本章の基にした security(7) マニュアルページの執筆: </contrib></author>
</authorgroup>
- </chapterinfo>
+ </info>
- <title>セキュリティ</title>
+
<indexterm><primary>セキュリティ</primary></indexterm>
<para><emphasis>訳: &a.jp.hino;、(jpman プロジェクトの成果を利用させ
@@ -97,7 +92,7 @@
</sect1>
- <sect1 id="security-intro">
+ <sect1 xml:id="security-intro">
<title>はじめに</title>
<para>セキュリティとは、システム管理者をいつも悩ませる仕事の一つです。
@@ -136,7 +131,7 @@
<para>また、システムセキュリティには、
さまざまな形での攻撃に対処することとも関係しています。
- 攻撃の中には <username>root</username>
+ 攻撃の中には <systemitem class="username">root</systemitem>
権限を奪おう (<quote>root 権限を破る</quote>) とはしないけれども、
クラッシュやシステムの不安定状態を引き起こそうとするものもあります。
このセキュリティ問題は、いくつかに分類することが可能です。</para>
@@ -214,13 +209,13 @@
ログを解析して、疑わしい送信元アドレスを探すものです。</para>
<para>ひとたび攻撃者がユーザアカウントへのアクセス権を入手したら、
- 攻撃者は <username>root</username> 権限を破れると仮定するべきです。
+ 攻撃者は <systemitem class="username">root</systemitem> 権限を破れると仮定するべきです。
しかし、セキュリティを十分維持し、手入れの行き届いたシステムにおい
ては、あるユーザアカウントへのアクセスが可能となっても、
- 必ずしも攻撃者に <username>root</username>
+ 必ずしも攻撃者に <systemitem class="username">root</systemitem>
へのアクセス権を与えるとは限りません。この違いは重要です。
というのは、一般的に
- <username>root</username> へのアクセス権がなければ、
+ <systemitem class="username">root</systemitem> へのアクセス権がなければ、
攻撃者は自分の侵入の痕跡を隠蔽することができませんし、
そのユーザのファイルを引っかき回したり、
マシンをクラッシュさせたりするのがせいぜいです。
@@ -233,27 +228,27 @@
<secondary>裏口 (バックドア)</secondary>
</indexterm>
- <para>システム管理者は、あるマシン上で <username>root</username>
+ <para>システム管理者は、あるマシン上で <systemitem class="username">root</systemitem>
権限を奪取する方法は、
潜在的に何通りもあるということを心しておかねばなりません。
- 攻撃者は <username>root</username>
+ 攻撃者は <systemitem class="username">root</systemitem>
のパスワードを知っているかもしれませんし、
- 攻撃者が <username>root</username>
+ 攻撃者が <systemitem class="username">root</systemitem>
権限で実行されているサーバのバグを見つけ、
ネットワーク接続を介して
- <username>root</username> 権限を破ることができるかもしれません。
+ <systemitem class="username">root</systemitem> 権限を破ることができるかもしれません。
また、攻撃者は suid-root プログラムに存在するバグを知っていて、
ユーザアカウントを破れば
- <username>root</username> 権限を奪取できるかもしれません。
+ <systemitem class="username">root</systemitem> 権限を奪取できるかもしれません。
攻撃者があるマシン上で
- <username>root</username> 権限を破る方法を知ったならば、
+ <systemitem class="username">root</systemitem> 権限を破る方法を知ったならば、
攻撃者は裏口を用意する必要がありません。
- これまでに発見され、ふさがれた <username>root</username>
+ これまでに発見され、ふさがれた <systemitem class="username">root</systemitem>
の穴の多くには、攻撃者が自分のしたことの痕跡を消そうとした作業が、
かなりの割合で含まれています。
そのため、ほとんどの攻撃者は裏口を作るのです。裏口は、
攻撃者がたやすくシステムへの
- <username>root</username> アクセスを再び得られるようにしますが、
+ <systemitem class="username">root</systemitem> アクセスを再び得られるようにしますが、
有能な管理者に侵入を検知する便利な手段を与えるものでもあります。
攻撃者に裏口を作らせないようにするということは、
セキュリティにとっては実際には良くないことかもしれません。
@@ -267,13 +262,13 @@
<orderedlist>
<listitem>
- <para><username>root</username>
+ <para><systemitem class="username">root</systemitem>
とスタッフのアカウントの安全性を高める。</para>
</listitem>
<listitem>
- <para><username>root</username> の安全性を高める &ndash;
- <username>root</username> 権限で動作するサーバと
+ <para><systemitem class="username">root</systemitem> の安全性を高める &ndash;
+ <systemitem class="username">root</systemitem> 権限で動作するサーバと
suid/sgid バイナリ。</para>
</listitem>
@@ -304,7 +299,7 @@
ます。</para>
</sect1>
- <sect1 id="securing-freebsd">
+ <sect1 xml:id="securing-freebsd">
<title>FreeBSDの安全性を高める</title>
<note>
@@ -324,86 +319,86 @@
</link>でとりあげた FreeBSD システムの安全性を高める方法について
述べます。</para>
- <sect2 id="securing-root-and-staff">
- <title><username>root</username>
+ <sect2 xml:id="securing-root-and-staff">
+ <title><systemitem class="username">root</systemitem>
アカウントとスタッフアカウントの安全性を高める</title>
<indexterm>
<primary><command>su</command></primary>
</indexterm>
- <para><username>root</username>
+ <para><systemitem class="username">root</systemitem>
のアカウントの安全性を確保しないうちから
スタッフのアカウントの安全性をうんぬんしてもしかたがありません。
- ほとんどのシステムでは、<username>root</username>
+ ほとんどのシステムでは、<systemitem class="username">root</systemitem>
アカウントに割り当てたパスワードが 1 つあり
ます。まず最初にすべきことは、このパスワードは<emphasis>いつで
も</emphasis>不正利用の危険に晒されていると仮定することです。これは
- <username>root</username>
+ <systemitem class="username">root</systemitem>
のパスワードを消すべきだと言っているのではありません。
- <username>root</username>
+ <systemitem class="username">root</systemitem>
のパスワードは、マシンにコンソールからアクセスするのには、
ほとんどいつでも必要なものです。ここで言いたいのは、コンソール
以外からは、そして可能なら &man.su.1; コマンドを実行する場合も
- <username>root</username>
+ <systemitem class="username">root</systemitem>
のパスワードを使えないようにするべきである、ということで
す。たとえば、あなたが使っている pty が、
<filename>/etc/ttys</filename> ファイルで insecure と指定
されているか確認してください。そうすると、
<command>telnet</command> や <command>rlogin</command> 経由では
- <username>root</username> で直接ログインできないようになります。
+ <systemitem class="username">root</systemitem> で直接ログインできないようになります。
これは、<filename>/etc/ssh/sshd_config</filename> を編集して
<literal>PermitRootLogin</literal> に <literal>NO</literal>
が設定されるようにすることで実現できます。
<application>sshd</application> のような、別のログインサービス
- を使っている場合でも同様に、直接 <username>root</username>
+ を使っている場合でも同様に、直接 <systemitem class="username">root</systemitem>
へログインすることを許し
ていないかどうか確認してください。すべてのアクセス手段 &ndash;
たとえば FTP
のようなサービスが、良くクラックの対象となることを考えましょう。
- <username>root</username> への直接ログインは、
+ <systemitem class="username">root</systemitem> への直接ログインは、
システムコンソール経由でのみ可能であるべきなのです。</para>
<indexterm>
- <primary><groupname>wheel</groupname></primary>
+ <primary><systemitem class="groupname">wheel</systemitem></primary>
</indexterm>
- <para>また当然、システム管理者として自分が <username>root</username>
+ <para>また当然、システム管理者として自分が <systemitem class="username">root</systemitem>
になれるようにしておく必要が
ありますから、そのための穴をいくつか開けておきます。し
かし、それらの穴を動作させるには、さらに追加のパスワード認証が
必要であるようにしておくことが重要です。
- <username>root</username> でアクセス可能と
+ <systemitem class="username">root</systemitem> でアクセス可能と
する方法の一つとして、適切なスタッフアカウントを
(<filename>/etc/group</filename> 中の)
- <groupname>wheel</groupname> グループに加えることがあります。
- <groupname>wheel</groupname> グループに入っているスタッフメンバは
+ <systemitem class="groupname">wheel</systemitem> グループに加えることがあります。
+ <systemitem class="groupname">wheel</systemitem> グループに入っているスタッフメンバは
<command>su</command> を使って
- <username>root</username> になることが許されます。
+ <systemitem class="username">root</systemitem> になることが許されます。
パスワードエントリにおいて、スタッフメンバを
- <groupname>wheel</groupname> グループに置くことによって直接
- <groupname>wheel</groupname>
+ <systemitem class="groupname">wheel</systemitem> グループに置くことによって直接
+ <systemitem class="groupname">wheel</systemitem>
権限を与えてはいけません。スタッフメンバのアカウントは
- <groupname>staff</groupname> グループに所属させるべきで、その上で
+ <systemitem class="groupname">staff</systemitem> グループに所属させるべきで、その上で
<filename>/etc/group</filename> ファイルを通して
- <groupname>wheel</groupname> グループに加えるべきです。実際に
- <username>root</username> アクセスの必要なスタッフメンバのみ
- <groupname>wheel</groupname> グループに置くようにすべきです。
+ <systemitem class="groupname">wheel</systemitem> グループに加えるべきです。実際に
+ <systemitem class="username">root</systemitem> アクセスの必要なスタッフメンバのみ
+ <systemitem class="groupname">wheel</systemitem> グループに置くようにすべきです。
他の認証方法の場合、たとえば Kerberos を使用する場合には、
- <username>root</username> アカウントの
+ <systemitem class="username">root</systemitem> アカウントの
Kerberos <filename>.k5login</filename> ファイルを使えば、誰も
- <groupname>wheel</groupname> グループに置く必要なく
- <username>root</username> に &man.ksu.1;
+ <systemitem class="groupname">wheel</systemitem> グループに置く必要なく
+ <systemitem class="username">root</systemitem> に &man.ksu.1;
することを許可できます。このやり
方はよりよい解決策なのかもしれません。なぜなら、
<literal>wheel</literal> のメカニズムでは、侵入者がパスワード
ファイルを手に入れ、スタッフアカウントのいずれか 1 つを破るこ
とができると、
- <username>root</username> を破ることがまだできてしまうからです。
- <groupname>wheel</groupname> のメカニズムを用いる方が、
+ <systemitem class="username">root</systemitem> を破ることがまだできてしまうからです。
+ <systemitem class="groupname">wheel</systemitem> のメカニズムを用いる方が、
何もしないよりは良いのですが、
必ずしも最も安全な選択肢とは限りません。</para>
<para>スタッフのアカウント、また究極には
- <username>root</username> アカウントの安全性
+ <systemitem class="username">root</systemitem> アカウントの安全性
を高める間接的な方法は、別のログインアクセスの方法を用いてスタッ
フのアカウントの安全性を高め、その上でそのスタッフのアカウント
の暗号化パスワードを <quote>アスタリスク化</quote>
@@ -511,9 +506,9 @@
ていがちだということに注意して下さい。たとえば、古いバージョンの
<application>imapd</application> や
<application>popper</application>
- を実行させておくのは、全世界に万能の <username>root</username>
+ を実行させておくのは、全世界に万能の <systemitem class="username">root</systemitem>
の切符を与えているようなものです。自分で注意深くチェックしていない
- サーバは、決して実行してはいけません。<username>root</username>
+ サーバは、決して実行してはいけません。<systemitem class="username">root</systemitem>
で実行させる必要のあるサーバはほとんどありません。たとえば、
<application>ntalk</application>,
<application>comsat</application>,
@@ -527,7 +522,7 @@
に脱出しなければなりません。攻撃者が通過せねばならない層の数が
増えれば増えるほど、それだけ攻撃者が侵入に成功する確率が減りま
す。Root の抜け穴は歴史的に、基本システムサーバも含め、
- <username>root</username>
+ <systemitem class="username">root</systemitem>
権限で実行されるほとんどすべてのサーバプロセスで発見されています。
ユーザが <application>sshd</application> 経由でのみログインし、
<application>telnetd</application>,
@@ -561,12 +556,12 @@
のサーバには代わりとなるものがありますが、代わりのものをインス
トールするには、あなたが思うより多くの仕事が必要になるかもしれ
ません (便利さという要素がまたも勝利を収めるわけです)。これら
- のサーバは、<username>root</username>
+ のサーバは、<systemitem class="username">root</systemitem>
権限で実行しなければばならないかもしれません。また、
これらのサーバ経由で生じる侵入を検出するためには、他の仕組みに
頼らなくてはならないかもしれません。</para>
- <para>システムの <username>root</username>
+ <para>システムの <systemitem class="username">root</systemitem>
権限の潜在的な穴で他に大きなものには、シ
ステムにインストールされた suid-root/sgid バイナリがあります。
これらのバイナリは、<application>rlogin</application> のように、
@@ -574,11 +569,11 @@
<filename>/usr/bin</filename>, <filename>/usr/sbin</filename>
に存在するものがほとんどです。100% 安全なものは存在しないとは
いえ、システムデフォルトの siud/sgid バイナリは比較的安全とい
- えます。それでもなお、<username>root</username>
+ えます。それでもなお、<systemitem class="username">root</systemitem>
セキュリティホールがこれらのバイナリにときおり発見されています。
1998 年に <application>xterm</application>
(普通、suid 設定されています) を脆弱にしていた
- <literal>Xlib</literal> の <username>root</username>
+ <literal>Xlib</literal> の <systemitem class="username">root</systemitem>
セキュリティホールが見つかりました。
安全である方がよいので、
用心深いシステム管理者は残念に思いながらも、スタッフのみが実行
@@ -597,7 +592,7 @@
送られたキーストロークを監視できるという危険があります。キース
トロークには、安全な方法でログインするユーザが使っている pty
も含まれます。
- <groupname>tty</groupname> グループを破った侵入者は、ほぼ任意のユーザの
+ <systemitem class="groupname">tty</systemitem> グループを破った侵入者は、ほぼ任意のユーザの
tty へ書き込みができます。ユーザが端末プログラムやキーボードを
シミュレーションする機能を持ったエミュレータを使っている場合、
侵入者は潜在的に、結局そのユーザとして実行されるコマンドをユー
@@ -605,7 +600,7 @@
ます。</para>
</sect2>
- <sect2 id="secure-users">
+ <sect2 xml:id="secure-users">
<title>ユーザアカウントの安全性を高める</title>
<para>ユーザアカウントは、普通、安全性を高めることが最も困難です。
@@ -630,14 +625,13 @@
それらのアカウントのアクセスには
ssh や Kerberos を使うようにすることが、唯一の確実な方法です。
暗号化パスワードファイル
- (<filename>/etc/spwd.db</filename>) は <username>root</username>
+ (<filename>/etc/spwd.db</filename>) は <systemitem class="username">root</systemitem>
でのみ読み出し可能だけれども、
たとえ、侵入者が root の書き込み権限は得られなくとも、
読み出しアクセス権限を得ることは可能かもしれません。</para>
<para>セキュリティスクリプトで常にパスワードファイルの変更をチェッ
- クし、報告するようにすべきです (<link
- linkend="security-integrity">ファイルの完全性のチェック</link>
+ クし、報告するようにすべきです (<link linkend="security-integrity">ファイルの完全性のチェック</link>
節参照)。</para>
</sect2>
@@ -645,28 +639,28 @@
<title>カーネルのコア、raw デバイス、ファイルシステムの安全性を
高める</title>
- <para><username>root</username>
+ <para><systemitem class="username">root</systemitem>
の権限を破ると、攻撃者はほとんど何でもできますが、特に重宝さ
れる特定の事柄もいくつかあります。たとえば、最近のカーネルは、組
み込みのパケット覗き見デバイス (packet sniffing device) ドライ
バを備えているものがほとんどです。FreeBSD では
- <devicename>bpf</devicename> デバイスと呼ばれています。侵入者
+ <filename>bpf</filename> デバイスと呼ばれています。侵入者
は普通、侵入済みのマシンでパケット覗き見プログラムを実行させよ
うと試みます。侵入者にわざわざそういう機能を提供する必要はない
- ので、ほとんどのシステムで <devicename>bpf</devicename>
+ ので、ほとんどのシステムで <filename>bpf</filename>
デバイスを組み込むべきではありません。</para>
<indexterm>
<primary><command>sysctl</command></primary>
</indexterm>
- <para><devicename>bpf</devicename> デバイスを外しても、
- <devicename>/dev/mem</devicename> と
- <devicename>/dev/kmem</devicename>
+ <para><filename>bpf</filename> デバイスを外しても、
+ <filename>/dev/mem</filename> と
+ <filename>/dev/kmem</filename>
という悩みの種がまだ残っています。この問題に関しては、侵入者は
raw ディスクデバイスに書き込
むこともできます。ほかにも、モジュールローダ、&man.kldload.8; とい
う、別のカーネル機能があります。やる気まんまんの侵入者は、KLD
- モジュールを使って自分独自の <devicename>bpf</devicename>
+ モジュールを使って自分独自の <filename>bpf</filename>
もしくはその他覗き見デバイス
を動作中のカーネルにインストールできます。この問題を
避けるため、システム管理者はカーネルをより高い安全レベル (
@@ -693,7 +687,7 @@
要なことができなくなってしまうということです。</para>
</sect2>
- <sect2 id="security-integrity">
+ <sect2 xml:id="security-integrity">
<title>ファイルの完全性のチェック: バイナリ、設定ファイルなど
</title>
@@ -891,7 +885,7 @@
<para>境界ルータのところでファイアウォールを設けて、外部からのア
クセスに対して内部サービスを防御するという考えは実によいもので
す。この考えは、LAN の外部からの飽和攻撃を防ぐことにあり、内部
- サービスをネットワークベースの <username>root</username>
+ サービスをネットワークベースの <systemitem class="username">root</systemitem>
権限への攻撃から防御するこ
とにはあまり考慮を払っていません。ファイアウォールは常に排他的
に設定して下さい。つまり、<quote>ポート A, B, C, D と M から Z
@@ -1024,7 +1018,7 @@
実際の鍵そのものが見えてしまうわけではありませんが、
ssh はあなたが login
している間、転送用ポートを作ります。攻撃者が安全でないマシンの
- <username>root</username> を破ったら、このポートを使って暗号鍵を取得し、
+ <systemitem class="username">root</systemitem> を破ったら、このポートを使って暗号鍵を取得し、
この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。
</para>
@@ -1044,19 +1038,15 @@
</sect2>
</sect1>
- <sect1 id="crypt">
- <sect1info>
+ <sect1 xml:id="crypt">
+ <info><title>DES, MD5 と Crypt</title>
<authorgroup>
- <author>
- <firstname>Bill</firstname>
- <surname>Swingle</surname>
- <contrib>改訂: </contrib>
- </author>
+ <author><personname><firstname>Bill</firstname><surname>Swingle</surname></personname><contrib>改訂: </contrib></author>
</authorgroup>
- <!-- 21 Mar 2000 -->
- </sect1info>
+
+ </info>
- <title>DES, MD5 と Crypt</title>
+
<indexterm>
<primary>セキュリティ</primary>
<secondary>crypt</secondary>
@@ -1139,7 +1129,7 @@
</sect2>
</sect1>
- <sect1 id="skey">
+ <sect1 xml:id="skey">
<title>S/Key</title>
<indexterm><primary>S/Key</primary></indexterm>
<indexterm>
@@ -1551,7 +1541,7 @@ permit port ttyd0</programlisting>
<para>二行目 (<literal>permit user</literal>)
によって、ある特定のユーザ、この場合は
- <username>fnord</username>、に対して、いつでも Unix
+ <systemitem class="username">fnord</systemitem>、に対して、いつでも Unix
パスワードの利用を許可するように指定しています。
一般的にはこの設定をおこなうべきではありません。
<command>key</command> プログラムがどうしても使えない環境にい
@@ -1567,25 +1557,17 @@ permit port ttyd0</programlisting>
</sect2>
</sect1>
- <sect1 id="kerberos">
- <sect1info>
+ <sect1 xml:id="kerberos">
+ <info><title>Kerberos</title>
<authorgroup>
- <author>
- <firstname>Mark</firstname>
- <surname>Murray</surname>
- <contrib>寄稿: </contrib>
- </author>
+ <author><personname><firstname>Mark</firstname><surname>Murray</surname></personname><contrib>寄稿: </contrib></author>
</authorgroup>
<authorgroup>
- <author>
- <firstname>Mark</firstname>
- <surname>Dapoz</surname>
- <contrib>基にした文書の執筆: </contrib>
- </author>
+ <author><personname><firstname>Mark</firstname><surname>Dapoz</surname></personname><contrib>基にした文書の執筆: </contrib></author>
</authorgroup>
- </sect1info>
+ </info>
- <title>Kerberos</title>
+
<indexterm><primary>Kerberos</primary></indexterm>
<para><emphasis>訳: &a.jp.arimura;.</emphasis></para>
@@ -1624,7 +1606,7 @@ permit port ttyd0</programlisting>
アメリカ合衆国およびカナダ以外の国に住んでいるシステム所有者の手に入るものだったからです。</para>
<para>ほかに、MIT で実装された Kerberos が Ports Collection
- の <filename role="package">security/krb5</filename>
+ の <package>security/krb5</package>
から利用できます。</para>
</sect2>
@@ -1651,7 +1633,7 @@ README krb.conf krb.realms</screen>
<filename>krb.realms</filename>を編集してKerberosの 管理領域
(realm) を定義してください。
ここでは管理領域が <filename>EXAMPLE.COM</filename>
- で、サーバ名が <hostid role="fqdn">grunt.example.com</hostid>
+ で、サーバ名が <systemitem class="fqdomainname">grunt.example.com</systemitem>
であるとします。
<filename>krb.conf</filename>
というファイルを次のように編集してください。</para>
@@ -1684,8 +1666,8 @@ ARC.NASA.GOV trident.arc.nasa.gov</screen>
のマニュアルページをご覧ください。</para>
<para>ここで、<filename>EXAMPLE.COM</filename> という管理領域に
- <hostid role="fqdn">grunt.example.com</hostid>
- およびその他の <hostid role="domainname">.example.com</hostid>
+ <systemitem class="fqdomainname">grunt.example.com</systemitem>
+ およびその他の <systemitem class="fqdomainname">.example.com</systemitem>
ドメインのすべてのホストを追加しなければなりません。
<filename>krb.realms</filename> は次のようになります。</para>
@@ -1837,7 +1819,7 @@ Generating 'grunt-new-srvtab'....</screen>
<para>そのファイルがクライアントに配るためのもので、
ネットワークが安全で はないと思われる場合には、<filename>
- <replaceable>client</replaceable>-new-srvtab</filename>
+ client-new-srvtab</filename>
を移動
可能なメディアにコピーして物理的に安全な方法で運んでください。
クラ
@@ -1855,7 +1837,7 @@ Generating 'grunt-new-srvtab'....</screen>
<para>ここで、
ユーザのエントリをデータベースに追加する必要があります。
始めに、
- ユーザ<username>jane</username>のエントリを作成してみましょう。
+ ユーザ<systemitem class="username">jane</systemitem>のエントリを作成してみましょう。
<command>kdb_edit</command>
を用いて次のように作成してください。</para>
@@ -1919,7 +1901,7 @@ Current Kerberos master key version is 1.
Master key entered. BEWARE!</screen>
- <para>さあ、これで上で作成した <username>jane</username>
+ <para>さあ、これで上で作成した <systemitem class="username">jane</systemitem>
というIDのチケットを
<command>kinit</command>コマンドで得ることができます。</para>
@@ -1956,13 +1938,13 @@ Password changed.</screen>
<sect2>
<title><command>su</command> 特権の追加</title>
- <para>Kerberos は <username>root</username> 権限が必要な
+ <para>Kerberos は <systemitem class="username">root</systemitem> 権限が必要な
<emphasis>各</emphasis> ユーザに対し、
<command>su</command> コマンドのパスワードをユーザ毎に
<emphasis>別のもの</emphasis> として持つことを可能にします。
- <username>root</username> に <command>su</command>
+ <systemitem class="username">root</systemitem> に <command>su</command>
できる権利を与えられた id を追加します。これは、
- principal に付いている <username>root</username>
+ principal に付いている <systemitem class="username">root</systemitem>
というインスタンスに よって制御されています。
<command>kdb_edit</command>を用いて
<literal>jane.root</literal>というエントリを
@@ -2005,7 +1987,7 @@ MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane.root"
<prompt>Password: </prompt></screen>
- <para>ここで <username>root</username> ユーザの
+ <para>ここで <systemitem class="username">root</systemitem> ユーザの
<filename>.klogin</filename>
ファイルにユーザを追加する必要があります。</para>
@@ -2035,13 +2017,13 @@ May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM</screen>
うインスタンス付きで作成しました。
これはユーザと同じ名前をprincipalと しており、
Kerberosのデフォルトの値です;
- <literal>&lt;username&gt;.</literal><username>root</username>
+ <literal>&lt;username&gt;.</literal><systemitem class="username">root</systemitem>
という形式の
<literal>&lt;principal&gt;.&lt;instance&gt;</literal>で、
- 必要なエントリが <username>root</username> のホームディレクトリの
+ 必要なエントリが <systemitem class="username">root</systemitem> のホームディレクトリの
<filename>.klogin</filename> ファイルにあれば、
<literal>&lt;username&gt;</literal> が
- <username>root</username> に
+ <systemitem class="username">root</systemitem> に
<command>su</command> できます。</para>
<screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
@@ -2055,16 +2037,16 @@ jane.root@EXAMPLE.COM</screen>
jane@EXAMPLE.COM
jack@EXAMPLE.COM</screen>
- <para><username>jane</username> または <username>jack</username>
+ <para><systemitem class="username">jane</systemitem> または <systemitem class="username">jack</systemitem>
という名前で (前述の<command>kinit</command> によって)
認証されている <filename>EXAMPLE.COM</filename>
という管理領域のユーザ なら誰でも<command>rlogin</command> や
<command>rsh</command>, <command>rcp</command>等によってこ
- のシステム (<hostid>grunt</hostid>)
- の<username>jane</username>のアカウントまたはファ
+ のシステム (<systemitem>grunt</systemitem>)
+ の<systemitem class="username">jane</systemitem>のアカウントまたはファ
イルにアクセスできます。</para>
- <para>たとえば、<username>jane</username> が他のシステムに
+ <para>たとえば、<systemitem class="username">jane</systemitem> が他のシステムに
Kerberos を用いて login します。</para>
<screen>&prompt.user; <userinput>kinit</userinput>
@@ -2078,7 +2060,7 @@ Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<para>次の例では、Jack が同じマシンの Jane
- のアカウントに login します。<username>jane</username> は
+ のアカウントに login します。<systemitem class="username">jane</systemitem> は
<filename>.klogin</filename> ファイルを前述のように設定しており、
Kerberos では <emphasis>jack</emphasis> という principal
をインスタンスなしで設定してあります。</para>
@@ -2095,22 +2077,15 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
</sect2>
</sect1>
- <sect1 id="firewalls">
- <sect1info>
+ <sect1 xml:id="firewalls">
+ <info><title>ファイアウォール</title>
<authorgroup>
- <author>
- <firstname>Gary</firstname>
- <surname>Palmer</surname>
- <contrib>寄稿: </contrib>
- </author>
- <author>
- <firstname>Alex</firstname>
- <surname>Nash</surname>
- </author>
+ <author><personname><firstname>Gary</firstname><surname>Palmer</surname></personname><contrib>寄稿: </contrib></author>
+ <author><personname><firstname>Alex</firstname><surname>Nash</surname></personname></author>
</authorgroup>
- </sect1info>
+ </info>
- <title>ファイアウォール</title>
+
<indexterm><primary>ファイアウォール</primary></indexterm>
<indexterm>
<primary>セキュリティ</primary>
@@ -2185,7 +2160,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
proxy サーバはたいへんバラエティに富んでいるので、
この節でそれらすべてをカバーすることはできません。</para>
- <sect3 id="firewalls-packet-filters">
+ <sect3 xml:id="firewalls-packet-filters">
<title>パケットフィルタリングルータ</title>
<para>ルータとは、二つまたはそれ以上のネットワークの間で
@@ -2220,7 +2195,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
に基づくルールを指定することができます。</para>
</sect3>
- <sect3 id="firewalls-proxy-servers">
+ <sect3 xml:id="firewalls-proxy-servers">
<title>Proxy サーバ</title>
<para>Proxy サーバとは通常のシステムデーモン
@@ -2548,7 +2523,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
特定のインタフェースを通ってきたパケット
だけにマッチするように、IP アドレスまたはローカル IP
インタフェースの ドメイン名、またはインタフェース名
- (たとえば <devicename>ed0</devicename>) を
+ (たとえば <filename>ed0</filename>) を
指定することができます。
インタフェースユニット番号はオプションで、
ワイルドカードで指定することが できます。たとえば、
@@ -2573,8 +2548,8 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<option><replaceable>mask-bits</replaceable></option>
はアドレスマスクで上位何ビットを1にするべきかを
示す十進数値です。たとえば次の指定、
- <hostid role="netmask">192.216.222.1/24</hostid> はクラス C のサブネット
- (この場合 <hostid role="ipaddr">192.216.222</hostid>)
+ <systemitem class="netmask">192.216.222.1/24</systemitem> はクラス C のサブネット
+ (この場合 <systemitem class="ipaddress">192.216.222</systemitem>)
の任意のアドレスにマッチするマスクを作成します。
<option><replaceable>mask-pattern</replaceable></option>
は与えられたアドレスと 論理 AND される IP アドレスです。
@@ -2780,16 +2755,13 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<sect2>
<title><application>ipfw</application> についてのコマンドの例</title>
- <para>このコマンドは、ホスト <hostid
- role="fqdn">evil.crackers.org</hostid> から ホスト <hostid
- role="fqdn">nice.people.org</hostid> の telnet ポートへの
+ <para>このコマンドは、ホスト <systemitem class="fqdomainname">evil.crackers.org</systemitem> から ホスト <systemitem class="fqdomainname">nice.people.org</systemitem> の telnet ポートへの
すべてのパケットを拒絶します。</para>
<screen>&prompt.root; <userinput>ipfw add deny tcp from evil.crackers.org to nice.people.org 23</userinput></screen>
- <para>次の例は、ネットワーク <hostid
- role="domainname">crackers.org</hostid> (クラス C) 全体から
- マシン <hostid role="fqdn">nice.people.org</hostid>
+ <para>次の例は、ネットワーク <systemitem class="fqdomainname">crackers.org</systemitem> (クラス C) 全体から
+ マシン <systemitem class="fqdomainname">nice.people.org</systemitem>
(の任意のポート) への 任意の TCP トラフィックを拒絶し、
ログを取ります。</para>
@@ -2937,8 +2909,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
</itemizedlist>
<para>これとは別のファイアウォール設定に 関するチェックリストが
- CERT から 入手可能です。<ulink
- url="http://www.cert.org/tech_tips/packet_filtering.html">http://www.cert.org/tech_tips/packet_filtering.html</ulink></para>
+ CERT から 入手可能です。<link xlink:href="http://www.cert.org/tech_tips/packet_filtering.html">http://www.cert.org/tech_tips/packet_filtering.html</link></para>
<para>前にも述べたように、これはただの <emphasis> ガイドライン
</emphasis> にすぎません。
@@ -2949,7 +2920,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
わたしたちは「いかなる」責任もとることはできません。</para>
</sect2>
- <sect2 id="ipfw-overhead">
+ <sect2 xml:id="ipfw-overhead">
<title>IPFW のオーバーヘッドと最適化</title>
<para>多くの人が IPFW
@@ -3029,7 +3000,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
</sect2>
</sect1>
- <sect1 id="openssl">
+ <sect1 xml:id="openssl">
<title>OpenSSL</title>
<indexterm>
<primary>セキュリティ</primary>
@@ -3038,7 +3009,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<indexterm><primary>OpenSSL</primary></indexterm>
<para>FreeBSD&nbsp;4.0 では、OpenSSL ツールキットが基本構成の一部に
- 含まれています。<ulink url="http://www.openssl.org/">OpenSSL</ulink> は、
+ 含まれています。<link xlink:href="http://www.openssl.org/">OpenSSL</link> は、
Secure Sockets Layer v2/v3 (SSLv2/SSLv3) や Transport Layer
Security v1 (TLSv1) ネットワークセキュリティプロトコルと同様の
多目的な暗号化ライブラリを提供します。</para>
@@ -3072,19 +3043,15 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
</sect2>
</sect1>
- <sect1 id="ipsec">
- <sect1info>
+ <sect1 xml:id="ipsec">
+ <info><title>IPsec</title>
<authorgroup>
- <author>
- <firstname>Yoshinobu</firstname>
- <surname>Inoue</surname>
- <contrib>寄稿: </contrib>
- </author>
+ <author><personname><firstname>Yoshinobu</firstname><surname>Inoue</surname></personname><contrib>寄稿: </contrib></author>
<!-- 5 Mar 2000 -->
</authorgroup>
- </sect1info>
+ </info>
- <title>IPsec</title>
+
<indexterm><primary>IPsec</primary></indexterm>
<indexterm>
<primary>セキュリティ</primary>
@@ -3107,25 +3074,21 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<tip>
<para>FreeBSD の IPsec 実装について説明した HOWTO は、他に
- <ulink
- url="http://www.daemonnews.org/200101/ipsec-howto.html"></ulink>
- と <ulink
- url="http://www.freebsddiary.org/ipsec.php"></ulink>
+ <uri xlink:href="http://www.daemonnews.org/200101/ipsec-howto.html">http://www.daemonnews.org/200101/ipsec-howto.html</uri>
+ と <uri xlink:href="http://www.freebsddiary.org/ipsec.php">http://www.freebsddiary.org/ipsec.php</uri>
があります。</para>
</tip>
<para>IPsec 機構は、IP 層とソケット層に対して安全な通信を提供します。
- この節ではその使い方を説明します。実装の詳細に関しては <ulink
- url="../../../en_US.ISO8859-1/books/developers-handbook/ipv6.html">The
- Developers' Handbook</ulink> を参照してください。
+ この節ではその使い方を説明します。実装の詳細に関しては <link xlink:href="../../../en_US.ISO8859-1/books/developers-handbook/ipv6.html">The
+ Developers' Handbook</link> を参照してください。
<!-- si006:2001/08/11 - developers handbook is not translated yet. -->
</para>
<para>現在の IPsec の実装は、
トランスポートモードとトンネルモードの両方に対応しています。
- しかし、トンネルモードにはいくつかの制限事項があります。<ulink
- url="http://www.kame.net/newsletter/">http://www.kame.net/newsletter/
- </ulink> にはより総合的な例が載っています。</para>
+ しかし、トンネルモードにはいくつかの制限事項があります。<link xlink:href="http://www.kame.net/newsletter/">http://www.kame.net/newsletter/
+ </link> にはより総合的な例が載っています。</para>
<para>ここで述べる機能を利用するには、以下のオプションをカーネルコ
ンパイル時に指定する必要があることにご注意ください。</para>
@@ -3136,8 +3099,8 @@ options IPSEC_ESP #IP security (crypto; define w/IPSEC)</progr
<sect2>
<title>IPv4 におけるトランスポートモードの例</title>
- <para>ホスト A (<hostid role="ipaddr">10.2.3.4</hostid>)
- とホスト B (<hostid role="ipaddr">10.6.7.8</hostid>)
+ <para>ホスト A (<systemitem class="ipaddress">10.2.3.4</systemitem>)
+ とホスト B (<systemitem class="ipaddress">10.6.7.8</systemitem>)
との間に安全なチャネルを配置するために、
セキュリティアソシエーションを設定しましょう。
ここでは、少し込み入った例を示します。ホスト A からホストB
@@ -3227,7 +3190,7 @@ B で:
^D</userinput>
- ホスト A -------------------------------------> ホスト B
+ ホスト A -------------------------------------&gt; ホスト B
10.2.3.4 10.6.7.8
| |
========== old AH keyed-md5 ==========&gt;
@@ -3256,7 +3219,7 @@ B で:
認証アルゴリズムは hmac-sha1 で、その鍵は <quote>this is the test
key</quote> とします。ホスト-A の設定は次のようになります。</para>
- <screen>&prompt.root; <userinput>setkey -c &lt;&lt;<filename>EOF</filename>
+ <screen>&prompt.root; <userinput>setkey -c &lt;&lt;EOF
spdadd fec0::10[any] fec0::11[110] tcp -P out ipsec
esp/transport/fec0::10-fec0::11/use ;
spdadd fec0::11[110] fec0::10[any] tcp -P in ipsec
@@ -3273,7 +3236,7 @@ B で:
<para>そしてホスト-B の設定は次のようになります。</para>
- <screen>&prompt.root; <userinput>setkey -c &lt;&lt;<filename>EOF</filename>
+ <screen>&prompt.root; <userinput>setkey -c &lt;&lt;EOF
spdadd fec0::11[110] fec0::10[any] tcp -P out ipsec
esp/transport/fec0::11-fec0::10/use ;
spdadd fec0::10[any] fec0::11[110] tcp -P in ipsec
@@ -3307,7 +3270,7 @@ B で:
<para>ゲートウェイ-A における設定は次のようになります。</para>
- <screen>&prompt.root; <userinput>setkey -c &lt;&lt;<filename>EOF</filename>
+ <screen>&prompt.root; <userinput>setkey -c &lt;&lt;EOF
spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec
ah/tunnel/172.16.0.1-172.16.0.2/require ;
spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec
@@ -3327,7 +3290,7 @@ EOF</userinput></screen>
<para>そしてゲートウェイ-B では次のようになります。</para>
- <screen>&prompt.root; <userinput>setkey -c &lt;&lt;<filename>EOF</filename>
+ <screen>&prompt.root; <userinput>setkey -c &lt;&lt;EOF
spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec
ah/tunnel/172.16.0.2-172.16.0.1/require ;
spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec
@@ -3362,7 +3325,7 @@ EOF</userinput></screen>
hmac-sha1 とします。AH の認証アルゴリズムは hmac-md5 とします。
ゲートウェイ-A での設定は次のようになります。</para>
- <screen>&prompt.root; <userinput>setkey -c &lt;&lt;<filename>EOF</filename>
+ <screen>&prompt.root; <userinput>setkey -c &lt;&lt;EOF
spdadd fec0:0:0:1::/64 fec0:0:0:2::/64 any -P out ipsec
esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require
ah/transport/fec0:0:0:1::1-fec0:0:0:2::1/require ;
@@ -3402,7 +3365,7 @@ EOF</userinput></screen>
<para>ホスト-A での設定は次のようになります。</para>
- <screen>&prompt.root; <userinput>setkey -c &lt;&lt;<filename>EOF</filename>
+ <screen>&prompt.root; <userinput>setkey -c &lt;&lt;EOF
spdadd fec0:0:0:1::1[any] fec0:0:0:2::2[80] tcp -P out ipsec
esp/transport/fec0:0:0:1::1-fec0:0:0:2::2/use
esp/tunnel/fec0:0:0:1::1-fec0:0:0:2::1/require ;
@@ -3428,19 +3391,15 @@ EOF</userinput></screen>
</sect2>
</sect1>
- <sect1 id="openssh">
- <sect1info>
+ <sect1 xml:id="openssh">
+ <info><title>OpenSSH</title>
<authorgroup>
- <author>
- <firstname>Chern</firstname>
- <surname>Lee</surname>
- <contrib>寄稿: </contrib>
- </author>
+ <author><personname><firstname>Chern</firstname><surname>Lee</surname></personname><contrib>寄稿: </contrib></author>
<!-- 21 April 2001 -->
</authorgroup>
- </sect1info>
+ </info>
- <title>OpenSSH</title>
+
<indexterm><primary>OpenSSH</primary></indexterm>
<indexterm>
<primary>セキュリティ</primary>
@@ -3500,7 +3459,7 @@ EOF</userinput></screen>
<para>&man.ssh.1; ユーティリティは
&man.rlogin.1; と同様に働きます。</para>
- <screen>&prompt.root; <userinput>ssh <replaceable>user@example.com</replaceable></userinput>
+ <screen>&prompt.root; <userinput>ssh user@example.com</userinput>
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? <userinput>yes</userinput>
Host 'example.com' added to the list of known hosts.
@@ -3542,7 +3501,7 @@ user@example.com's password: <userinput>*******</userinput></screen>
安全な方法で行っているほかは、ローカルのファイルをリモートマシンへ、
あるいはリモートマシンのファイルをローカルにコピーするのは同じです。</para>
- <screen>&prompt.root; <userinput> scp <replaceable>user@example.com:/COPYRIGHT COPYRIGHT</replaceable></userinput>
+ <screen>&prompt.root; <userinput> scp user@example.com:/COPYRIGHT COPYRIGHT</userinput>
user@example.com's password: <userinput>*******</userinput>
COPYRIGHT 100% |*****************************| 4735
00:00
@@ -3556,7 +3515,7 @@ COPYRIGHT 100% |*****************************| 4735
1 つめの引数になり、コピー先が 2 つめの引数になります。
ファイルはネットワーク越しに SSH を通して送られるので、
引数に指定するファイルには
- <option>user@host:&lt;path_to_remote_file></option>
+ <option>user@host:&lt;path_to_remote_file&gt;</option>
という形式をとるものがあります。</para>
</sect2>
@@ -3642,7 +3601,7 @@ Your identification has been saved in /home/user/.ssh/identity.
<para>以下のコマンドは &man.ssh.1; で telnet
用のトンネルを作成します。</para>
- <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5023:localhost:23 user@foo.example.com</replaceable></userinput>
+ <screen>&prompt.user; <userinput>ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com</userinput>
&prompt.user;</screen>
<para><command>ssh</command> コマンドは、
@@ -3696,15 +3655,15 @@ Your identification has been saved in /home/user/.ssh/identity.
</varlistentry>
</variablelist>
- <para>SSH のトンネルは <hostid>localhost</hostid>
+ <para>SSH のトンネルは <systemitem>localhost</systemitem>
の指定されたポートに listen
するソケットを作ることで実現されています。
SSH はローカルのホスト/ポートで受けた接続すべてを SSH
接続経由で指定されたリモートホストのポートへ転送します。</para>
- <para>この例では、<hostid>localhost</hostid> のポート
+ <para>この例では、<systemitem>localhost</systemitem> のポート
<replaceable>5023</replaceable> がリモートマシンの
- <hostid>localhost</hostid> のポート <replaceable>23</replaceable>
+ <systemitem>localhost</systemitem> のポート <replaceable>23</replaceable>
に転送されるようになっています。
<replaceable>23</replaceable> は telnet なのでこれは SSH
トンネルを通るセキュアな telnet セッションを作ります。</para>
@@ -3715,7 +3674,7 @@ Your identification has been saved in /home/user/.ssh/identity.
<example>
<title>SSH を用いた SMTP 用の安全なトンネルの作成</title>
- <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5025:localhost:25 user@mailserver.example.com</replaceable></userinput>
+ <screen>&prompt.user; <userinput>ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com</userinput>
user@mailserver.example.com's password: <userinput>*****</userinput>
&prompt.user; <userinput>telnet localhost 5025</userinput>
@@ -3746,14 +3705,14 @@ Escape character is '^]'.
解決策は、オフィスの SSH サーバへの SSH 接続を行い、
メールサーバへのトンネルを作成することです。</para>
- <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>2110:mail.example.com:110 user@ssh-server.example.com</replaceable></userinput>
+ <screen>&prompt.user; <userinput>ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com</userinput>
user@ssh-server.example.com's password: <userinput>******</userinput></screen>
<para>トンネルが作成されて動作したら、
- メールクライアントに対し <hostid>localhost</hostid>
+ メールクライアントに対し <systemitem>localhost</systemitem>
のポート 2110 に POP3 リクエストを送るように指示できます。
そこへの接続は、トンネルを経由して安全に
- <hostid>mail.example.com</hostid> に転送されます。</para>
+ <systemitem>mail.example.com</systemitem> に転送されます。</para>
</sect4>
<sect4>
@@ -3778,11 +3737,11 @@ user@ssh-server.example.com's password: <userinput>******</userinput></screen>
SSH 接続を行い、Ogg Vorbis
サーバへのトンネルに利用することです。</para>
- <screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>8888:music.example.com:8000 user@unfirewalled.myserver.com</replaceable></userinput>
+ <screen>&prompt.user; <userinput>ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled.myserver.com</userinput>
user@unfirewalled.myserver.com's password: <userinput>*******</userinput></screen>
- <para>ストリーミングクライアントを <hostid>localhost</hostid>
- の 8888 番ポートに向けると、<hostid>music.example.com</hostid>
+ <para>ストリーミングクライアントを <systemitem>localhost</systemitem>
+ の 8888 番ポートに向けると、<systemitem>music.example.com</systemitem>
の 8000 番ポートに転送され、
ファイアウォールをすり抜けられます。</para>
</sect4>
@@ -3792,7 +3751,7 @@ user@unfirewalled.myserver.com's password: <userinput>*******</userinput></scree
<sect2>
<title>もっと詳しく知りたい人へ</title>
- <para><ulink url="http://www.openssh.com/">OpenSSH</ulink></para>
+ <para><link xlink:href="http://www.openssh.com/">OpenSSH</link></para>
<para>&man.ssh.1; &man.scp.1; &man.ssh-keygen.1;
&man.ssh-agent.1; &man.ssh-add.1;</para>