os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Merge the following from the English version:

Browse source 
1.88 -> 1.95	doc/ja_JP.eucJP/books/handbook/security/chapter.sgml

Submitted by:	Hiroo Ono <hiroo _at_ jp dot FreeBSD dot org>
Reference :	[doc-jp-work 1727]
This commit is contained in:
Ryusuke SUZUKI 2010-12-23 03:06:14 +00:00
parent 23f276a068
commit ec01b3345e
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=36715
1 changed files with 138 additions and 107 deletions

245
ja_JP.eucJP/books/handbook/security/chapter.sgml
View file

@ -2,7 +2,7 @@
The FreeBSD Documentation Project
The FreeBSD Japanese Documentation Project
Original revision: 1.88
Original revision: 1.95
Waiting for: 1.123 or mac/chapter.sgml
("mac" referenced from disks).
Translation note: "fs-acl" section added in rev.1.118 is moved to
@ -131,7 +131,8 @@
<para>また、システムセキュリティには、
さまざまな形での攻撃に対処することとも関係しています。
攻撃の中には root 権限を奪おうとはしないけれども、
攻撃の中には <username>root</username>
権限を奪おう (<quote>root 権限を破る</quote>) とはしないけれども、
クラッシュやシステムの不安定状態を引き起こそうとするものもあります。
このセキュリティ問題は、いくつかに分類することが可能です。</para>
@ -208,11 +209,13 @@
ログを解析して、疑わしい送信元アドレスを探すものです。</para>
<para>ひとたび攻撃者がユーザアカウントへのアクセス権を入手したら、
攻撃者が root 権限を破る可能性があることを仮定するべきです。
攻撃者は <username>root</username> 権限を破れると仮定するべきです。
しかし、セキュリティを十分維持し、手入れの行き届いたシステムにおい
ては、あるユーザアカウントへのアクセスが可能となっても、攻撃者に
必ずしも root へのアクセス権を与えるとは限りません。こ
の違いは重要です。というのは、一般的に root へのアクセス権がなければ、
ては、あるユーザアカウントへのアクセスが可能となっても、
必ずしも攻撃者に <username>root</username>
へのアクセス権を与えるとは限りません。この違いは重要です。
というのは、一般的に
<username>root</username> へのアクセス権がなければ、
攻撃者は自分の侵入の痕跡を隠蔽することができませんし、
そのユーザのファイルを引っかき回したり、
マシンをクラッシュさせたりするのがせいぜいです。
@ -225,20 +228,27 @@
<secondary>裏口 (バックドア)</secondary>
</indexterm>
<para>システム管理者は、あるマシン上で root 権限を奪取する方法は、
<para>システム管理者は、あるマシン上で <username>root</username>
権限を奪取する方法は、
潜在的に何通りもあるということを心しておかねばなりません。
攻撃者は root のパスワードを知っているかもしれませんし、
攻撃者が root 権限で実行されているサーバのバグを見つけ、
ネットワーク接続を介して root 権限を破ることができるかもしれません。
攻撃者は <username>root</username>
のパスワードを知っているかもしれませんし、
攻撃者が <username>root</username>
権限で実行されているサーバのバグを見つけ、
ネットワーク接続を介して
<username>root</username> 権限を破ることができるかもしれません。
また、攻撃者は suid-root プログラムに存在するバグを知っていて、
ユーザアカウントを破れば root 権限を奪取できるかもしれません。
攻撃者があるマシン上で root 権限を破る方法を知ったならば、
ユーザアカウントを破れば
<username>root</username> 権限を奪取できるかもしれません。
攻撃者があるマシン上で
<username>root</username> 権限を破る方法を知ったならば、
攻撃者は裏口を用意する必要がありません。
これまでに発見され、ふさがれた root の穴の多くには、
攻撃者が自分のしたことの痕跡を消そうとした作業が、
これまでに発見され、ふさがれた <username>root</username>
の穴の多くには、攻撃者が自分のしたことの痕跡を消そうとした作業が、
かなりの割合で含まれています。
そのため、ほとんどの攻撃者は裏口を作るのです。裏口は、
攻撃者がたやすくシステムへの root アクセスを再び得られるようにしますが、
攻撃者がたやすくシステムへの
<username>root</username> アクセスを再び得られるようにしますが、
有能な管理者に侵入を検知する便利な手段を与えるものでもあります。
攻撃者に裏口を作らせないようにするということは、
セキュリティにとっては実際には良くないことかもしれません。
@ -252,12 +262,14 @@
<orderedlist>
<listitem>
<para>root とスタッフのアカウントの安全性を高める。</para>
<para><username>root</username>
とスタッフのアカウントの安全性を高める。</para>
</listitem>
<listitem>
<para>root の安全性を高める &ndash; root 権限で動作するサーバ
と suid/sgid バイナリ。</para>
<para><username>root</username> の安全性を高める &ndash;
<username>root</username> 権限で動作するサーバと
suid/sgid バイナリ。</para>
</listitem>
<listitem>
@ -308,44 +320,53 @@
述べます。</para>
<sect2 id="securing-root-and-staff">
<title><username>root</username> アカウントとスタッフアカウントの安全性を高める</title>
<title><username>root</username>
アカウントとスタッフアカウントの安全性を高める</title>
<indexterm>
<primary><command>su</command></primary>
</indexterm>
<para>root のアカウントの安全性を確保しないうちからスタッフのア
カウントの安全性をうんぬんしてもしかたがありません。ほとんどの
システムでは、root アカウントに割り当てたパスワードが 1 つあり
<para><username>root</username>
のアカウントの安全性を確保しないうちから
スタッフのアカウントの安全性をうんぬんしてもしかたがありません。
ほとんどのシステムでは、<username>root</username>
アカウントに割り当てたパスワードが 1 つあり
ます。まず最初にすべきことは、このパスワードは<emphasis>いつで
も</emphasis>不正利用の危険に晒されていると仮定することです。これは
root のパスワードを消すべきだと言っているのではありません。
root のパスワードは、マシンにコンソールからアクセスするのには、
<username>root</username>
のパスワードを消すべきだと言っているのではありません。
<username>root</username>
のパスワードは、マシンにコンソールからアクセスするのには、
ほとんどいつでも必要なものです。ここで言いたいのは、コンソール
以外からは、そして可能なら &man.su.1; コマンドを実行する場合も
root のパスワードを使えないようにするべきである、ということで
<username>root</username>
のパスワードを使えないようにするべきである、ということで
す。たとえば、あなたが使っている pty が、
<filename>/etc/ttys</filename> ファイルで unsecure と指定
されているか確認してください。そうすると、
<command>telnet</command> や <command>rlogin</command> 経由では
root で直接ログインできないようになります。
<username>root</username> で直接ログインできないようになります。
これは、<filename>/etc/ssh/sshd_config</filename> を編集して
<literal>PermitRootLogin</literal> に <literal>NO</literal>
が設定されるようにすることで実現できます。
<application>sshd</application> のような、別のログインサービス
を使っている場合でも同様に、直接 root へログインすることを許し
を使っている場合でも同様に、直接 <username>root</username>
へログインすることを許し
ていないかどうか確認してください。すべてのアクセス手段 &ndash;
たとえば FTP
のようなサービスが、良くクラックの対象となることを考えましょう。
root への直接ログインは、
<username>root</username> への直接ログインは、
システムコンソール経由でのみ可能であるべきなのです。</para>
<indexterm>
<primary><groupname>wheel</groupname></primary>
</indexterm>
<para>また当然、システム管理者として自分が root になれるようにしておく必要が
<para>また当然、システム管理者として自分が <username>root</username>
になれるようにしておく必要が
ありますから、そのための穴をいくつか開けておきます。し
かし、それらの穴を動作させるには、さらに追加のパスワード認証が
必要であるようにしておくことが重要です。root でアクセス可能と
必要であるようにしておくことが重要です。
<username>root</username> でアクセス可能と
する方法の一つとして、適切なスタッフアカウントを
(<filename>/etc/group</filename> 中の)
<groupname>wheel</groupname> グループに加えることがあります。
@ -360,20 +381,23 @@
<groupname>wheel</groupname> グループに加えるべきです。実際に
<username>root</username> アクセスの必要なスタッフメンバのみ
<groupname>wheel</groupname> グループに置くようにすべきです。
他の認証方法の場合、たとえば
kerberos を使用する場合には、root アカウントの
<filename>.k5login</filename> ファイルを使って、誰も
<groupname>wheel</groupname> グループに置く必要なく &man.ksu.1;
を使って root になることを許すようにすることもできます。このやり
他の認証方法の場合、たとえば Kerberos を使用する場合には、
<username>root</username> アカウントの
Kerberos <filename>.k5login</filename> ファイルを使えば、誰も
<groupname>wheel</groupname> グループに置く必要なく
<username>root</username> に &man.ksu.1;
することを許可できます。このやり
方はよりよい解決策なのかもしれません。なぜなら、
<literal>wheel</literal> のメカニズムでは、侵入者がパスワード
ファイルを手に入れ、スタッフアカウントのいずれか 1 つを破るこ
とができると、root を破ることがまだできてしまうからです。
とができると、
<username>root</username> を破ることがまだできてしまうからです。
<groupname>wheel</groupname> のメカニズムを用いる方が、
何もしないよりは良いのですが、
必ずしも最も安全な選択肢とは限りません。</para>
<para>スタッフのアカウント、また究極には root アカウントの安全性
<para>スタッフのアカウント、また究極には
<username>root</username> アカウントの安全性
を高める間接的な方法は、別のログインアクセスの方法を用いてスタッ
フのアカウントの安全性を高め、その上でそのスタッフのアカウント
の暗号化パスワードを <quote>アスタリスク化</quote>
@ -398,9 +422,8 @@
こうした後は、スタッフメンバは認証のために &man.kerberos.1; や
公開鍵 / 秘密鍵の組を用いる &man.ssh.1; のような代わりとなる認
証手段を利用しなければなりません。
Kerberos のようなログイン機構を使う場合は、一般に kerberos サー
バを実行するマシンと自分のデスクトップワークステーションの安全
性を確保しなければなりません。
Kerberos のようなログイン機構を使う場合は、一般に Kerberos
サーバを実行するマシンと自分のデスクトップワークステーションの安全性を確保しなければなりません。
また ssh で公開鍵 / 秘密鍵の組を使う場合、
一般に、<emphasis>ログイン元</emphasis>マシン (通常は自分のワー
クステーション) の安全性を確保しなければなりません。ここで、
@ -442,9 +465,9 @@
きに、すべてのマシンでスタッフメンバのパスワードを即座に変更す
る能力を過小評価してはいけません。パスワードが分散されている状
況では、N 台のマシンでパスワードを変更すると、てんやわんやの事
態を招く可能性があります。kerberos を使用すると、パスワードの
態を招く可能性があります。Kerberos を使用すると、パスワードの
再発行に制限 (re-passwording restriction) を課することもできま
す。この機能を使うことにより、ある kerberos チケットをしばらく
す。この機能を使うことにより、ある Kerberos チケットをしばらく
経つとタイムアウトにすることができるだけでなく、一定期間 ( 例
えば、1 ヶ月に 1 回) 経つと、ユーザに新しいパスワードを選ぶよ
うに要求することもできます。</para>
@ -482,14 +505,14 @@
ていがちだということに注意して下さい。たとえば、古いバージョンの
<application>imapd</application> や
<application>popper</application>
を実行させておくのは、全世界に万能の root
を実行させておくのは、全世界に万能の <username>root</username>
の切符を与えているようなものです。自分で注意深くチェックしていない
サーバは、決して実行してはいけません。root で実行させる必要の
あるサーバはほとんどありません。たとえば、
サーバは、決して実行してはいけません。<username>root</username>
で実行させる必要のあるサーバはほとんどありません。たとえば、
<application>ntalk</application>,
<application>comsat</application>,
<application>finger</application> デーモンを、専用ユーザの
<literal>砂場 (sandbox)</literal> で実行させることができます。
<firstterm>砂場 (sandbox)</firstterm> で実行させることができます。
管理者が膨大な数の問題を経験していないのなら、
この「砂場」は完
璧ではありませんが、セキュリティに関するタマネギ的アプローチは
@ -497,8 +520,9 @@
して侵入を果たすことができたとしても、攻撃者はさらに砂場から外
に脱出しなければなりません。攻撃者が通過せねばならない層の数が
増えれば増えるほど、それだけ攻撃者が侵入に成功する確率が減りま
す。root の抜け穴は歴史的に、基本システムサーバも含め、root 権
限で実行されるほとんどすべてのサーバプロセスで発見されています。
す。Root の抜け穴は歴史的に、基本システムサーバも含め、
<username>root</username>
権限で実行されるほとんどすべてのサーバプロセスで発見されています。
ユーザが <application>sshd</application> 経由でのみログインし、
<application>telnetd</application>,
<application>rshd</application>,
@ -531,21 +555,26 @@
のサーバには代わりとなるものがありますが、代わりのものをインス
トールするには、あなたが思うより多くの仕事が必要になるかもしれ
ません (便利さという要素がまたも勝利を収めるわけです)。これら
のサーバは、root 権限で実行せねばならないかもしれません。また、
のサーバは、<username>root</username>
権限で実行しなければばならないかもしれません。また、
これらのサーバ経由で生じる侵入を検出するためには、他の仕組みに
頼らなくてはならないかもしれません。</para>
<para>システムの root 権限の潜在的な穴で他に大きなものとして、シ
<para>システムの <username>root</username>
権限の潜在的な穴で他に大きなものには、シ
ステムにインストールされた suid-root/sgid バイナリがあります。
これらのバイナリは、<application>rlogin</application> のように、
<filename>/bin</filename>, <filename>/sbin</filename>,
<filename>/usr/bin</filename>, <filename>/usr/sbin</filename>
に存在するものがほとんどです。100% 安全なものは存在しないとは
いえ、システムデフォルトの siud/sgid バイナリは比較的安全とい
えます。それでもなお、root の穴がこれらのバイナリにときおり発
見されています。1998 年に <literal>Xlib</literal> で見つかった
root の穴は、<application>xterm</application> (普通、suid 設定
されています)を脆弱にしてしまいました。安全である方がよいので、
えます。それでもなお、<username>root</username>
セキュリティホールがこれらのバイナリにときおり発見されています。
1998 年に <application>xterm</application>
(普通、suid 設定されています) を脆弱にしていた
<literal>Xlib</literal> の <username>root</username>
セキュリティホールが見つかりました。
安全である方がよいので、
用心深いシステム管理者は残念に思いながらも、スタッフのみが実行
する必要がある suid バイナリは、スタッフのみがアクセス可能な特
別なグループに含めるように制限を加え、誰も使わない suid バイナ
@ -582,7 +611,7 @@
者は勝利し、ユーザのアカウントの安全を適切に確保できるかもしれ
ません。それができないならば、よりいっそう気を配って一般ユーザ
のアカウントを監視するよりほかありません。
一般ユーザアカウントに対し ssh や kerberos を利用することには、
一般ユーザアカウントに対し ssh や Kerberos を利用することには、
システム管理がさらに増えたりテクニカルサポートが必要に
なるなどの問題があります。それでも、暗号化パスワードファイルと
比較するとはるかに良い解です。</para>
@ -593,23 +622,25 @@
<para>できるだけ多くのパスワードを <literal>*</literal> で外し、
それらのアカウントのアクセスには
ssh や kerberos を使うようにすることが、唯一の確実な方法です。
ssh や Kerberos を使うようにすることが、唯一の確実な方法です。
暗号化パスワードファイル
(<filename>/etc/spwd.db</filename>) は root でのみ読み出し可能
だといっても、侵入者が root の書き込み権限は得られなくとも、読
み出しアクセス権限を得ることは可能かもしれません。</para>
(<filename>/etc/spwd.db</filename>) は <username>root</username>
でのみ読み出し可能だけれども、
たとえ、侵入者が root の書き込み権限は得られなくとも、
読み出しアクセス権限を得ることは可能かもしれません。</para>
<para>セキュリティスクリプトで常にパスワードファイルの変更をチェッ
クし、報告するようにすべきです (<link
linkend="security-integrity">ファイルの完全性のチェック</link>
参照)。</para>
節参照)。</para>
</sect2>
<sect2>
<title>カーネルのコア、raw デバイス、ファイルシステムの安全性を
高める</title>
<para>root の権限を破ると、攻撃者は何でもできますが、特に重宝さ
<para><username>root</username>
の権限を破ると、攻撃者はほとんど何でもできますが、特に重宝さ
れる特定の事柄もいくつかあります。たとえば、最近のカーネルは、組
み込みのパケット覗き見デバイス (packet sniffing device) ドライ
バを備えているものがほとんどです。FreeBSD では
@ -856,7 +887,8 @@
<para>境界ルータのところでファイアウォールを設けて、外部からのア
クセスに対して内部サービスを防御するという考えは実によいもので
す。この考えは、LAN の外部からの飽和攻撃を防ぐことにあり、内部
サービスをネットワークベースの root 権限への攻撃から防御するこ
サービスをネットワークベースの <username>root</username>
権限への攻撃から防御するこ
とにはあまり考慮を払っていません。ファイアウォールは常に排他的
に設定して下さい。つまり、<quote>ポート A, B, C, D と M から Z
まで<emphasis>以外</emphasis> のすべてにファイアウォールを設ける</quote>
@ -968,13 +1000,13 @@
<indexterm><primary><command>ssh</command></primary></indexterm>
<indexterm><primary>Kerberos</primary></indexterm>
<para>もしあなたが、kerberos と ssh を使いたいのだとしたら、
<para>もしあなたが、Kerberos と ssh を使いたいのだとしたら、
両者に関して言っておかねばならない問題がいくつかあります。
kerberos V は大変優れた認証プロトコルですが、kerberos 化された
Kerberos V は大変優れた認証プロトコルですが、Kerberos 化された
<application>telnet</application> や
<application>rlogin</application> は、バイナリストリームを扱う
のに不向きになってしまうようなバグがあります。さらに、デフォル
トでは、kerberos は <option>-x</option> オプションを使わない限
トでは、Kerberos は <option>-x</option> オプションを使わない限
りセッションを暗号化してくれません。
<application>ssh</application> では、デフォルトですべてを暗号
化してくれます。</para>
@ -988,18 +1020,18 @@
実際の鍵そのものが見えてしまうわけではありませんが、
ssh はあなたが login
している間、転送用ポートを作ります。攻撃者が安全でないマシンの
root を破ったら、このポートを使って暗号鍵を取得し、
<username>root</username> を破ったら、このポートを使って暗号鍵を取得し、
この暗号鍵でロックが外れる他のマシンへのアクセスを得てしまいます。
</para>
<para>スタッフのログインには、kerberos を組み合せた
<para>スタッフのログインには、Kerberos を組み合せた
ssh を使用することを勧めます。
<application>ssh</application> は、kerberos サポート機能と一緒
<application>ssh</application> は、Kerberos 対応機能と一緒
にコンパイルできます。こうすると、見えてしまうかもしれない
ssh 鍵をあまりあてにしないで良いようになります。
また、それと同時に、kerberos 経由でパスワードを保護することもできます。
また、それと同時に、Kerberos 経由でパスワードを保護することもできます。
ssh 鍵は、安全なマシンからの自動化されたタスク
(kerberos はこの用途には不向きです) のみに使用するべきです。また、
(Kerberos はこの用途には不向きです) のみに使用するべきです。また、
ssh の設定で鍵転送をしないようにするか、あるいは ssh が
<filename>authorized_keys</filename> ファイル中に書くことを許
している <literal>from=IP/DOMAIN</literal> オプションを使用し
@ -1309,12 +1341,9 @@ MOS MALL GOAT ARM AVID COED
<sect2>
<title>信頼できない通信路での初期化</title>
<para>信頼できない通信路を使って、秘密のパスフレーズを変更するためには、
信頼できる通信路として、その信頼
できない通信路とは別のものを用意する必要があります。
その信頼できる通信路は
<command>key</command> または <command>opiekey</command>
プログラムを実行するために必要となるもので、
<para>信頼できない通信路を使って秘密のパスフレーズを初期化または変更するためには、
それとは別に <command>key</command> または <command>opiekey</command>
プログラムを実行するための信頼できる通信路を用意しておく必要があります。
たとえばそれは、あなたが信頼できる Macintosh
のデスクアクセサリや信頼できるマシンのシェルプロンプトだったり
するでしょう。(訳注: ここでの通信路とはマシンそのものになりま
@ -1360,8 +1389,9 @@ LINE PAP MILK NELL BUOY TROY
</screen>
<para>デフォルトのシード (<command>keyinit</command> プログラム
は困ったことにこれを <literal>key</literal> と読んでいるのです
が、混乱しないよう注意してください) で構わなければ、リターンキー
は困ったことにこれを <literal>key</literal>
と呼んでいるのですが、混乱しないよう注意してください)
で構わなければ、<keycap>Return</keycap>
を押してください。次に、アクセスパスワードを入れる前に、あらか
じめ用意しておいた信頼できる通信路(信頼できるマシンや信頼でき
る S/Key デスクアクセサリなど) へ移って、先ほどと同じパラメータ
@ -1417,8 +1447,8 @@ Password: </screen>
<para>ここでは表示していませんが、S/Key と OPIE
のプロンプトには便利な機能が備わっています。
パスワードプロンプトに対して、
何も入力せずにリターンを押すとエコーモードに切り替わります。
パスワードプロンプトに対して、何も入力せずに
<keycap>Return</keycap> を押すとエコーモードに切り替わります。
つまりタイプした文字がそのまま見えるようになるのです。
これは、紙に印刷していたりするワンタイムパスワードを
手で入力しなければならない場合に特に役立つ機能です。</para>
@ -1940,9 +1970,10 @@ Password changed.</screen>
<sect2>
<title><command>su</command> 特権の追加</title>
<para>root 権限が必要なユーザは<emphasis>誰でも</emphasis>、
<para>Kerberos は <username>root</username> 権限が必要な
<emphasis>各</emphasis> ユーザに対し、
<command>su</command> コマンドのパスワードをユーザ毎に
<emphasis>別のもの</emphasis> として持つことができます。
<emphasis>別のもの</emphasis> として持つことを可能にします。
<username>root</username> に <command>su</command>
できる権利を与えられた id を追加します。これは、
principal に付いている <username>root</username>
@ -2021,11 +2052,11 @@ May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM</screen>
<literal>&lt;username&gt;.</literal><username>root</username>
という形式の
<literal>&lt;principal&gt;.&lt;instance&gt;</literal>で、
必要なエント
リが<username>root</username>のホームディレクトリの
<filename>.klogin</filename>ファイルに あれば、
<literal>&lt;username&gt;</literal>がrootに
<command>su</command>することができます。</para>
必要なエントリが <username>root</username> のホームディレクトリの
<filename>.klogin</filename> ファイルにあれば、
<literal>&lt;username&gt;</literal> が
<username>root</username> に
<command>su</command> できます。</para>
<screen>&prompt.root; <userinput>cat /root/.klogin</userinput>
jane.root@EXAMPLE.COM</screen>
@ -2292,9 +2323,9 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
そのため、どのファシリティ (機能) を必要とするかによって、
1 つまたは複数のオプションをカーネルコンフィグレーションファイルに追加し、
カーネルを再コンパイルする必要があるでしょう。
カーネルの再コンパイル方法の詳細については、<link
linkend="kernelconfig">カーネルコンフィグレーション</link>
を参照してください。</para>
カーネルの再コンパイル方法の詳細については、
「カーネルのコンフィグレーション」(<xref linkend="kernelconfig">)
をご覧ください。</para>
<para>現在、IPFW
に関係するカーネルコンフィグレーションオプションは
@ -3021,7 +3052,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<para>IPsec 機構は、IP 層とソケット層に対して安全な通信を提供します。
実装の詳細に関しては <ulink
url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/developers-handbook/ipv6.html">
url="../../../en_US.ISO8859-1/books/developers-handbook/ipv6.html">The
Developers' Handbook</ulink> を参照してください。
<!-- si006:2001/08/11 - developers handbook is not translated yet. -->
</para>
@ -3411,11 +3442,11 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec
<para>&man.ssh.1; ユーティリティは
&man.rlogin.1; と同様に働きます。</para>
<screen>&prompt.root <userinput>ssh user@foobardomain.com</userinput>
<screen>&prompt.root <userinput>ssh <replaceable>user@example.com</replaceable></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 'foobardomain.com' added to the list of known hosts.
user@foobardomain.com's password: <userinput>*******</userinput></screen>
Host 'example.com' added to the list of known hosts.
user@example.com's password: <userinput>*******</userinput></screen>
<para>ログインは <command>rlogin</command> や telnet
でセッションを張った時と同様に続きます。
@ -3452,8 +3483,8 @@ user@foobardomain.com's password: <userinput>*******</userinput></screen>
安全な方法で行っているほかは、ローカルのファイルをリモートマシンへ、
あるいはリモートマシンのファイルをローカルにコピーするのは同じです。</para>
<screen>&prompt.root <userinput> scp <replaceable>user@foobardomain.com:/COPYRIGHT COPYRIGHT</replaceable></userinput>
user@foobardomain.com's password:
<screen>&prompt.root <userinput> scp <replaceable>user@example.com:/COPYRIGHT COPYRIGHT</replaceable></userinput>
user@example.com's password:
COPYRIGHT 100% |*****************************| 4735
00:00
&prompt.root</screen>
@ -3550,7 +3581,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.bar.com</replaceable></userinput>
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5023:localhost:23 user@foo.example.com</replaceable></userinput>
&prompt.user;</screen>
<para><command>ssh</command> コマンドは、
@ -3596,7 +3627,7 @@ Your identification has been saved in /home/user/.ssh/identity.
</varlistentry>
<varlistentry>
<term><option>user@foo.bar.com</option></term>
<term><option>user@foo.example.com</option></term>
<listitem>
<para>リモートの SSH サーバです。</para>
@ -3620,13 +3651,13 @@ Your identification has been saved in /home/user/.ssh/identity.
<para>典型的な SSH トンネル</para>
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5025:localhost:25 user@mailserver.foobar.com</replaceable></userinput>
user@mailserver.foobar.com's password: <userinput>*****</userinput>
<screen>&prompt.user; <userinput>ssh -2 -N -f -L <replaceable>5025:localhost:25 user@mailserver.example.com</replaceable></userinput>
user@mailserver.example.com's password: <userinput>*****</userinput>
&prompt.user; <userinput>telnet localhost 5025</userinput>
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.foobar.com ESMTP</screen>
220 mailserver.example.com ESMTP</screen>
<para>&man.ssh-keygen.1; と別のユーザアカウントを組み合わせて使うことで
より透過的で悩まずに済むような SSH のトンネル環境を作ることができます。
@ -3648,14 +3679,14 @@ Escape character is '^]'.
解決策は、オフィスの SSH サーバへの SSH 接続を行い、
メールサーバへのトンネルを作成することです。</para>
<screen>&prompt.user; ssh -2 -N -f -L 2110:mail.office-foobar.com user@ssh-server.office-foobar.com
user@ssh-server.office-foobar.com's password: ******</screen>
<screen>&prompt.user; ssh -2 -N -f -L 2110:mail.example.com user@ssh-server.example.com
user@ssh-server.example.com's password: ******</screen>
<para>トンネルが作成されて動作したら、
メールクライアントに対し <hostid>localhost</hostid>
のポート 2110 に POP3 リクエストを送るように指示できます。
そこへの接続は、トンネルを経由して安全に
<hostid>mail.office-foobar.com</hostid> に転送されます。</para>
<hostid>mail.example.com</hostid> に転送されます。</para>
</sect4>
<sect4>
@ -3680,11 +3711,11 @@ user@ssh-server.office-foobar.com's password: ******</screen>
SSH 接続を行い、Ogg Vorbis
サーバへのトンネルに利用することです。</para>
<screen>&prompt.user; ssh -2 -N -f -L 8888:music.foobar.com:8000 user@unfirewalled.myserver.com
<screen>&prompt.user; ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled.myserver.com
user@unfirewalled.myserver.com's password: *******</screen>
<para>ストリーミングクライアントを <hostid>localhost</hostid>
の 8888 番ポートに向けると、<hostid>music.foobar.com</hostid>
の 8888 番ポートに向けると、<hostid>music.example.com</hostid>
の 8000 番ポートに転送され、
ファイアウォールをすり抜けられます。</para>
</sect4>
@ -3694,7 +3725,7 @@ user@unfirewalled.myserver.com's password: *******</screen>
<sect2>
<title>もっと詳しく知りたい人へ</title>
<para><ulink url="http://www.openssh.com">OpenSSH</ulink></para>
<para><ulink url="http://www.openssh.com/">OpenSSH</ulink></para>
<para>&man.ssh.1; &man.scp.1; &man.ssh-keygen.1;
&man.ssh-agent.1; &man.ssh-add.1;</para>