ssh を日々使わぬ日は無いが, 秘密鍵のパスフレーズを変てこで長い文章にしてしまい, 毎日後悔していました.
すると, どこからともなく助けが現われ, というのは嘘で, 二宮さんがこういう便利なものを教えてくれました. 知らんかった....
じゃあ今までどうしてたのかというと, ssh でログインするのは一日一回くらいなんで, 別に長いパスフレーズでも問題ないわけです. ところが, 最近 ssh ごしに CVS を使うようになってからというもの, update するとパスフレーズを聞かれ, diff すると聞かれ, commit すると聞かれ, status を調べると聞かれるという, 悲惨な状況になってしまいました.
この悲惨な状況も, ssh-agent を使えばバッチリ解決. パスフレーズを要求されるのは, 最初の一回だけ. おおお！ なんて便利なんだ！ と感動したのでここに記事を書きます. 二宮さん, また, Webmasters チャネルでお助け下さった 中野さん, 鵜飼さん, ありがとうございます.
ssh-agent はユーザの秘密鍵を保持し, 認証を代行するプログラムです. ユーザの秘密鍵を, こいつに登録すれば, 以後, こいつの制御下に あるプログラムからの ssh クライアントな仕事に関しては, 公開鍵認証をこいつがやってくれるのだ.
具体的な使い方としては, xsession を ssh-agentの制御下に置くやりかたがある. これが本来の意図された使い方で, たとえば ".xsession" に
ssh-agent gnome-session
などと書くと, ログインセッションの子プロセス, つまり, ユーザがログインしてから起動するプログラムは全部, agent の 制御下に入り, 認証代行業務の恩恵をうけることができる.
ユーザの秘密鍵を登録するには, ssh-add を使う. 引数無しで起動すれば, デフォルトのユーザの秘密鍵 (.ssh/identity とか) が使われる. この際, 秘密鍵にアクセスするためのパスフレーズ入力がある. 以後, 認証はあなたの代わりに agentがやってくれるので, ウザいパスフレーズの入力は不要.
ところで, つまり, このプログラムを使っている場合は, 以後の作業は, 本人がやったもの とみなされるわけです. だから, セキュリティ上非常に重要な仕事でこれを使うのは良くないかもしれないですね. だって, もし何か事件があって, それがあなたを装って行われたものであったとしても, ssh 秘密鍵が無いとできないような行為だった場合, 自分はやっていない, と立証するのはかなり大変かもよ？ でも, 実際には ssh-add さえされていれば, 小便行ってる間なんかに ズギャっと何でもできるわけですから.
うひひひ. つまり, ssh-agent 制御下のプログラムは, 自分以外が操作できちゃだめなのだよ. ま, そういうはなしは置いといて, だ.
なにも, ログインセッションを全部こういう環境にしてしまう必要は無く, シェル毎にこういう環境を作ることも可能だ. ssh-agent をシェルから叩くと, 何やらコマンドを吐く. ssh-add が agent に接続するために必要な環境設定コマンドだ. これを, agent を実行したシェルで, 同時に実行しておけばいい. sh 系(bash とか zsh) なら
eval `ssh-agent`
こんな感じで, 以後 ssh-add すれば, そのシェルの中では, 以後上記代行業務が執り行われる. もっとも, こうしたからといって, ログインセッションを全部 agent 化するよりも 安全になるわけではないのだが.
む. べつに eval しなくても,
ssh-agent zsh
てやればいいことに気づいた. 一個シェルが無駄になるが, こっちの利点は agent が無駄に残らないところ. agent の制御下にあるシェルから抜ければ, agent も終了する. わざわざこういうことをする理由というのは, shell から引数ナシで agent を叩くと logout してもプロセスが残ってしまうのだ. 今日気づいたら, ssh-agent1 が 4個 ss-agent2 が 3個. 合計 7個残ってやがった. ええ, そんなときは ikill でまとめて終了させますがね.
agent ごとに違うソケットを開くので, 一人のユーザが同時に複数の agent を使うこともできる. そんなことに, 何か意味があるとも思えんが(笑). 個人的には ssh1 と ssh2 を両方使っているので, こういう使い方もあるのは助かる.
どっちにせよ, ログインセッションを全部 agent の制御下に 置く方が便利であることは間違いないところだけどね. (2000/10/22 加筆)
というわけで, ssh ごしに cvs を使う場合は, こいつは必須！ 以上！
「日本のlinux情報」から行けるサイトといえば, わりとかなり強まったところが多いわけで, そのなかの一つ, 一歩進んだ Mule の活用法 に掲載されていた, scheme のナイスな開発環境の作り方.
これで, C-x C-e で eval した S 式が scheme インタプリタに送られ, 結果が別窓に出る. 別窓を消せば, schem インタプリタも終了する. とまあ, こんなかんじで, emacs lisp を書くのと同じ感じで scheme も書けるようになるわけですな.
ここですぐ思い付くのは, 同じことが script-fu server を使ってできる, ということ. GIMP を起動し, script-fu server を立てれば, emacs からの eval で GIMP がグリグリと. わっはっは. こりゃ楽しそうだな. 作ろ.
ソケット開く関数とかあるじゃろ, と思ったら案の定, ありますな. open-network-stream モロ. そのまんまですな. ハイパーコアの gimp-ml で梶山さんという方が script-fu 鯖のプロトコルを解析してくださったので, それにそって process-send-ナントカ みたいにすりゃよさげ？ 多分(←良く解ってない). シンボルテーブルから関数名その他を補完できると, 良いなあ. もちろん, define を eval したらテーブルは更新されるわけで. うっひっひ. む. describe-hoge を作るのは, ちょっと大変かも. でも, せっかく作るなら, それもぜひ欲しいところだなあ.
モードの名前は script-fu-mode ですな. でも, こんなの 俺ですら思い付くのであるから, なんか 1024個めくらいの車輪という気もして, やや萎みぎみでもあるわけですがね.