ssh-xferを使って既存のSSH接続経由でファイルをすばやく取得する
Secure Shell（SSH）とSecure Copy（SCP）を使えば、システムのリモート管理や、セキュアなリンク経由のファイルコピーは難しくない。SSHとSCPは、どちらも同じSSHプロトコルを使用してネットワーク通信を保護するが、シェルの実行やファイルのコピーにはユーザの介在を必要とする。また、リモートマシンへの既存のSSH接続を使ったファイル取得は容易ではなく、SCPによるファイルコピーの際には別のSSH接続が必要になる。だが、 ssh-xfer を使えば話は別だ。
ssh-xferでは、ローカルのSSHエージェント（ssh-agent）を利用することで、既存のSSH接続を介したファイル転送が簡単に実行できる。ssh-xferを使うにあたり、SSHのクライアントやサーバのプログラムの変更は不要だが、ssh-agentにパッチを当てる必要がある。できればssh-agentにパッチを当てずに済ませたいところだが、これには複数のSSH接続を介したファイル転送が可能になるという大きな利点もある。たとえば、まずファイアウォールに接続し、そこから順にリモートサーバ、リモートデスクトップマシンへと接続して、そのリモートマシンのSSHから「/etc/foo.conf」ファイルを取得しようとする場合に、ローカルマシンからそのファイルにたどり着くまでの過程や、SCPによってすべての中間ホストを介してそのファイルを転送する方法を考えなくても済むのだ。リモートマシンのSSHから単純に「ssh-xfer /etc/foo.conf」とするだけで、このファイルがローカルマシンの「~/Desktop」にコピーされる。また、デフォルトの転送先ディレクトリはssh-xfer用パッチの「XFER_DEST_DIR」で指定できる。もちろん、リモートマシン側でssh-xferプログラムが使えるようにしておく必要があるが、サーバ側のSSH環境の変更は一切必要ない。
ssh-xferにはFedora用、Ubuntu用、openSUSE用のいずれのパッケージも存在しない。ここでは、64ビット版Fedoraマシンでssh-xferバージョン0.15のソースからのビルドを行う。また、SSHにはFedora 9のアップデートリポジトリから入手したOpenSSH 5.0p1-3.fc9を用いる。
下記の「rpmbuild --recompile」コマンドにより、FedoraがOpenSSHに追加したすべてのパッチを含め、OpenSSHのソース取得とビルドが行われる。ここではssh-agentにパッチを当てるので、ディストリビューションで使用する際にそのソースを再生成したうえでssh-xferのパッチを適用するのがよさそうだ。パッチには最新のソースにうまく適用できない部分がいくつかあったが、返り値のちょっとした違い（返り値がないところで0が返されるなど）に関係したものがほとんどで、それ以外は確かにパッチの適用を妨げる内容ではあったが門外漢でも簡単に修正できるものだった。とりあえず、Fedora 9のアップデートにあるOpenSSHのバージョン5.0p1-3.fc9を使って生成した更新済みのパッチをアップロードしておいたので、ほかの人はこうした修正に煩わされずに済むだろう。
$ rpmbuild --recompile /FromWeb/openssh-5.0p1-3.fc9.src.rpm $ cd ~/rpmbuild/BUILD/openssh-5.0p1/ $ patch -p0 < /FromWeb/ssh-xfer-0.15.diff ... patching file ssh-agent.c ... Hunk #16 FAILED at 1417. 2 out of 16 hunks FAILED -- saving rejects to file ssh-agent.c.rej ... use my patch above or fix these issues by hand.
ssh-agentのソースにパッチを当てたら、以下のコマンドでソースツリーを構成し直してからssh-agentおよび新しいssh-xferプログラムのリビルドを行う。そのあと、ローカルのデスクトップマシンで修正済みのssh-agentを実行すると共に、ファイルの転送元となるリモートマシンでssh-xferのバイナリが使えるようにする必要がある。リモートマシン側のディストリビューションがssh-agentおよびssh-xferをビルドしたマシンのものと同じ場合は、SCPを使ってリモートマシンにssh-xferを用意するのが手っとり早いだろう。
$ ./config.status $ make all ssh-xfer $ su -l # chown root:root ssh-xfer # chmod 755 ssh-xfer # scp -pv ssh-xfer myserver:/usr/local/bin # install --mode 755 ssh-agent /usr/local/bin/ssh-agent-xfer
ssh-xferを使うには、修正したssh-agentを起動しておくと共に、認証エージェントによる接続転送を有効にする必要がある。エージェント転送機能の使用は、セキュリティ上の問題を引き起こすおそれがあるため、デフォルトでは無効になっている。一般に、エージェント転送で接続しようとするリモートマシンにファイルパーミッションのチェックをバイパスする手段が存在する場合、リモートマシン側のセキュリティチェックをすり抜けた者がローカルのSSHエージェントにアクセスしてくる可能性がある。こうしたセキュリティの問題は、リモートマシンのエージェントへの接続を、ローカルマシンのエージェントに転送する機能を有効化しようとする場合に生じる。
以下のコマンド列は、修正によってssh-xferに対応したssh-agentを使ってローカルのbashシェルを実行したうえで、リモートマシンへのSSH接続の確立、リモートマシンでの新規ファイル作成、ssh-xferによる作成ファイルのローカルマシンへの転送を行う。
ben@desktop ~$ ssh-agent-xfer bash ben@desktop ~$ ssh -A ben@myserver ben@myserver ~$ date > myserver-testfile.txt ben@myserver ~$ ssh-xfer myserver-testfile.txt Sending file . done. ben@myserver ~$ exit ben@myserver ~$ cd ~/Desktop ben@desktop Desktop$ ls -lh -rw------- 1 ben ben 29 2008-07-21 21:11 myserver-testfile.txt ben@desktop Desktop$ cat myserver-testfile.txt Mon Jul 21 21:19:14 EST 2008
sshのエージェント転送を利用するという点でssh-xferを敬遠する人もいるだろう。ssh-xferのホームページにも、ハック的な要素が強いことや、ファイルのバイト転送に使われるプロトコルの完成度が十分でないことが記されている。ssh-xferはエージェントを利用しているため、SSH接続を連鎖的にたどることによってリモートマシンのファイルを直接ダウンロードすることができる。このとき、ダウンロードしたいファイルのあるホストにどうすれば到達できるのかをいちいち考える必要はない。
ダイヤルアップ接続とターミナルプログラムを使ってUNIXマシンに接続していた頃は、コンソール画面から直接コマンドを発行してダウンロードを開始することができた。ファイル転送のためにSSHエージェントを拡張するというアイデアは、そうしたひと昔前のやり方を現在のSSH接続にもたらすものであり、リモートターミナルからのファイル転送の開始を可能にしてくれる。
Ben Martinは10年以上前からファイルシステムに携わっている。博士号を持ち、現在はlibferris、各種ファイルシステム、検索ソリューションを中心としたコンサルティング業務に従事。
