[目次へ][6章へ][6.1へ][6.3へ] 最終更新：$Date: 2002/09/09 06:19:36 $
version 1.11.2から追加された遠隔用の特殊なコマンド(version)は付録に任せる。
※パスワード入れ替え。
■■6.2 遠隔から使えるようにしよう
■■■ 6.2.1 CVSを遠隔から使うための基本
■■■ 6.2.2 遠隔リポジトリへの接続方法
■■■ 6.2.3 SSHの初期設定をごく簡単に
■■■ 6.2.4 extとSSHで接続してみよう
■■■ 6.2.5 pserverで接続してみよう
■■■ 6.2.6 SSHのポート転送でpserver接続してみよう
■■■ 6.2.7 WinCvsで接続しよう
■■6.2 遠隔から使えるようにしよう
筆者は、CVSの真骨頂はこの「遠隔から使えること」だと思っています。どこかにリポジトリを用意しておくことで、どこのどんなマシンを使用していても最新の作業状態を手に入れることができます。ただし、マシンを離れるときには必ずコミットしておくことが条件ではありますが(何度かコミットを忘れて結局作業を滞らせてしまった覚えのある人…はい)。
ということで、さっそくCVSを遠隔から使えるようにしていきましょう。
■■■6.2.1 CVSを遠隔から使うための基本
CVSコマンドを使って遠隔のリポジトリにアクセスするには、単にCVSROOT環境変数もしくは-dオプションで、リポジトリを「接続に必要な情報を含んだ形で」指定するだけです。その指定形式は、【図6.2.1】もしくは【図6.2.2】のようになります。【図6.2.2】の方は、1.11.1から導入されたpserver接続のみについて拡張された指定形式です。パスワードとポート番号を明記できるようになりました。
【図6.2.1】遠隔リポジトリの指定形式(一般) ▼ :接続方法:ユーザ名@サーバ名:サーバ上でのリポジトリパス ▲
【図6.2.2】遠隔リポジトリの指定形式(1.11.1以降のpserver接続のみ) ▼ :pserver:[[ユーザ名][:パスワード]@]サーバ名[:[ポート番号]]/サーバ上でのリポジトリパス ▲
たとえば、mikaというユーザが、extという接続方法で、cvs.mydomain.comというサーバ上の、/home/cvsrootというリポジトリから、cvstestというモジュールをcheckoutする場合は、一般的には次のように指定することになります。
【図6.2.3】遠隔リポジトリの記述例(一般)
▼ cvs -d :ext:mika@cvs.mydomain.com:/home/cvsroot checkout cvstest ▲
一方、新しく導入された形式では、例えばパスワード(mypassとしてみましょう)とポート番号(2402としてみましょう)を記述して、【図6.2.4】のように書くことができます。
【図6.2.4】遠隔リポジトリの記述例(pserver)
▼ cvs -d :pserver:mika:mypass@cvs.mydomain.com:2402/home/cvsroot checkout cvstest ▲
ただし、パスワードについては、CVS/Rootなどにこのまま保存されてしまうので、よっぽど公開性の高いパスワード以外は書くべきではないとされています。匿名(anonymous)CVSサーバでは、パスワードなしが一般的です。
■■■6.2.2 遠隔リポジトリへの接続方法
接続方法には、ext、server、pserver、gserver、kserver、forkの6つの種類があります。また、これとは別に、明示的にローカルであることを示すために、localという接続方法も指定できます。nserverという方法もありますが、これはcvsntというWindowsサーバに特化したシステムのもので、CVSの本流にはまだ取り込まれていません。WinCvs1.3はcvsntをベースにしていますので、将来的にはWindowsユーザはこちらをメインに使うことになるかも知れませんが、今回はWinCvs1.2をメインに話しています。このため、nserverについては本書では基本的に扱いません。
接続方法は、ユーザの環境や用途によって使い分ける必要があります。どんなサーバにもいえることですが、使い勝手とセキュリティのトレードオフを考慮する必要があります。つまり、設定が簡単な方法は一般にセキュリティが低く、セキュリティの高い方法は初期設定や使い方が難しいのです。
server、gserver、kserver、forkは、あまり一般的でないため、簡単な説明にとどめます。
serverという接続方法は、CVS内部に実装されたrshを利用して接続する方法で、CVSの種類によっては、使えないでしょう（筆者はこれが使える実装に出会ったことがありません）。
gserverとkserverはKerberosという認証システムを使用しており、使用にあたっては、サーバ、クライアントともにKerberosが組み込まれている必要があります。Kerberosは米国の暗号方式の輸出問題に絡んで日本ではあまり普及していません。gserverはKerberos 5、kserverはKerberos 4いうKerberosのバージョンにそれぞれ対応しています。
forkは実行すると、クライアントとサーバの2つのプロセスに分かれて通信をおこない、データをやり取りします。これは、デバッグのための機能ですので、プログラマ以外の利用者は気にする必要はありません。
localは、特にWindowsでディスクの区切りと区別するために良く使いますね。localを用いる場合には、ユーザ名とサーバ名を指定する必要はありません。
通常、CVSをサーバにするには、extとpserverのどちらかの接続方法を選択するのが一般的です。本書ではこれらの接続方法を説明していきます。
extを指定すると、CVSは接続するために外部プログラムを呼び、そのプログラムを介して接続先のシステムに登録されたユーザで認証をおこないます。接続に利用する外部プログラムは環境変数CVS_RSHで設定します。CVS_RSHが設定されていない場合は、rshを呼びます。しかし、rshはパスワードもそのまま流れますし.rhostsや/etc/hosts.equivなどではかなり安易に相手ホストを信用するような設定をおこなうため、よほど信頼のおけるイントラネットでないと、実際に使用することはできません。一般に、通信が暗号化されていないログイン方法だと、パスワードもデータもそのまま流れてとても危険です。インターネットでの利用はもちろん、イントラネットでもなるべく避けた方がよいでしょう（とはいえ、素でユーザ名とパスワードが流れる同様のプロトコルFTPが使われつづけているので、ここだけ強化してもしょうがない気もする今日この頃）。
筆者のお勧めは、外部プログラムとしてsshを利用する方法です。sshを使えば、ユーザ認証もデータ転送も暗号化されます。sshの設定、利用方法は必要な分だけ簡単に説明しますが、より詳しい情報については関連書籍をあたってみてください。Googleなどのサーチエンジンで検索してもらっても関連する情報を入手することは難しくないでしょう。
pserverはpassword serverの意味です。システムのパスワード・ファイルとは別のパスワード・ファイルを作成することができ、そのファイルに書かれたユーザ名とパスワードに基づき認証をおこないます。この方法のよいところは、システムに普通にログインするためのユーザ名とパスワードとは別にpserver用のユーザ名とパスワードが設定できるので、外部からシステムのユーザ情報を隠せるということです。しかし、パスワードやデータは暗号化されませんので、機密性を要する用途には使えません。インターネット上でデータを公開するなどの用途には使えるでしょう。さらに通信路を暗号化したいという場合は、sshのポート転送機構を利用すると良いかもしれません。SSL認証を使ったstunnelなどを利用するとよいと思いますが、筆者は実際に運用したことはありません。
以上をかんがみてextとpserverの接続方法を分類すると、【表6.2.1】のようになります。
【表6.2.1】接続方法の分類
| サーバタイプ | 外部プログラム | 認証 | データの暗号化 | 必要設定 | 用途 |
| ext（server） | rsh（なし） | rhosts認証 | なし | rhostsの設定 | イントラネットでの共有 |
| ext | ssh | sshの認証 | sshにより暗号化 | 環境変数CVS_RSHにsshを設定 | インターネットでの共有 |
| pserver | なし | 独自passwdファイル | なし | pserverの設定 | インターネットでの公開 |
| pserver | ssh | sshの認証+独自passwd | sshにより暗号化 | pserverの設定+sshのトンネル設定 | インターネットでの共有 |
以下では、extとpserverでの接続方法をSSHを絡めながら説明していきます。
■■■6.2.3 SSHの初期設定をごく簡単に
ひとまず、SSHの初期設定の話を先にしてしまいましょう。extで使うにしても、pserverで使うにしても初期設定は必要です。
SSHには現在オリジナルのSSHと、これから派生したOpenSSHという大きく2つの潮流がありますが、本書ではライセンス的に自由度の高いOpenSSHを対象に説明していきます。OpenSSHはRed Hat Linuxでは7以降には標準で入っています。BSD系のFree UNIXでは標準的に入っていると思います（そもそもOpenBSDが発祥の地ですし）。RedHat Linux 6.x以前では、別途インストールが必要です。他の商用UNIXではたぶんインストールが必要でしょう。SSHとOpenSSHは微妙にプロトコルや鍵の書式が違ったりして、相互運用するにはコツが要ります。が、インストールやSSHとの相互運用は本書では範囲を越えてますので述べません。関連書籍などをあたってください。
SSHのURL(日本語)
http://www.ipsec.co.jp/
OpenSSHのURL(日本語)
http://www.openssh.org/ja/index.html
ここでは、リポジトリの置いてある計算機にはOpenSSHがインストールされているものとして話を進めます。はじめにサーバの簡単な設定の話をして、それからクライアントの設定をしてつないでみる、というところまでを目指します。本書では、「OpenSSHセキュリティ管理ガイド」(新山祐介/春山征吾著、秀和システム、ISBN:4-7980-0129-5)を参考にしています。ですので、もっと本質的なことが知りたいという向きはぜひこちらをご覧ください(とか宣伝してみる)。
▼「OpenSSHセキュリティ管理ガイド」サポートページ
[http://www.unixuser.org/~haruyama/security/openssh/support/]
■■■■サーバの設定
もし、すでにサーバが運用されていて、設定を変える気がないか、設定を変える権限を持たない場合にはこの項は飛ばして次に行ってください。サーバをこれから設定する人だけここを参考にされてください。よって、基本的にこの項の作業はroot権限で行うものとします。
サーバを設定するにはまず、運用ポリシーを決めます。ここでは、利用目的を考えて、【表6.2.2】のように決めました。本格運用する場合には、それぞれの環境をさらに考慮して運用ポリシーを決める必要があるでしょう。まぁ、ここではこれでやっていきます。
【表6.2.2】 運用ポリシーの決定| 項目 | 決定 | 理由 |
| どのSSHプロトコルを使用するか | SSH1とSSH2の両方 | SSH2のみが望ましいが、SSH1しか利用できないクライアント(TTSSH)の利用があるため |
| ログインを許可するユーザ | システムの一般ユーザ(Rootは不許可にする) | CVSを利用するユーザのみでよいから |
| ユーザが利用できる認証方法 | 公開鍵暗号 | 一般的に推奨されているから |
| ユーザが利用できるコマンド | 最低限CVSのコマンドとポート転送 | ext+sshとpserver+portforwardingの説明のため |
| 接続を許可するホストやクライアント数 | 標準設定で | テストとは関係ないので |
| ログの出力設定 | 標準設定で | 同上 |
| 暗号方式とポート | 標準設定で(ポートは22) | 同上 |
他のこまごまとした設定は標準設定でいくことにします。この運用ポリシーから、OpenSSHのサーバの設定ファイルsshd_configの内容は【図6.2.5】のようになると思います。設定ファイルsshd_configは、OSによって、/etcの下にあったり、/usr/local/etcの下にあったりします。本書では。Red Hat Linux 7.xを仮定して、/etc/ssh/sshd_configにあるとします。【図6.2.5】は全ての項目を設定しているわけではありません。他の項は標準設定のままだと考えてください。
【図6.2.5】/etc/ssh/sshd_configに設定する ▼ # ポートは22を使用する（標準設定） Port 22 Protocol 2,1 # ネットワークの制限は特にかけない #ListenAddress 0.0.0.0 #ListenAddress :: # ホスト鍵のファイルの場所 （LHL7.xの標準設定） # SSH1用のホスト鍵 HostKey /etc/ssh/ssh_host_key # SSH2用のホスト鍵 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # ServerKeyBits 768 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin no # SSH1用のRSA公開鍵による認証を許可する RSAAuthentication yes # SSH2用のDSA公開鍵による認証を許可する PubkeyAuthentication yes # 公開鍵の置き場を指定する AuthorizedKeysFile .ssh/authorized_keys # 他の認証方法は禁止する HostbasedAuthentication no RhostsRSAAuthentication no RhostsAuthentication no PasswordAuthentication no ChallengeResponseAuthentication no # ポート転送機能を許可する （標準設定） AllowTcpForwarding yes ▲
設定が終わったら、サーバを起動しましょう。本運用の前にサーバをデバッグモードで動かしてみるべきかもしれませんが、ここでははしょります（デバッグモードオプションは-dです）。一般のSSHサーバ起動は【図6.2.6】のようになります。
【図6.2.6】サーバを起動してみよう（一般） ▼ % /usr/local/sbin/sshd ▲
Red Hat Linux 7.xの場合にはサーバは/sbin/sshdにあり、起動スクリプトも/etc/init.d/sshdに用意してありますが、お作法としては/sbin/serviceを使用します。やってみましょう。よいしょ【図6.2.6】。
【図6.2.6】RHL 7.xでサーバを起動してみよう ▼ /sbin/service sshd start ▲
ここで、クライアントからの接続を受け付けられるモードになっているはずです。とりあえず動いているかどうかだけはtelnetコマンドで確かめられますので、ちょっと叩いてみましょう【図6.2.7】。
【図6.2.7】とんとんとん、動いてますか？ ▼ % telnet localhost 22 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. SSH-1.99-OpenSSH_3.1p1 Protocol mismatch. Connection closed by foreign host. ▲
「SSH-1.99-OpenSSH_3.1p1」のようにOpenSSHから返事が返ってきて、待ち受け状態になったら成功です。リターンを押すと「Protocol mismatch.（プロトコルが合っていません。）」と言われて切られます。なお、sshdが起動時に立ち上がるように設定するには、一般のUNIXでは/etc/rc.localあたりで設定します。SolarisやRed Hatだと/etc/rc3,dあたりに起動スクリプトを設置します。Red Hat Linux7.xはこの起動スクリプトが基本になっているのですが、それをさらにxinetdと合わせてサービスとして統括するコマンドが用意されています。/sbin/chkconfigがそれです。
/sbin/chkconfigを使用して、サービスを活性化すると、単体で動かすものは起動スクリプトがあるべき状態に設置され、xinetdで動かすものはxinetd.dの下の設定ファイルが書き換えられます。sshdは単体で動かすサービスなので（OSの標準設定としてで、実際はxinetdで動かすことも可能です）、起動スクリプトの設置状態が変わります。つまり、/sbin/chkconfig sshd onとして活性化すると、【図6.2.8】のように、rc2.d、rc3.d、rc4.d、rc5.dではS55sshdとして/etc/init.d/sshdにリンクが張られ、他のrc0.d、rc1.d、rc6.dではK25sshdとしてリンクが張られます。この各ディレクトリはinit levelといって計算機の起動レベルに対応しています。といっても難しいですね…まぁ通常はrc3.dの中の対応するファイルがSで始まれば起動し、Kで始まれば起動しない、とでも覚えておいてください。
【図6.2.8】sshdを活性化すると… ▼ % /sbin/chkconfig sshd on % ls -l /etc/rc?.d/*sshd lrwxrwxrwx 1 root root 14 Aug 11 07:55 /etc/rc0.d/K25sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 14 Aug 11 07:55 /etc/rc1.d/K25sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 14 Aug 11 07:55 /etc/rc2.d/S55sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 14 Aug 24 09:26 /etc/rc3.d/S55sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 14 Aug 24 09:26 /etc/rc4.d/S55sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 14 Aug 24 09:26 /etc/rc5.d/S55sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 14 Aug 11 07:55 /etc/rc6.d/K25sshd -> ../init.d/sshd ▲
一方、sshdを /sbin/chkconfig sshd offで不活性化すると、/etc/rc3.d/K25sshdと起動しない設定に変えられます【図6.2.9】。
【図6.2.9】sshdを不活性化すると… ▼ % /sbin/chkconfig sshd off % ls -l /etc/rc?.d/*sshd lrwxrwxrwx 1 root root 14 Aug 11 07:55 /etc/rc0.d/K25sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 14 Aug 11 07:55 /etc/rc1.d/K25sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 14 Aug 11 07:55 /etc/rc2.d/S55sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 14 Aug 24 09:22 /etc/rc3.d/K25sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 14 Aug 24 09:22 /etc/rc4.d/K25sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 14 Aug 24 09:22 /etc/rc5.d/K25sshd -> ../init.d/sshd lrwxrwxrwx 1 root root 14 Aug 11 07:55 /etc/rc6.d/K25sshd -> ../init.d/sshd ▲
ということで、次は、SSHのクライアントから接続できるように設定をしてみましょう。
■■■■クライアントの設定
上の設定とは異なる認証設定をした場合には、その設定にあわせてクライアントを設定してください。ここでは、上で公開鍵暗号による認証に限るようにサーバを設定しましたので、クライアント側(とサーバ側でも)で必要になる公開鍵に関する初期設定について説明します。ここからは、通常のユーザでの設定です。root権限は必要ありません。
SSH1でのRSA公開鍵暗号の設定については、丹野さんの「簡単SSH」に詳しい紹介がありますので参考にされるとよろしいでしょう。
▼簡単SSH URL [http://www.netlab.is.tsukuba.ac.jp/~one/ssh/]
ここでは、クライアントにUNIX系のOpenSSHがインストールされている環境での初期設定を説明します。Windowsについては6.2.7節のWinCvsのところで説明します。設定の流れは基本的に同じですので、SSH1とSSH2の両方を並列に見ていきましょう。
ここではまず、サーバ上で試験的に接続するための設定を考えます。sshdが動いているCVSリポジトリのある計算機をcvs.mydomain.comという名前だとしましょう。
■■■■■STEP1 クライアントのホームディレクトリで秘密鍵と公開鍵を作成する
大事なパスフレーズが素のままネットを流れるとまずいので、秘密鍵と公開鍵はローカルでログインして作成します。鍵の作成には、OpenSSHをインストールすると必ず入っているはずのssh-keygenコマンドを利用します。本書ではSSH1もSSH2も使用しますので、RSAとDSAの両方について生成方法を説明します。
■■■■■■@SSH1用のRSA鍵を生成する【図6.2.10】
ssh-keygenを-tオプションにrsa1を指定して実行すると、SSH1用のRSA鍵が生成されます。生成されるファイルは.ssh/identity(秘密鍵) と .ssh/identity.pub (公開鍵)です。ファイル名は-fオプションで変えることができますが、ここではそのままいきます。
生成時にはパスフレーズが必要です。ここで指定したパスフレーズは実際の接続の時に使用します。適当に決めて打ち込んでください。
【図6.2.10】SSH1用のRSA鍵を生成する ▼ % ssh-keygen -t rsa1 Generating public/private rsa1 key pair. Enter file in which to save the key (/home/mika/.ssh/identity): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/mika/.ssh/identity. Your public key has been saved in /home/mika/.ssh/identity.pub. The key fingerprint is: f8:b9:cb:2e:de:b4:c8:b3:c2:f4:06:73:02:c3:f4:c1 mika@cvs.mydomain.com ▲
■■■■■■ASSH2用のDSA鍵を生成する【図6.2.11】
ssh-keygenの-tオプションでrsaあるいはdsaと指定することにより、SSH2用のRSA鍵あるいはDSA鍵を生成することができます。生成されるファイルはRSA鍵の場合は .ssh/id_rsa (秘密鍵) と .ssh/id_rsa.pub (公開鍵)で、DSA鍵の場合は .ssh/id_dsa (秘密鍵) と .ssh/id_dsa.pub (公開鍵)です。ここではDSA鍵でやってみます。生成方法はSSH１の場合と同じで、やはりパスフレーズが必要です。
【図6.2.11】SSH2用のDSA鍵を生成する ▼ % ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/mika/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/mika/.ssh/id_dsa. Your public key has been saved in /home/mika/.ssh/id_dsa.pub. The key fingerprint is: 65:f6:22:4c:89:e9:cf:bb:75:f5:58:c6:9c:5c:b2:99 mika@cvs.mydomain.com ▲
■■■■■STEP2 サーバに公開鍵を転送し登録する
STEP1でクライアントで作成した公開鍵(.ssh/identity.pubや.ssh/id_dsa.pub)を、ftpでもなんでもいいのですが、接続先サーバのホームに転送します。秘密鍵(id_rsaやid_dsa)は転送してはいけません。転送した公開鍵は、公開鍵保存ファイル（OpenSSHでは一般に.ssh/authorized_keys）に登録します。
今はローカルで作業してますので、.ssh/identity..pubと.ssh/id_dsa.pubを.ssh/authorized_keysに登録します【図6.2.13】【図6.2.14】。ここでは追加モードのリダイレクション>>を使ってますが、間違えて>（上書きリダイレクション）にしちゃうとかなり不味いので、エディタ（viとか）を使う方のがお勧めです。
【図6.2.13】SSH1用のRSA公開鍵を登録する ▼ % cat identity.pub >> authorized_keys ▲
【図6.2.14】SSH2用のDSA公開鍵を登録する ▼ % cat id_dsa.pub >> authorized_keys ▲
■■■■■STEP3 接続してみる
これで接続の準備ができました。早速接続してみましょう。OpenSSHではSSH1とSSH2の指定は-1オプションと-2オプションで行います。何も指定しないと、SSH2で接続します。まず、-1を指定して、SSH1で接続してみます【図6.2.15】。
【図6.2.15】SSH1で接続してみる ▼ % ssh -1 localhost The authenticity of host 'localhost (127.0.0.1)' can't be established. RSA1 key fingerprint is c0:af:1f:31:24:f2:b2:ae:a8:ac:28:ed:20:ac:af:17. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (RSA1) to the list of known hosts. Enter passphrase for RSA key '/home/mika/.ssh/identity': Last login: Sat Aug 24 10:05:44 2002 from localhost.localdomain % ▲
最初の接続では、接続先のホスト鍵が.ssh/known_hostsにないので、それを登録するかと聞いてきます。ここでは、そのままyesとして受け入れてください【図6.2.15 4行目】。次に、.ssh/identityのパスフレーズの入力を聞いてきます【図6.2.15 6行目】。ですので、さっきこの鍵を作成するときに入力したパスフレーズを打ち込んでください。間違いがなければ、入れるはずです。
次に-2を指定してSSH2で接続してみましょう【図6.2.16】。オプションは指定しなくても、SSH2になりますが、ここでは明示的に。流れは全く同じです。初めてのSSH2での接続なので、ホスト鍵の登録をするかどうか聞かれ【図6.2.16 4行目】、それにyesと答えたあと、パスフレーズを聞かれています【図6.2.16 6行目】。
【図6.2.16】SSH2で接続してみる ▼ % ssh -2 localhost The authenticity of host 'localhost (127.0.0.1)' can't be established. RSA key fingerprint is 69:43:a2:e3:52:51:d5:63:7c:07:c3:cb:c2:98:23:6a. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (RSA) to the list of known hosts. Enter passphrase for key '/home/mika/.ssh/id_dsa': Last login: Sat Aug 24 10:18:17 2002 from localhost.localdomain % ▲
どうでしょう、問題なく接続できたでしょうか。接続できない場合は、known_hostsの状態とか、鍵のパスフレーズなどを良くチェックしてください。場合によっては、firewallの設定や、/etc/hosts.allowの設定で問題が生じているかもしれません。設定を確認するとともに、他の通信はできているか、他の計算機ではどうか、など調べてください。
■■■6.2.4 extとSSHで接続してみよう
上のようにsshの設定が完了したら、環境変数CVS_RSHにsshを設定し、パスフレーズを入力することで接続できるようになります。環境変数CVS_RSHは次のように設定します。
CSH系のシェルを利用している場合 setenv CVS_RSH ssh SH系のシェルを利用している場合 CVS_RSH=ssh; export CVS_RSH
環境変数の設定後、extを用いたリポジトリを指定するコマンドを実行してみると【図6.2.17】のようになります。
【図6.2.17】extを指定してコマンドを実行してみる ▼ % cvs -d :ext:mika@localhost:/home/cvsroot checkout cvstest Enter passphrase for key '/home/mika/.ssh/id_dsa': cvs server: Updating cvstest U cvstest/fish.jpg U cvstest/test.txt ▲
【図6.2.17 2行目】で、sshの接続のためのパスフレーズ入力が促されています。パスフレーズを正しく入力すると接続がおこなわれ、接続先でcvsのコマンドがサーバモードで実行されます。さらにその結果の出力がネットワークを介して送られ、それをクライアント側で処理することで、遠隔リポジトリでも同じように利用することができます。
じきにコマンド実行毎のパスフレーズの入力が面倒くさくなるかもしれません。これを簡略化するためには、ssh-agentを設定するとよいです。詳細は、「OpenSSHセキュリティ管理ガイド」などをご覧ください。
※いや書いてもいいんですが…余裕があれば…。「OpenSSHセキュリティ管理ガイド」 p.140-145あたりの話。
なお、接続先のcvsコマンドが一般的でない場所にセットアップされていると、まれに失敗することがあります。シェルの初期化ファイルでプログラムの検索パスを設定できればよいのですが、それでもうまくいかないことがあります（ええ、筆者はつい先日遭遇しましたとも）。こういう場合にクライアント側でできる解決策が1つあります。それは環境変数CVS_SERVERを設定することです。
たとえば、接続先のcvsが/home/hoge/binにあるとすると、CVS_SERVERを/home/hoge/bin/cvsに設定すればしのげます。
■■■6.2.5 pserverで接続してみよう
では、pserverの設定方法について具体的に説明していきましょう。pserverの設定は、「管理ファイルの設定」と「サーバとしての設定」という2つの手順からなります。
■■■■管理ファイルの設定って何?
CVSがpserverとして働くときは、ユーザ認証をおこないアクセスが許されたユーザかどうかチェックします。この認証を正しく設定しておかないと、意図しない人物からアクセスされ危険です。特に自分が何をしているのかよくわからない場合には、セキュリティ・レベルをきつめに設定しておきましょう。pserverの認証に関わる管理ファイルは、configとpasswdです。passwdファイルは、初期状態では存在しませんから、自分で作成して追加することになります。■■■■■@configファイルの設定
まず、管理ファイルconfigでの設定です。
設定項目は1つだけです。SystemAuthというパラメータを設定できるのですが、それをnoにしておきます【図6.2.4】。
【図6.2.18】configファイルの変更部分 ▼ SystemAuth=no ▲
このパラメータは、認証要求のあったユーザがpasswdファイルに登録されたユーザでなかった場合に、システムのユーザとして認証するかどうかを決定します。つまりmikaというユーザ認証の要求があり、かつ、このユーザがpasswdファイルに登録されていなかったときに、システムのユーザにmikaがいるか調べるかということです。
逆にSystemAuth=yesに設定すると、システムのユーザまで対象にします。SystemAuth=noにしておけば、passwdファイルのユーザのみを認証対象にします。なるべく、対象を絞っておくためにnoにしておきましょう。システムのユーザを対象とする危険性は、ネットワーク中をシステム・パスワードが流れてしまう点にあります。なお、passwdファイルでのユーザ名およびパスワードを、システムのものと同じにしてしまったら意味がありません。違うものを使うようにしましょう。
■■■■■Apasswdファイルの作成と登録
ユーザの制限が終わったら、アクセスできるユーザを設定しないと誰も使えません。ということで、passwdファイルにアクセスできるユーザを登録していきます。
この手法の最大の問題点は、ユーザのパスワードを暗号化してpasswdファイルに書かなければならないのに、暗号化の手段をCVSが提供していないということです。つまり、どこからかパスワードを暗号化するツールを取ってくるか、自分でごりごり作る必要があります。あるいは、passwdコマンドでユーザのパスワードを変更して、/etc/passwd（もしくは/etc/shadow）に生成されたパスワードをカット・アンド・ペーストしてくる手もあります。しかし、これはホストのroot権限がないと難しいかもしれません。筆者はWebサーバであるApache httpdについてくる、htpasswdを流用して使っています。
自力でごりごり作る場合は、perlのcrypt関数を利用するのが簡単だと思います。基本は、crypt("pass phrase", "xx")という形で、暗号化したい文字列を第1引数に、それにちょっと味付けをするための塩（salt）を第2引数に加えます。saltに渡せるのは、[a-zA-Z0-9./]のうち任意の2文字です。たとえば、【図6.2.19】のように、パスワードを^Hi-h0&=に、saltを.0にした場合【図6.2.19 1行目】、.0mE4ugRRj9r.という文字列が生成されます【2行目】。
saltを考えるのも面倒なら、それをランダムに生成するためのコードをつけてスクリプトとして用意しておきましょう。
【図6.2.19】暗号化された文字列を得る
▼
% perl -e 'print crypt("^Hi-h0&=", ".0"), "\n";'
.0mE4ugRRj9r.
▲
どんな方法でもよいですが、パスワードが暗号化できたら、passwdファイルを作成します。passwdファイルには1行に一人のユーザを設定します。1行の書式は次のようになります。
【図6.2.20】passwdファイルの1行の書式 ▼ CVSのユーザ名:パスワード:システムのユーザ名 ▲
ここで、第1項目のCVSのユーザ名と、第2項目のパスワードが、pserverにアクセスするためのユーザ名とパスワードを意味します。第3項目のユーザは、第1項目のユーザ名でアクセスした場合に、実際にどのシステム側ユーザとしてコマンドが実行されるかを設定する部分です。たとえば、bmikaとanonymousというユーザを設定してみると、【図6.2.21】のようになります。
【図6.2.21】完成したpasswdファイル ▼ bmika:.0mE4ugRRj9r.:mika anonymous:gB/FnBTDLRODw:anon ▲
bmikaとanonymousはシステム内では実際には、それぞれmikaとanonというユーザに該当することになります。
Column cvsntのpasswdコマンド
Windowsではパスワード生成が面倒です。ということで、CVSの亜流であるCVS for NT (cvsnt)では独自コマンドpasswdが導入されています。このコマンドを使用すると、$CVSROOT/CVSROOT/passwdのパスワードの更新ができます。前版の読者の方から情報を提供していただきました。多謝。
【図6.2.22】passwdコマンドの書式 cvs passwd [-a] [-x] [-X] [-r システムユーザ] [-R] [-D ドメイン] [ユーザ名] -a: ユーザを加える -x: ユーザを無効にする -X: ユーザを削除する -r: システムユーザの別名とする -R: システムユーザへの別名を削除する -D ドメイン: ドメインのパスワードを利用する
■■■■サーバの設定って何？
CVSは独立したサーバとしては動きません。つまり、「起動するとバックグラウンドに入り、待ち受け、通信などの全ての処理を自力でおこなうようなサーバではない」ということです。その代わりに、UNIXで通信の待ち受けを肩代わりしてくれるシステム、inetd（RedHat Linux 7ではxinetd）を利用します。telnetやftpもこのinetdを利用しています。inetd(xinetd)はそういったプログラムの代わりに、あらかじめ指定されたポートを見張り、通信の要求がくるのを待ち受けてくれます。そして、指定のポートに接続要求が来たら、接続を確立しポートに割り当てられたプログラムを呼び出してくれます。どのポートがどのプログラムに対応し、どのように呼び出せばよいかという設定は、inetdの場合には/etc/inetd.confというファイルに、xinetdの場合には/etc/xinetd.confに記述します。以下では、inetdとxinetdに分けて説明を行いますが、基本は同じです。
■■■■■@inetdでの設定方法 (RHL6.x以前、および一般的なUNIX)
cvsのpserverを設定するためには、inetd.confに【図6.2.23】のような行を追加します。図では行が折り返されていますが、改行しないように注意してください。改行してしまうと、引数が途中で切れてしまうため、正常動作しません。
【図6.2.23】/etc/inetd.confへの追加（tcpdを挟む場合） ▼ # CVS pserver cvspserver stream tcp nowait root /usr/sbin/tcpd /usr/bin/cvs -f --allow-root=/home/cvsroot pserver ▲
ここで、第1項目のcvspserverはポート番号です。次の第2、3、4項目のstream、tcp、nowaitというのは通信方法で、第5項目のrootがプログラムの実行ユーザを指定しています。第6項目が呼び出すプログラムのパスを指定する場所ですが、通信の制限をおこなうために、CVS本体へのパスを直接書くのではなく、一旦tcpdというプログラムを間に挟む設定にします。次の第6項目以降が実際に呼び出されるプログラムと、その引数（-f、--allow-root=/home/cvsrootとpserver）になります。
引数のうち、pserverというのがCVSをサーバとして動作させるためのコマンドです。全体にかかるオプション、--allow-rootオプションはアクセスできるリポジトリを制限しています。つまり、サーバを介した状態では/home/cvsrootというリポジトリにしかアクセスできないということです。このオプションは必ずpserverと一緒に使われます。
ちなみに複数のリポジトリにアクセスできるように、--allow-rootを複数設定しようとすると、inetd.confの一行に設定可能な文字数を越えてしまいます。そういうときは、シェルスクリプトでCVSコマンドをくるんで、そのシェルスクリプトを呼び出すなどの工夫が必要です。
また、-fオプションは環境変数を無効化するためのオプションです。-fがないとroot（実行ユーザ）の環境変数が有効になってしまうようです。ただし、初期設定ファイルを各ユーザ毎に見にいくようにするためには、これだけではうまくいかないことも多いようで、UNIXの環境変数を操作するenvコマンドを利用し、CVSを実行するときの環境変数（特に環境変数HOME）を無効化する必要があります。envはオプション-iで無効化をおこないます。たとえば、【図6.2.23】を【図6.2.24】のように変更します（【図6.2.23】同様、改行しないように注意）。
【図6.2.23】envを使って無効化する ▼ # CVS pserver cvspserver stream tcp nowait root /usr/sbin/tcpd /usr/bin/env -i /usr/bin/cvs -f --allow-root=/home/cvsroot pserver ▲
tcpdは、/etc/hosts.deny、/etc/hosts.allowといったファイルで利用者の接続を制限をします。これらの設定方法などは、本書の範囲を超えていますので、各自で調べてみてください。ここでは、自マシン（localhost）と自ドメイン（localdomain）のみに接続許可を出す設定例を示します【図6.2.24】【図6.2.25】。ドメイン名（mydomain.com）とネットワーク（192.168.0.0）、それからネットマスク（256.256.255.0）は各自の環境にあったものを設定しましょう。
【図6.2.24】/etc/hosts.deny ▼ ALL: ALL ▲
【図6.2.25】/etc/hosts.allow ▼ ALL: localhost 127.0.0.1 .mydomain.com 192.168.0.0/256.256.255.0 ▲
tcpdはインターネットに直接接続する計算機の自衛方法として基本的なプログラムです。なるべく使えるようにしておいた方がよいと思います。パッケージ名はtcpwrapperです。最近のRedHat Linuxの配付セットには、はじめから含まれています。もし、パッケージが見つからず、インストール方法も分からないという場合は、危険ですが、CVSを直接呼び出すように設定することもできます【図6.2.26】。また、公開サーバで一般利用者のアクセスを制限する必要がないという場合も、このように設定します。
【図6.2.26】/etc/inetd.confへの追加（tcpdを挟まない場合） ▼ # CVS pserver cvspserver stream tcp nowait root /usr/bin/cvs cvs -f --allow-root=/home/cvsroot pserver ▲
なお、/etc/inetd.confにおける最初のポート番号の指定で、cvspserverという文字列を指定しましたが、あらかじめ/etc/servicesの中にポート番号の別名としてcvspserverが登録されていることが前提になります。最近のRedHat Linuxではあらかじめ別名が定義されていますが、ほかのOSを利用している場合は記述を確認し、定義されていない場合は、【図6.2.27】のような行を追加しておいてください。
【図6.2.27】/etc/servicesの設定部分 ▼ cvspserver 2401/tcp # CVS client/server operations cvspserver 2401/udp # CVS client/server operations ▲
/etc/inetd.conf、/etc/servicesの設定が完了したら、inetdにその変更を通知しましょう。変更の通知は再起動でもよいですし、killコマンドでHUP（ハングアップ）信号を送りつけ（kill -HUP）ても構いません。RedHat Linux 6.xでは、起動スクリプトを利用するのが簡単です。【図6.2.28】のように/etc/rc.d/init.d/inetに引数restartを指定して、inetdを再起動しましょう。
【図6.2.28】inetdの再起動（RedHat Linux 6.x） ▼ /etc/rc.d/init.d/inet restart ▲
Solarisにも起動スクリプト（/etc/init.d/inetsvc）はあるのですが、inetd以外にも余計なものを沢山動かしてくれます。このため筆者はもっぱらkill -HUPで再初期化をおこないます。具体的にはinetdのプロセス番号をpsコマンドで探し【図6.2.29 1行目】、そのプロセス番号にHUP信号をkillで送りつけます【図6.2.29 3行目】。SolarisのpsコマンドはSysV系で、BSD系とはオプションが異なります。詳しくは、manで調べてください。オプションの差異が気になる場合は、/usr/ucbの下にあるpsコマンドを使うとよいでしょう。
【図6.2.29】inetdの再初期化（Solarisでkill -HUPコマンドを実行する） ▼ % ps -ef | grep inetd root 120 1 0 04:01:21 ? 0:00 /usr/sbin/inetd -s % kill -HUP 120 ▲
■■■■■Axinetdでの設定方法(RHL7.x)
RedHat Linux 7.xでは、inetdがxinetdに置き換わっています。初期設定ファイルの書き方も大幅に変更されました。しかし、書く内容自体は、ほとんど変わりません。上記のように「tcpdを使用しない」設定をおこなうファイルを【図6.2.30】に示します。これを、/etc/xinetd.dディレクトリ以下にcvspserverという名前で配置してください。ファイル名はおそらく任意だと思いますが、サービス名と一緒にしておきます。
【図6.2.30】/etc/xinetd.d/cvspserver
▼
# default: off
# description: A CVS (concurrent versions system) pserver.
service cvspserver
{
disable = no
socket_type = stream
wait = no
user = cvsuser
server = /usr/bin/cvs
server_args = -f --allow-root=/home/cvsroot pserver
}
▲
1行目のserviceは/etc/servicesに記述したポートの別名を書きます。次に、socket_type、wait、userといった項目に前と同じようにstream、no、rootを設定します。
serverというのが実行されるプログラムであり、/usr/bin/cvsを設定します。 このとき、CVSは引数を必要とするので、その引数-fと--allow-root=/home/cvsroot pserverをserver_argsに書きます。
ちなみに、もし、envで環境変数の初期化をおこなう場合には、serverに/usr/bin/envを、server_argsに"/usr/bin/cvs -f --allow-root=/home/cvsroot"を設定します。筆者の環境では、tcpwrapper（tcpd）の動作は、serverに書く、書かないに関わらず同じでした。この場合、tcpwrapper（tcpd）の動作を書かなくても、/etc/hosts.deny、/etc/hosts.allowで制御できるのだと考えます。
このファイルを/etc/xinetd.d/cvspserverとして置いたら、xinetdを再起動します。Red Hat Linux 6.xと同じように起動スクリプト（/etc/init.d/xinetd）を直接叩いてもいいのですが、RHL7.xでは/sbin/serviceコマンドをしようするのが、お作法のようです【図6.2.31】。なお、kill -HUPではうまくいきません。
【図6.2.31】xinetdの再起動（RHL7.x） ▼ % /sbin/service xinetd restart Stopping xinetd: [ OK ] Starting xinetd: [ OK ] ▲
なお、pserverを止めたいという場合には、/sbin/chkconfigコマンドを使用して、cvspserverファイルのdisable=noをdisable=yesに変更します。逆に止めたpserverを再度動かすには、/sbin/chkconfig cvspserver onとして、cvspserverファイルのdisable=yesをdisable=noに変更します。【図6.2.31】に/sbin/chkconfigでのcvspserverの書き換えの様子を示します。
【図6.2.31】cvspserverの有効化と無効化（RHL7.x）
▼
% grep disable /etc/xinetd.d/cvspserver
disable = no
% /sbin/chkconfig cvspserver off
% grep disable /etc/xinetd.d/cvspserver
disable = yes
% /sbin/chkconfig cvspserver on
% grep disable /etc/xinetd.d/cvspserver
disable = no
▲
どちらにしろ、変化した設定を有効にするためにはxinetdの再起動が必要ですので、お忘れなく。
■■■■telnetコマンドでの接続テスト
inetdを設定した後は、まず同じ計算機上からtelnetを使って接続できるか確認します。具体的には【図6.2.32】のようにホスト名とcvspserverを指定して、telnetを実行します。
【図6.2.32】telnetでの接続テスト（接続が成功した場合） ▼ % telnet localhost cvspserver Trying 127.0.0.1... Connected to xxx.xxx.xxx. Escape character is '^]'. cvs [pserver aborted]: bad auth protocol start: Connection closed by foreign host. ▲
接続できると、3行目にConnected to xxx.xxx.xxxというようなメッセージが表示されます。表示されずに、【図6.2.33】のようなConnection refusedメッセージが表示されてしまった場合は、うまく設定できていません。再度設定を見直してください。
【図6.2.33】接続が失敗した場合のメッセージ ▼ telnet localhost 2402 Trying 127.0.0.1... telnet: Unable to connect to remote host: Connection refused ▲
/etc/inetd.confの記述で間違いやすいのはコマンドのパスです。また、/etc/servicesを自分で書き換えた場合は、ポート番号の別名の綴りもチェックした方がよいかもしれません。なお、接続に失敗した場合、Enterキーなどを入力すれば、「手順と違う」と表示され、CVSから強制的に切断されます。もちろん、Cntl-]でいったんtelnetの対話モードに復帰し、終了してもらっても構いません。
■■■■CVSクライアントからの接続テスト
inetdで接続できることを確認したら、次はCVSクライアントから接続できるかテストしてみましょう。CVSでクライアントから接続する手順は、次のようになります。
■■■■■@コマンドを使って、認証し認証情報を保存する
CVSのloginコマンドを実行すると、指定されたリポジトリに接続し、パスワード入力を求められます【図6.2.34】。パスワードを入力すると、CVSサーバへ接続して、認証をおこないます。
【図6.2.34】loginして認証情報を保存する ▼ % cvs -d :pserver:bmika@localhost:/home/cvsroot login (Logging in to bmika@localhost) CVS password: ▲
認証が成功するとユーザのクライアント側のホームディレクトリにある.cvspassというファイルにその情報が格納されます【図6.2.35】。
【図6.2.35】~/.cvspass ▼ /1 :pserver:bmika@localhost:2401/home/cvsroot A ?=I0 ▲
Caution! .cvspassのフォーマット変更
1.11.1から.cvspassのフォーマットが変更されました。といっても、ユーザレベルではほとんど意識することがないとは思います。
■■■■■A任意のCVSのコマンドを実行する
一度.cvspassに認証情報が保存されると、ほかのコマンドの実行をサーバに依頼するときにも、その情報が自動的にサーバへ送信されます。
実は、コマンドを実行する度に、この.cvspassの情報を元に認証がおこなわれているのです。これは、コマンドの実行が一回一回独立しているためです。CVSには、前のコマンドの実行と、次のコマンドの実行が同じ人物かどうかを知るすべがありません。そのため.cvspassの情報をもとに、コマンドの利用者が同じかどうか判断するという仕組みになっています。
■■■■■BCVSのlogoutコマンドを使って、認証情報を除去する
.cvspassに認証情報を保持しておいてもよいのですが、第三者が同じ環境で作業する場合や、そもそも「気持ち悪いな」という場合は、logoutコマンドを使って.cvspassの認証情報を削除しておきましょう。削除した場合には当然、次回のloginで再び認証情報を格納するところからはじめる必要があります。
【図6.2.36】logoutして認証情報を除去する ▼ % cvs -d :pserver:bmika@localhost:/home/cvsroot logout (Logging out of bmika@localhost) ▲
リポジトリと同じ計算機上で以上の作業が成功したら、外部から同じように接続を試みてください。外部から接続できない場合は、tcpdを介した場合の制限や、外部のファイアーウォールの影響による制限などといった原因が考えられます。サーバの運用には複雑な要因が絡んできますので、正常に動かすには、問題の原因を把握し、ひとつ一つ取り除いていくことが大事です。
■■■ 6.2.6 SSHのポート転送でpserver接続してみよう
せっかくSSHの設定もしたことですし、SSHのポート転送機能を使用して、pserverの通信をより安全にしてみましょう。ポート転送というのは、通信ポートをSSHが仲介することで、ネットワーク上の通信はSSHが行うようすることです。って言葉で説明してもわかりにくいかと思いますので、【図6.2.37】にイメージ図を示します。cvsクライアントは本来は直接pserverに接続するんですが、そうしないで、一旦sshで接続しsshがローカルに開いたポートにクライアントが接続することで、暗号化してない接続をローカルな計算機内部に限ります。
これは、ローカル（クライアント）側主体のポート転送機能です。リモート（サーバ）側主体のポート転送もあり、その場合にはサーバ内部でsshプロセスが内部のポートに接続を張り、sshはサーバ上で代理のポートで待ち受けを行います。こちらは、サーバの元のポートがローカルからしかアクセスできないようになっているときなどに使用します。以下ではクライアント側主体でポート転送をする場合について説明します。
【図6.2.37】 SSHのポート転送のイメージ図
ローカル側主体のポート転送のためのsshコマンドの使用法を【図6.2.38】に示します。
【図6.2.38】ポート転送のためのsshコマンドの使用法
▼ ssh -2 -N -L ローカルポート:pserverホスト名:2401 ユーザ名@ホスト名 ▲
ここで、-2と-Nのオプションの組み合わせは、ログインシェルが起動しないようにするおまじないです。つけないと通常のログインが開始してしまって、その端末を占拠してしまってちょっとうっとうしいのでつけています。ローカルポートなんですが、1.11以前のcvsだと2401を指定しないと接続することができません。ローカルで2401が使用できるなら、それを使用してください。ここでは、1.11.1以降のcvsでpserverの書式拡張を利用してポート番号を指定して接続してみます。ローカルポートを10000として、まずはsshの経路を開いてみましょう【図6.2.39】。
【図6.2.39】通信路を作るぞ〜
▼ % ssh -2 -N -L 10000:localhost:2401 mika@localhost Enter passphrase for key '/home/mika/.ssh/id_dsa': [1]+ Stopped ssh -2 -N -L 10000:localhost:2401 mika@localhost % bg [1]+ ssh -2 -N -L 10000:localhost:2401 mika@localhost & ▲
なお、ここでは認証終了後、待機に入ったのをCntl-Zで一旦止め、これをバックグラウンドジョブにしています（コマンドbg使用）。これで、通信路を開いたsshが表からは隠れてひっそりと仕事をしてくれるようになります。止めるときには、psでプロセス番号を調べてkillしてください。
この10000ポートが開いているのかtelnetコマンドで試してみみましょう【図6.2.40】。
【図6.2.40】通信路はできたかな？ ▼ % telnet localhost 10000 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. cvs [pserver aborted]: bad auth protocol start: Connection closed by foreign host. ▲
なんとなく、動いているみたいです。では次に、この新たに開いたポートを介してpserverにログインしてみましょう【図6.2.41】。
【図6.2.41】ログインできたみたい。おお。 ▼ % cvs -d :pserver:bmika@localhost:10000/home/cvsroot login Logging in to :pserver:bmika@localhost:10000/home/cvsroot CVS password: ▲
という感じでちょっと手順は複雑に見えますが、より安全な通信を行うことができるようになります。sshで通信路を暗号化する手段にはいろいろありますので、興味がある方は上で挙げた書籍などで学ばれてください。
■■■ 6.2.7 WinCvsで接続しよう
ここではWinCvsでの接続方法について説明します。接続方法そのものは、上で挙げたものと変わりません。ただ、SSHについてはWindowsでも利用できるプログラムを用意する必要があるということです。順に見ていきましょう。
■■■■ extとSSHで接続してみる
後で述べるTeraTermのSSH拡張であるTTSSHなどは、ポート転送機能はあっても、通常のsshコマンドの替わりに使用することはできません。そのため、通常のsshと同じように機能するプログラムを入手する必要があります。選択肢としては、今のところWindows上に移植されたSSHパッケージを利用するか、CygwinのOpenSSHを利用するかの２つだと思われます。CygwinはOpenSSHだけではなく、他に沢山GNUのUNIXコマンドを含む巨大なパッケージです。そのため、Windowsの一般ユーザにはちょっと使いづらいかもしれません。Windows上に移植されたOpenSSHパッケージの情報はOpenSSHのホームページにあります。
▼OpenSSHのWindowsへの移植情報
[http://www.openssh.org/windows.html]
PuTTYはオリジナルのSSHに準拠しており、OpenSSHとは異なるため、ここではひとまずOpenSSH単体移植版、またCygwinのOpenSSHについて簡単に説明します。ちなみに、PuTTYは以下のURLから入手することができます。オリジナルのSSHとの相互運用には有効ではないかと思われます。
▼PuTTYホームページ
[http://www.chiark.greenend.org.uk/~sgtatham/putty/]
■■■■■@ OpenSSH単体移植版を利用
OpenSSH単体移植版は以下のホームページから入手することができます。ちなみに、このホームページによると感謝の意を表すにはAmazon.comの作者のWishlistを尋ねてCDを送ればよいらしいです。
▼OpenSSH単体移植版ホームページ
[http://www.networksimplicity.com/openssh/]
この移植はCygwinのライブラリの一部を使用しているようです。ひとまず、ここから最新版のパッケージをダウンロードしてきましょう。2002年8月の段階ではopenssh34-2.zipが最新でした。この圧縮されたファイルを適当なところで解凍すると、setup.exeが現われます。これを実行してインストールを開始してください。えいえい（2回クリック）【図6.2.42】。
【図6.2.42】インストール開始
ページの都合上、インストールの詳細は省きます。サポートページに流れだけ作っておきますので見て下さい。
▼OpenSSHインストールの流れ(サポートページ)
[OpenSSH-install.html]
このOpenSSHを使えるようにするには、最低でも【図6.2.43】の手順が必要です。まずDOS窓を開き、OpenSSHをインストールしたディレクトリの下にあるsshというディレクトリに移動してください【図6.2.43 1行目】。次に、ここにあるmkgroupコマンドとmkpasswdコマンドでシステムのユーザをOpenSSHが認識できるように変換します【図6.2.43 3、5行目】。使用者がドメインユーザの場合にはmkgroupとmkpasswdのオプション-lが-dに変わります。
【図6.2.43】OpenSSHを使えるようにしよう ▼ C:\> cd インストール先\ssh C:\インストール先\ssh>mkgroup -l >> ../etc/group C:\インストール先\ssh>mkpasswd -l -u mika >> ../etc/passwd ▲
この設定ができたら接続可能になっているはずです。同じディレクトリにssh-keygenやsshも存在していますので、そこで上で述べた鍵生成を行ってください。特に何の設定も行っていない状態では、/ssh/.sshに鍵が生成されます。鍵が無事生成されたら接続実験を行ってください【図6.2.44】。
【図6.2.44】無事に接続できるかな？ C:\インストール先\ssh>ssh mika@cvs.mydomain.com Enter passphrase for key '/ssh/.ssh/id_dsa': Last login: Sat Aug 24 20:16:02 2002 from pc52.mydomain.com % ▲
■■■■■A Cygwinを利用
UNIX環境を使いたいけれど、WindowsとのデュアルブートやPCエミュレータまではちょっと、とかUNIX環境とWindows環境の共存を図りたい、という人向けのパッケージがCygwinです。Red Hat社がオープンソースソフトウェアとして提供しています。最近、日本のHOLON社が、HOLON X on Windowsというパッケージに作り変えて販売もしていました。オリジナルのCygwinには日本語環境がないので、本格的に使用するならばHOLON X on Windowsの方が良いかと思います。また、HOLON X on WindowsのソースとバイナリはFTPでも公開されています。
▼Red Hat社のCygwinのホームページ
[※リンクは任せた]
▼HOLON X on Windows
[http://www.holonlinux.com/product/xonwin/]
Cygwinをインストールする際にOpenSSHを選べば、OpenSSHはインストールされます。Cygwinのインストールについては、説明していると長くなるので、割愛させていただきます。以前企画倒れになったCygwin本の場所に概略を置いておくので参考にしてください。あ、この本が出るといいと思う方はメールください、ご要望が多ければ出るかも。
▼Cygwin本企画ページ
[http://www.mikamama.com/CygwinBook/] ※中身はあとで整える…。
OpenSSH単体のときと異なり、初期設定は必要ではありません。
■■■■■接続してみよう
コマンドラインでの接続を確認したら、WinCvsのメニュー[管理(A)]→[設定(E)]【図6.2.45】を選んで、ssh接続に必要な設定を行います。
【図6.2.45】 [管理(A)]→[設定(E)]メニュー
メニューを選ぶと1番最初に表示される【図6.2.46】の[全体]タブでは、3つの項目を設定します。まず、extによるリポジトリを指定します。ここでは:ext:mika@cvs.mydomain.com:/home/cvsrootとしています。次に、認証方法に「SSH経由で接続」を指定します。そして、RSA鍵の位置を指定します。この例では、C:\home\mika\.ssh\id_dsaに置いてあるものとしています。RSA鍵と書いてはありますが、別にDSA鍵でも構いません。
【図6.2.46】 ext接続でリポジトリを設定しよう
次に呼び出されるべきSSHプログラムの場所を指定します。これは[ポート指定]タブ【図6.2.47】のところで行います。「使用するrshを指定する(H)」というチェックボックスにチェックを入れ、sshコマンドへのパスを入力します。C:\Program Files\NetworkSimplicity\ssh\ssh.exe【図6.2.47】でも、C:\cygwin\bin\ssh.exe【図6.2.48】でも、インストールした環境に従って指定しておいてください。
【図6.2.47】C:\Program Files\NetworkSimplicity\ssh\ssh.exeを指定
【図6.2.48】C:\cygwin\bin\ssh.exeを指定
ここまで設定が終わったら、「OK」を押して設定を完了してください。アウトプット領域に【図6.2.49】のようなメッセージが表示されているかと思います。
【図6.2.49】リポジトリが切り替わったらしい ▼ 新規 CVSROOT: :ext:mika@cvs.mydomain.com:/home/cvsroot (ssh経由の認証) ▲
これは単に全体タブのリポジトリの設定が変わったというメッセージでなので、sshの設定がうまく行っているかはわかりません。何かコマンドを実行して試してみましょう。チェックアウトでもしてみましょうか。何か止まってしまった状態になりましたか？実は、sshがどこかで入力待ちになっています。タスクバーを探してみてください。【図6.2.50】のようなDOS窓が増えているはずです。
【図6.2.50】 時折隠れてしまうDOS窓…
ということでパスフレーズを入力してください。DOS窓が消え、コマンドが無事実行されるはずです。
■■■■ pserverで接続してみる
pserverで接続するには、単に設定メニューでリポジトリをpserverのものに変え、認証方法を指定するだけです。例えば、【図6.2.51】のようにします。認証方法が連動してないので、時々「ローカルな…」のままにしてしまうのが間抜けなんですが…うう。
【図6.2.51】 リポジトリの指定をpserverにしよう
【図6.2.52】リポジトリは切り替わったかな？ ▼ 新規 CVSROOT: :pserver:bmika@cvsmydomain.com:/home/cvsroot (パスワードによる認証) ▲
ただ、初めてpserverを指定した場合には、.cvspassを置く場所を指定するように、【図6.2.53】のようなダイアログが現われます。環境変数でHOMEを設定していても、WinCvsはこの場所を聞いてきます。適切な場所を指定しておいて下さい。
【図6.2.53】 なんかHOMEを指定しろと言われている…
ちなみに、WinCvsには固有のポート転送機能があり、1.11以前のcvsでもこれを利用することで標準のpserverのポート以外でも接続できます。この設定は、[WinCvsの設定]ダイアログの[ポート指定]タブで行います【図6.2.54】。
【図6.2.54】 pserverのポートを違うところにしたい場合
■■■■ SSHポート転送でpserver接続
OpenSSHの単体移植、CygwinのOpenSSHでもポート転送は可能だと思いますが、ここではポート転送に特化したプログラムPortForwarderとTeraTermのSSH拡張TTSSHのポート転送機能について紹介します。TeraTermなどは端末として常時動かしていたりするので、わざわざ別に上げる必要が無いという利点はあります。難点はSSH2に対応していないことでしょうか。ここでは、これらのプログラムのインストールについては割愛します。サポートページに流れだけは置いておきますので参考にしてください。
■■■■■@ PortForwarderで接続してみる
PortForwarderは登 不二雄さんが作成されているSSHのポートフォワード機能の実装です。OpenSSHの完全な実装ではないので機能は限られます。詳しくはホームページを見てください。ソースコード及びバイナリもここから入手できます。2002年8月現在の最新バージョンはPortForwarder 1.1.1です。
▼PortForwarderのホームページ
[http://www.fuji-climb.org/pf/JP/index.shtml]
PortForwarderのインストールには特筆すべきものはありません。取ってきたバイナリを展開すると、【図6.2.55】のようになっているはずです。これを適切なフォルダに移動すればインストールは完了です。
【図6.2.55】 PF-keygenってなんだろう？
ここに含まれているPF-keygenは、GUIでSSH1用のRSA鍵を生成してくれるちょっと便利なツールです。PortForwarderを使用するためには、何らかの形でRSA鍵をこのフォルダに用意した状態でなければいけません。
ここまででまだRSA鍵を作成していない人は、このプログラムを使って鍵を生成しておいてください。起動した最初の画面だけを【図6.2.56】に示しておきます。ここで、鍵のファイル名を入れて、後はそのまま進めていってください。パスフレーズとコメントを求められるので、それを入れて最後まで到達すれば秘密鍵と公開鍵が作成されます。
【図6.2.56】 PF-keygenの最初の画面…新しくRSA鍵が作れる
鍵は用意できましたが、さらに、configファイルを用意しないといけません。このconfigファイルはOpenSSHでクライアント設定をするための~/.ssh/config(/etc/ssh_config)と同じものです。ここにポート転送の実際の設定を行います。ひとまず、CVSのpserverへ接続したいので、サーバ名cvs.mydomain.comやポート番号2401などの情報を使用して【図6.2.57】のような設定ファイルを作成してみました。LocalPortForwardの項目で、localhostの記述はサーバからの相対的な記述で、cvs.mydomain.comを再度指定しても構いません。この項目の内容はコマンドラインでの-Lオプションで指定したものと同じです。
【図6.2.57】こんなconfig.txtをどこかに作ろう
▼
# Host id for CVS pserver
Host cvs
# CVS pserver hostname
Hostname cvs.mydomain.com
# pserver port 2401
# LocalForward clientport server:serverport
LocalForward 2401 localhost:2401
# Username on the host
User mika
# Any other hosts
Host *
User mika
▲
ここまで準備できたら、ようやく起動することができます。やれやれ。アイコンを叩いてみましょう、よいしょ【図5.2.58】。
【図6.2.58】 ようやく起動できた…
ここで、「Config file」にまず、先ほど作成した今configファイルを指定します。そして、「Host」のところには、このconfigファイルで指定したところのcvsというホスト識別子を指定します。後は「Connect」ボタンを押すと、パスフレーズ入力画面になるので、入力して接続を開始してください【図6.2.59】。初めての場合はknown_hostsへの登録を警告されたりしますが、「OK」を押して進めてください。
【図6.2.59】 パスフレーズを入力しよう ※要差し替え
【図6.2.60】のように入力画面が不活性化して、「Hide」ボタンが活性化したら、無事接続しています。静かに置いておいて下さい。
【図6.2.60】 静かに接続しております… ※要差し替え
■■■■■A TTSSHのポート転送機能で接続してみる
TeraTermProは端末ソフトとして広く利用されていると思います。TeraTermProにはSSH1を使用できるようにしたTTSSHという拡張版があります。このTTSSHには、ポート転送機能がありますので、ここではそれを利用するための手順について説明します。TeraTermProやTTSSHのインストールについては、紙面の都合上割愛ささて頂きます。サポートページに流れだけ載せておきます。
▼TeraTermProのホームページ
[※リンク頼みます…（涙]
▼TTSSHのホームページ
[※リンク頼みます…（涙]
▼TeraTerm+TTSSHのインストールの流れ（サポートページ）
[TeraTermPro_SSH.html]
ポート転送は可能ですが、TTSSHにはRSA鍵を生成する機能がありません。このため、別の場所なりツールなりで作成する必要があります。PF-keygenを利用するのが一般的なようです。ともかく、ここではRSA鍵はすでに用意されているとしましょう。
さて、TeraTermPro+TTSSH(ttssh.exe)を起動すると【図6.2.61】のような画面になります。
【図6.2.61】 TeraTermPro+TTSSH(ttssh.exe)の起動画面
とりあえずここは「Cancel」して、「接続していないけれどTeraTermPro+TTSSH(ttssh.exe)が動いている状態」にしてください。ここで、ポート転送に必要な設定をしていきましょう。まず、RSA鍵の設定が必要です。これはメニュー[Setup]→[SSH Authentication...]【図6.2.62】から行います。
【図6.2.62】 [Setup]→[SSH Authentication...]メニュー
【図6.2.63】のようなダイアログが現われたかと思います。
【図6.2.63】 RSA鍵の指定をしよう
このダイアログでは、RSA鍵のファイルとついでにユーザ名を指定します。ここでは、ユーザ名にはmika、RSA鍵のファイルにはC:\home\mika\.ssh\identityを指定しています。ここは各自の環境に合わせてください。「OK」を押して、次の設定に行きます。次は、ポート転送の設定です。ポート転送の設定はメニュー[Setup]→[SSH Forwarding...]【図6.2.64】からおこないます。
【図6.2.64】 [Setup]→[SSH Forwarding...]メニュー
メニューを選ぶと、【図6.2.65】のようなダイアログが現われます。設定のリストが並ぶ場所がありますが、この段階ではまだ何も登録されていないと思います。 これにCVS pserverのためのポート転送設定を追加します。追加するために「Add」ボタンを押しましょう。
【図6.2.65】 転送設定のリストだ…空だけど
すると、【図6.2.66】のような設定ダイアログが現われます。ここで、ローカル側の転送ポート2401、サーバ名cvs.mydomain.com、サーバ側のpserverのポート2401を図のように入力します。一覧にはcvskserverはありましたが、cvspserverは見当たりませんでした。ので、数字で指定しています。
【図6.2.66】 CVSのポート転送設定をしよう
きちんと入力を終えて「OK」ボタンを押すと、【図6.2.67】のように設定のリストに、CVS pserver用の転送設定が追加されます。
【図6.2.67】 おお、設定が加わってる（パチパチ）！
この設定を保存して、転送専用に使用します。まずは、メニュー[Setup]→[Save setup]【図6.2.68】として転送専用の設定ファイルを作成しましょう。
【図6.2.68】 [Setup]→[Save setup]メニュー
【図6.2.69】の画面で専用設定ファイルをCVS_PF.INIとでもして保存してください。
【図6.2.69】 転送専用設定ファイルCVS_PF.INIの保存
これで、TeraTermPro+TTSSH上での作業は終わりです。ひとまずここで（CVS_PF.INIを使用して）、CVS pserverのあるサーバにsshでログインしてください。通常の端末が開いたかと思います。実はこの状態で傍目からはわかりませんが、かげながらポート転送が動いています。ひとまず、この状態で接続テストをするので、おいてください。
Column ポート転送用のショートカットを作成しておこう
設定ファイルの切替えははちょっと面倒です。転送設定のしてある設定ファイルを使って複数立ち上げると文句を言われたりしますし。これらの問題を避けるために、転送専用のショートカットを作成しましょう。便利なところ、例えばデスクトップとかラウンチャにttssh.exeのショートカットを作成してください【図6.2.70】。
【図6.2.70】 ショートカットの作成
このショートカットを右クリックして、プロパティを出します【図6.2.71】。
【図6.2.71】プロパティの書き換え
ここで、「Target」が「C:\Program Files\TTERMPRO\ttssh.exe」になっているかと思いますが、これを「C:\Program Files\TTERMPRO\ttssh.exe /ssh cvs.mydomain.com:22 /F=CVS_PF.INI」のように書き換えてください。「"」のついているついてないは結構シビアですので注意してください。XPでは必要ありませんが、2000などではプログラムには「"」をつける必要があるかもしれません。オプションと引数ににはつけないでください。あと、「C:\Program Files\TTERMPRO\ttssh.exe」、「/ssh」、「cvs.mydomain.com:22」、「/F=CVS_PF.INI」は空白で区切ってください。
ポート転送が必要な場合にはこのショートカットから起動し、通常は標準の設定ファイル(TTERMPRO.INI)を使うようにしておけば、切替でごちゃごちゃしたり、ポートを開けようとして文句を言われたりしなくなります。
■■■■■ポート転送でpserverに接続してみる
どちらかの設定が完了したら、接続をテストしてみましょう。DOS窓からtelnetで設定した転送ポートに接続してみます【図6.2.72】。
【図6.2.72】 DOS窓でtelnet
ここで、Connect failedとか言われたら失敗です【図6.2.73】。
【図6.2.73】 繋がらなかった！ショック！
何の返事も無く固まってしまったら成功です。リターンキーを押すと文句を言われて終わりますので、押してください【図6.2.74】。
【図6.2.74】 何か文句言われた…けど繋がった模様
次に、WinCvsから接続します。設定はいたって簡単です。pserverでのリポジトリ設定のホスト名を本物のホスト名からlocalhostに書き換えるだけです。ユーザ名とか、リポジトリのパスとかは元のまま残しておいてください。【図6.2.75】のような感じです。元は:pserver:bmika@cvs.mydomain.com:/home/cvsrootだったものを、:pserver:bmika@localhost:/home/cvsrootに書き換えたわけです。
:【図6.2.75】 pserverのホスト名をローカルに切り替える
アウトプット領域に切替のメッセージが出たら確認してください【図6.2.76】。後は、いつもどおりログインしてチェックアウトなどをすれば、ごく普通にできるはずです。じゃんじゃん使ってみてください。
【図6.2.76】ちゃんと替わってるかな？ ▼ 新規 CVSROOT: :pserver:bmika@localhost:/home/cvsroot (パスワードによる認証) ▲