* BSDMagazine * BSD magazine No.6 特集2「セキュリティを考える」 * Title: SSH * Author: すずきひろのぶ(ソフトウエアコンサルタント) * E-mail: hironobu@h2np.net これはアスキー BSDマガジン2000年6月号に寄稿した生原稿です。 BSDマガジン2000年6月号 http://www.ascii.co.jp/BSDmag/200006 * SSH SSH (Secure SHell)はrlogin、rsh、rcpといったBSDの流れを汲むいわゆる"r" コマンド類を置き換えるために作られた暗号ツールである。"r"コマンドはネッ トワーク経由でリモートマシンにログインしたり、コマンド実行したり、ある いはファイルをコピーしたりするコマンドだが、これらは共通してユーザ認証 などが甘い。今までのリモートログインツール一般について言えることだが、 rloginやtelnetを用いてログインする際のパスワード入力が保護されないまま ネットワークを流れてしまうのは大きな問題がある。またネットワーク上に保 護されないデータが流れるのはセキュリティの面で問題がある。SSHは、この ような問題を解決し、今日的なセキュリティ環境を提供する。 SSHは"r"コマンドの代替に留まらず、X11 ウインドウプロトコルを暗号化しフォ ワードする機能(Secure X11 Forwarding)を持つ。またTCPでの通信を暗号化し フォワードする機能(Secure Port Forwarding)を持つので、X11ウインドウだ けに留まらず、いわゆるVPN (Virtual Private Network)と呼ばれるような一 般的な通信保護を行う環境も提供する。 sshサーバはあまり数多くはないが、sshクライアントのWindowsベース、 Macintoshベース、あるいはJavaベースといった色々なsshのクライアントがあ る。下記に参考となるURLを載せておく。 フリーのsshを集めたサイト http://www.freessh.org/ Linuxベースの暗号ツールを集めたサイト(*1) http://munitions2.xs4all.nl/dolphin.cgi?action=render&category=0206 --- コラム SSH1.2.26(1998年)の頃、筆者が満足できる高性能でかつ安全性の高い秘密鍵 暗号がSSHには実装されていなかった。そこで筆者はssh1.2.26にMISTY1を組み、 そのパッチを公開した。実測してみるとsshに入っている他の暗号よりも MISTY1の方が高速だった。その後のSSH2では高速で安全性の高いTwofishなど が入ったため、今となっては過去の話だが、その名残が(*1)のURLで見ること ができる。 --- ** 仕様と実装 SSH実装としては次の3つが広く知られている。 ・SSHバージョン1 および バージョン2 http://www.ssh.org/ ・LSH http://www.net.lut.ac.uk/psst/ ・OpenSSH http://www.openssh.com/ 現在、 SECSH(SECure SHell)という仕様としてRFC文章化する作業が進行して いる。 IETFのSECSHE ワーキンググループ + http://www.ietf.org/html.charters/secsh-charter.html 以下に簡単に各々の特徴を説明する。 + SSH1 --- SSH1は最初に作られたSSHで非商用目的のみ無料で利用できる。 実装および、仕様も古い。現在、SSH1はバグの修正のみ対応し、新しい機能追 加などは一切していない。新しい開発はSSH2に移行している。互換性の関係で SSH1ユーザのために残しているといっていいだろう。オリジナルはTatu Ylonen氏が個人的に作成したソフトウェアだが、後にSSH Communications Securityという会社を設立し、現在ではSSH Communications Securityがメン テナンスをしている。 + SSH2 --- SSH Communications Securityが作成し非商用目的のみ無料で利 用できる。SSH1をほとんど書き換えたバージョンである。SSH1とSSH2の互換性 は非常に乏しいのでプログラム的、仕様的にはSSH1とはまったく別物と考えた 方が良い。 SSH 1と SSH2の暗号化/認証アルゴリズムの違い 暗号化アルゴリズム SSH1 SSH2 DES YES NO Triple-DES YES YES IDEA YES NO Blowfish YES YES Twofish NO YES Arcfour[*1] NO YES CAST128 NO YES 認証アルゴリズム RSA YES NO DSA NO YES [*1] RSA社のRC4のことである。 + lsh --- Niels M\:oller ( \:o -- ウムラウト つきの oです )が作成した GNU版SSHである。現在バージョンlsh-1.1.0である。SSH1とSSH2に互換性があ る。かなり安定した動作もしていて、かつ、現在も改良が進行中であるが、定 まった評価を得るというにはまだ若い。導入するには、そのことを頭の隅にお いておく必要があるだろう。lshはSERPENTという非常に強力な暗号アルゴリズ ムを採り入れるなど、独自性がある。筆者としては好みのタイプである。 + openssh --- 統合化暗号技術環境(integrated cryptography)と呼ぶ OpenBSDの提供するトータルなセキュリティ環境を提供するための一環として 作られているSSHである。SSH1とSSH2のに対し互換性がある。現在はOpenSSH 2.3.0が最新である。アップデートも早い。コードの質、信頼、また実績も十 分であると言える。 * どのような攻撃を防げるか SSHが提供する認証と通信経路の暗号化は以下のような攻撃からの有効な防御 となる。 ・ネットワーク盗聴 ・データ改竄 ・IP偽装 (IP Spoofing) ・TCPハイジャック ・DNS 偽装(誤ったIPアドレスの取得) ・X11 プロトコルの認証とプロトコル偽装 SSHにより通信路が暗号化されるのでネットワーク盗聴やデータ改竄を防ぐと いうことは説明するまでもなく理解できると思う。TCPハイジャックに関して だが、たとえTCP接続自体はハイジャック出来ても、セッション(通信自体)は 成立できず安全である。たとえば通信中のセッションに対し乗っ取りをしよう とした場合、セッション中の暗号データをリアルタイムで解読することが出来 ない限り(これは現在の技術ではあり得ない)、セッションの乗っ取りは不可能 である。またsshは接続の認証に電子署名技術を使うので既知のサーバへのな りすましに対しても安全である。 * どのような攻撃が防げないのか ホームディレクトリへ攻撃者がアクセスできてしまう場合はSSHは防御できな い。通常はログイン先の~/.ssh以下に認証のための公開鍵設定などが用意され る。しかし、この情報を盗む、あるいは書き換えるようなことができてしまえ ば認証など無意味になる。そのログイン先のホストが完全に防御されている場 合であっても環境によっては落し穴がある。たとえばホームディレクトリが他 のNFSサーバからマウントされているホストであるとすると、もしNFSサーバが 攻撃者に乗っ取られてしまった場合、ホームディレクトリをマウントする側の ホストは防御できない。 * SSHのインストール ここではOpenBSDのopensshを取り上げ、インストールする手順を説明する。 まず注意したいのはopensshそのままのソースコードアーカイブはOpenBSD上で しかコンパイルできない。オリジナルのopensshのコードはOpenBSDの全体のセ キュリティ環境の1部として用意されているため、OpenBSDのコンパイル環境 であることが前提となる。 必要なのはPortable Opensshと呼ばれる数々のプラットフォーム上でコンパイ ルできるソースコードアーカイブである。これを利用する必要がある。このポー タブル版は暗号化ライブラリとしてOpensslのライブラリを利用するため、 Opensslを事前に入手し、コンパイル/インストールする必要がある。またPAM やZlibといった周辺ライブラリも必要である。PAM、Zlibなどは関しては各種 BSDやLinuxで標準的に用意されているので、ここでの説明は省略する。 Step 1: Opensslのソースコードアーカイブopenssl-0.9.6.tar.gzをコピーし インストールする。デフォルトは/usr/local/ssl以下にインストールされる。 入手方法はhttp://www.openssl.org/source/を参照のこと --- 実行例 % tar zxf openssl-0.9.6.tar.gz % cd openssl-0.9.6 % ./config % make (注 *1) % su # make install .... --- (注 *1)このopenssl-0.9.6に入っているPerlスクリプトは perlのパスが/usr/local/bin/perlだという前提で作成されているの でインストール時には注意が必要である。筆者は/usr/bin/perlを /usr/local/bin/perlにシンボリックリンクをして、この問題を回避 した。 Step 2: ポータブル版であるopenssh-2.3.0p1.tar.gzをコピーしコンパイルと インストールを行う。インストール時に自動的にホストの認証用公開鍵が作成 されインストールされる。 入手方法はhttp://www.openssh.com/portable.htmlを参照のこと ----- 実行例 % ./configure (注 *2) .... OpenSSH configured has been configured with the following options. User binaries: /usr/local/bin User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/manX PID file: /var/run Random number collection: Device (/dev/urandom) Manpage format: man PAM support: yes KerberosIV support: no AFS support: no S/KEY support: no TCP Wrappers support: no MD5 password support: no IP address in $DISPLAY hack: no Use IPv4 by default hack: no Translate v4 in v6 hack: yes Host: i586-pc-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -I. -I. -I/usr/local/ssl/include Linker flags: -L/usr/local/ssl/lib -L/usr/local/ssl Libraries: -ldl -lnsl -lz -lutil -lpam -lcrypto % make ... % su # make install .... Generating RSA keys: Key generation complete. Your identification has been saved in /usr/local/etc/ssh_host_key. Your public key has been saved in /usr/local/etc/ssh_host_key.pub. The key fingerprint is: 2c:4a:b0:90:5c:0f:d9:5c:15:47:9b:bc:fc:58:f0:59 root@msi.h2np.net Generating DSA parameter and key. Your identification has been saved in /usr/local/etc/ssh_host_dsa_key. Your public key has been saved in /usr/local/etc/ssh_host_dsa_key.pub. The key fingerprint is: e3:5f:fc:3e:a4:27:a9:d9:7a:bf:dd:12:64:81:a1:0e root@msi.h2np.net -------- (注 *2)もしopensslがインストールされていない場合、./config実行 時に次のようなメッセージが出力される。 --- checking whether pam_strerror takes only one argument... no checking for OpenSSL directory... configure: error: Could not find working SSLeay / OpenSSL libraries, please install --- * インストール、その他の注意点 システムがPAM (Pluggable Authentication Modules)、TCPWRAPPER、あるいは KerberosIV などの認証メカニズムを持っており、それがopensshに組み込まれ ている場合、別途各々の設定を行う必要がある。これらの環境はサイト毎、ホ スト毎に違うと思われるのでopensshのインストールにあたり適切な判断の元 に設定が必要である。 どのような環境でコンパイルされるかの確認が必要であるがopensshのインス トール時、./configure実行の最後に、どのような機構が組み込まれるかの一 覧が出るので、それを参照すると良い(上の画面出力例参照)。 今回の例ではPAM (Pluggable Authentication Modules)が組み込まれている。 そこではPAMのための設定ファイルを別途用意しなければ、PAMによるユーザパ スワードの認証が出来ない。そこでPAM設定を作成する。PAMのsshd用設定ファ イルの雛型はcontrib/の下に用意されているので、それを参考にすると良いだ ろう。ほとんどの場合デフォルトのまま使えるはずである。 ---- 実行例 PAMのためのsshd設定ファイル # cat /etc/pam.d/sshd #%PAM-1.0 auth required /lib/security/pam_pwdb.so shadow nodelay auth required /lib/security/pam_nologin.so account required /lib/security/pam_pwdb.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_pwdb.so shadow nullok use_authtok session required /lib/security/pam_pwdb.so session required /lib/security/pam_limits.so ---- * sshを試してみる sshdに関しては、既に認証に用いられるホストの公開鍵・秘匿鍵のペアが作ら れているので、あとはsshdを実行するだけで良い。 --- 実行例 # /usr/local/sbin/sshd --- まず自分自身のマシンにログインできるかどうか試してみる。ここで使ってい るホスト名はmsi@h2np.netである。 まず最初に"The authenticity of host 'msi@h2np.net' can't be established."と出るが、のホストmsi@h2np.netに対して接続したのは始めて だという意味である。 次にホストのRSAの公開鍵の“指紋"(fingerprint)が表示される。ここでの “指紋"とはRSA公開鍵と各種固有情報に対しハッシュ値を取ったものである。 事前にホストの“指紋"の値を知っておくことによって、なりすましを防ぐこ とができる。 ここで得たホストの情報と公開鍵は$HOME/.ssh/known_hostsに格納され、以降、 接続の度にホストが正しいかどうかこの公開鍵を使って認証を行う。次にパス ワード入力を求められるが、これはホストにログインする時のパスワード(パ スフレーズ)である。 --- 実行例 % /usr/local/bin/ssh msi@h2np.net The authenticity of host 'msi' can't be established. RSA key fingerprint is 2c:4a:b0:90:5c:0f:d9:5c:15:47:9b:bc:fc:58:f0:59. Are you sure you want to continue connecting (yes/no)? yes <-- yesと入力 Warning: Permanently added 'msi@h2np.net,192.168.1.60' (RSA) to the list of known hosts. hironobu@msi's password: <--- パスワードを入力 Last login: Tue Nov 14 07:10:11 2000 from localhost --- * 電子署名(公開鍵)認証を使ってログイン 先に行ったsshを使ったリモートログインはパスワード方式であった。このパ スワードは相手のリモートホストがシステムで所有しているパスワードである。 コンソールからログインする際にパスワードを使うのと同じパラダイムである。 しかし、もともとUNIXのパスワードは短いため少々問題がある。もしパスワー ドファイル(暗号化されているパスワード)がコピーされた場合、時間さえかけ れば総当たり方式でパスワードを見つけ出すのも可能である。しかしそれであっ ても、それなりの乱雑さを持つパスワードならば数年の時間を稼げるように思 われる。 しかし、本当にそうなのだろうか少し考えてみよう。毎秒100万回におよぶパ スワードの試行が可能な計算パワーを用意したと仮定して、UNIXが通常利用す るパスワードの文字数(データ長)を考えてみよう。この時、パスワードを見つ ける計算量を見積ると11年強となる。 しかし、すべての場合は11年かかるとは限らない。そこに「平均」という数字 のトリックがある。パスワードに使う文字は無作為という前提をおくと平均な らば数年レベルであっても、1000分の1程度の確率で1週間程度で破られる可能 性がある。この確率は暗号学的には無視できない十分に大きい確率である。 この問題を解決するのが電子署名の技術を用いた認証方法である。ログイン先 ホストに公開鍵を登録しておき、リモートからのログインは秘匿鍵で電子署名 したデータを送る。ホスト側ではその電子署名が正しいものであれば正規のユー ザだと判断する。このように電子署名技術の安全性のレベルでログインユーザ を認証できる。1024ビット長の鍵長を使うならば解読するのに現在の最高の技 術レベルであっても数万年かかる。つまり電子署名技術を使えば、十分に安全 であるとみなせるということである。 これを利用するには、公開鍵を事前にログイン先ホストに登録しておく必要が ある。手順は次の通り。 Step 1: 自分の鍵ペア(検証に使う公開鍵と、署名を作る秘匿鍵)を生成する。 Step 2: 自分の公開鍵である~/.ssh/identity.pubの内容をホストの上の ~/.ssh/authorized_keysの内容へ追加する --- 実行例 % ssh-keygen Generating RSA keys: Key generation complete. Enter file in which to save the key (/home/hironobu/.ssh/identity): Enter passphrase (empty for no passphrase): <---ローカルなパスワード Enter same passphrase again: <---ローカルなパスワード Your identification has been saved in /home/hironobu/.ssh/identity. Your public key has been saved in /home/hironobu/.ssh/identity.pub. The key fingerprint is: 86:41:f6:13:b8:ba:1d:9b:2b:36:c3:21:11:45:35:00 hironobu@msi.h2np.net --- デフォルトでは768ビット長のRSAの鍵ペアを作成する。-dを指定するとDSAの 鍵ペアが生成される。現在も768ビット長で問題はないが、もし1024ビット長 にしたければ "-b 1024" と指定できる。ここで「ローカルなパスワード(パス フレーズ)」と呼んでいるのは、電子署名を作成する秘匿鍵を保護するための パスワードである。手元にある暗号化され保護された秘匿鍵をパスワードで復 号化し、その秘密鍵を使って電子署名を行い、相手ホストに送る。 さて、その電子署名をチェックするためには秘匿鍵とペアになっている公開鍵 が必要である。そこで、自分自身のホスト上にある公開鍵である ~/.ssh/identity.pub の内容をログイン先サイトであるpc.h2np.netの ~/.ssh/authorized_keys へ追加する。この認証のことを「ホストベース認証方式」と呼ぶ。 この他にもX.509認証方式やPGP方式といった本格的な公開鍵暗号認証方式を用 いた運用が可能である。この方式に関しての説明は本章では省略する。 --- 実行例 % ssh pc.h2np.net 'cat >> ~/.ssh/authorized_keys' < ~/.ssh/identity.pub The authenticity of host 'pc.h2np.net' can't be established. RSA key fingerprint is a7:a9:d3:96:95:af:f7:15:47:20:24:ed:90:19:87:20. Are you sure you want to continue connecting (yes/no)? yes <-- yesを入力 Warning: Permanently added 'pc.h2np.net' (RSA) to the list of known hosts. hironobu@pc.h2np.net's password: <-- パスワードを入力 % ssh pc.h2np.net Enter passphrase for RSA key 'hironobu@msi.h2np.net': <---ローカルなパスワード Last login: Tue Nov 7 14:10:17 2000 from msi % --- * 他のバージョンや他のシステムからのアップデート 既にSSHが動いているネットワーク環境でアップデートする、あるいは新しい マシンに(別のバージョンの)sshをインストールするといった場合、なかなか 一筋縄ではいかないのが実情だ。 筆者が利用しているSSH環境はssh1→ssh2→OpenSSH→lshへと変遷を重ねてい るのだが、入れ換えるたびに右往左往している。 経験から言えば、既に動いている環境がある場合、その環境をオーバーライト しないようにバックアップしておいて、うまく動かない時、いつでも戻せるよ うにしておいた方が良い。 SSH1の認証はデフォルトがRSA方式で、SSH2のDSA方式は持っていないというバー ジョンの違いによる仕様の問題。相手ホストは SSH2のプロトコルを解釈する はずであるのに、設定でSSH1のプロトコルしか見ないといったトラブル。また その逆にクライアント側がデフォルトSSH1プロトコルを優先してしまってる状 況で、相手ホストがSSH2以外は受け付けない。ssh2とopensshのあいだで認証 はできるが、サーバ/クライアントのデータ交換で整合性が取れないとか、色々 な問題に遭遇する。なかなか思った通りには動いてくれない、というのが正直 な感想だ。 このあたりのトラブルはhttp://www.ssh.orgから辿れるSSH FAQがヒントにな る。山根信二さんがSSH FAQの日本語訳を以下のURLで公開してくれている。 http://www.vacia.is.tohoku.ac.jp/~s-yamane/FAQ/ssh/ssh-faq.html --- 実行例 "SSH Secure Shell 2.1.0.pl2"と"SSH Version OpenSSH_2.3.0p1, protocol versions 1.5/2.0"とがうまく動かない例 コネクション時が拒否される % ssh pgp.h2np.net Connection closed by 192.168.0.80 SSH2プロトコルを明示的に指定してみるが最後はエラーになる % ssh -2 pgp.h2np.net The authenticity of host 'pgp.h2np.net' can't be established. DSA key fingerprint is 73:b1:62:d4:fe:5c:9c:21:59:4f:e3:89:29:54:12:75. Are you sure you want to continue connecting (yes/no)? ... autodetect SSH_BUG_SIGBLOB Received packet with bad string length 812210565 --- システムに登録してあるホストの鍵を作った後に、ホスト名の変更、IPアドレ スの変更、あるいはホストの鍵の作り替えをした場合、クライアント側に既に あるknown_hosts中の公開鍵との不整合を起こす。基本的にはユーザの known_hostsから該当のホストのエントリを削除し、またあらたに最初のログ インと同じことをする必要がある。またホストの名前やアドレスが変わった場 合もホスト鍵(ssh_host_dsa_key/ssh_host_key)も不整合を起こす。新しい鍵 を生成し再インストールする必要がある。 --- 実行例 再度(pc.h2np.netの)鍵を作り直す # ssh-keygen -d -f /usr/local/etc/ssh_host_dsa_key -N "" Generating DSA parameter and key. /usr/local/etc/ssh_host_dsa_key already exists. Overwrite (y/n)? y <-- yを入力 Your identification has been saved in /usr/local/etc/ssh_host_dsa_key. Your public key has been saved in /usr/local/etc/ssh_host_dsa_key.pub. The key fingerprint is: b7:6c:1d:68:4c:6c:f8:a3:ff:af:f2:da:2c:a6:67:a0 root@pc.h2np.net --- --- 実行例 不整合が発生した場合 (pcのホスト鍵を事前に更新した) % ./ssh pc@h2np.net @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. Please contact your system administrator. Add correct host key in /Users/hironobu/.ssh/known_hosts to get rid of this message. RSA host key for pc has changed and you have requested strict checking. --- * X11 フォワーディング X11 フォワーディングとは、opensshを使いX11のパケットをトンネルさせ安全 にリモートのマシン同士でX11を使う機能である。遠隔マシンで実行されるXア プリケーションはopensshでトンネルされているので、Xサーバはローカルマシ ンからの接続に見える。また自動的にリモートマシンではX authorityのデー タ設定がなされている。 一度リモートホストへsshでログインしてしまえば、通常のリモートログイン からXアプリケーションを使う感覚で利用できる。ユーザ側は特にsshだという 意識をする必要はなくスムーズに使えるはずである。 sshdのこの機能はデフォルトではOFFになっているので /usr/local/etc/sshd_configのX11Forwardingを"no"から"yes"に変更する必要 がある。 --- 実行例 msiホスト上のmuleを立ち上げる (msi@h2np.netにはX11環境が載っている必要あり) % ssh -f msi@h2np.net mule --- * ポートフォワーディング 先のX11フォワーディングもポートフォワーディングも原理は同じである。TCP のセッションをSSHでトンネルしてしまう。ファイアウォールで外部とのアク セスコントロールを行なっているような場合、proxyの役目を果たすホスト上 でsshdを動かしておく。外部からsshで接続し、ポートのフォワードすると、 ちょうどproxyの役目を果たすホストから接続をするような形でポートが接続 される。通信は認証/暗号化されるため一種のVPNとして利用できる。 たとえば下の例はクライアントのポート3456をsshdが動いているmsiを経由し てh2np.netのport 80 (http)へパケットを中継したい時、-Lオプションを使っ て次のようにポートフォワードを行う。またこの反対の流れリモートのポート へ向かう-Rオプションもある。 --- 実行例 サーバmsi@h2np.netを経由してローカルポート3456をh2np.netのポート80へフォ ワードする場合 -L ローカルなポート番号:目的のサイト名:目的のポート番号 % ssh msi@h2np.net -L 3456:h2np.net:80 (通常のログイン) 別のシェルで % xterm -e lyxn http://localhost:3456 (xtermが開いてh2np.netが表示される) --- 筆者は出張にはWindows 2000が動いているノートパソコンを持っていくのだが、 これにはTTSSHというTera termをSSH拡張したクライアントを入れている。 TTSSHは非常に優秀で、バージョン1.5のプロトコルをサポートしていて、きち んとポートフォワーディングもできる。 ローカルのポート25(smtp)、110(pop3)、220(imap3)をメールサーバの同じポー トにフォワードするように設定しておき、sshで外部ネットワークからアクセ スできるファイアウォール上のsshdサーバにログインする。あとはメールクラ イアントのPOPサーバ、SMTPサーバをローカルに設定しておけば、ローカルマ シンがメールサーバに化ける。安全な上に簡単なので非常に重宝している。 * エージェントを使う あらかじめ電子署名に使う秘匿鍵を取り出し、あとはその準備された秘匿鍵を 使って認証を行う方法だ。面倒なユーザのパスワード入力という利点がある。 まずSSHのエージェントを立ち上げ、一度だけパスワードを入力する。以降は エージェントが自動的に認証を行うための処理をする。電子署名を使うので、 相手ホスト authorized_keys ファイルに公開鍵が準備されている必要がある。 --- 実行例 % ssh-agent bash <--- エージェント環境に入る。bashは利用するシェル % ssh-add Need passphrase for /Users/hironobu/.ssh/identity Enter passphrase for hironobu@pc.h2np.net: <--パスワード Identity added: /Users/hironobu/.ssh/identity (hironobu@pc.h2np.net) % ssh msi.h2np.net (注) --- (注) もちろんログインするmsi.h2np.netではIPアドレスからpc.h2np.netの名 前をリソルブ(逆引き)できることが条件である。 * 参考資料 SSH全般の構造に関しての説明 + 7.4章 SSH/Bit別冊情報セキュリティ(山口、鈴木編)/P197〜203/ 共立出版/2000年1月 RedHat LinuxでSSHをインストールし利用する方法 + リモートシェルSSHの使い方/実践Linuxセキュリティ(すずきひろのぶ)/ P133 -- P141 /インプレス/2000年9月 おしまい