環境変数にIDやPASSWORDを設定しなければならない状況で、ID/PASSWORDをファイルに平文で保存したりシェルの履歴に残したくない (Kanasansoft Web Lab.)

zshを前提にしているが、問題の解決方法が重要なので、ちょっと記述を変更すれば他のシェルでもできるようになるはず。また、暗号化には「gpg」の共通鍵暗号化方式(対象鍵)を使用している。

環境変数にIDとPASSWORDを設定しなければならない場合、例えばProxyだと次のようになる。

export http_proxy="http://userid:password@proxyaddress:portno/"

これを、「.zshrc」等に記述するか「zsh」で打ち込むのだがセキュリティ上の問題がある。「.zshrc」に記述する場合はID/PASSWORDを平文で保存しなくちゃならない。直接打ち込むとシェルの履歴に残ってしまう。色々な人の協力を得て、簡単ではあるがこれを解決する方法を見つけることができた。

まず、次の関数を「.zshrc」等に記述して「source」で読み込むか「zsh」を再起動する。

secenv()
{
    file=~/.secret_environment_value
    if [ $# -eq 0 ]; then
	`gpg <$file`
    fi
    if [ $# -eq 1 ]; then
	`gpg -c --output $file $1`
    fi
 }

secenv()
{
    file=~/.secret_environment_value
    if [ $# -eq 0 ]; then
    `gpg <$file`
    fi
    if [ $# -eq 1 ]; then
    `gpg -c --output $file $1`
    fi
}

環境変数を設定するファイルを準備する。

env.txt

export http_proxy="http://userid:password@proxyaddress:portno/"
export ftp_proxy="http://userid:password@proxyaddress:portno/"
export HTTP_PROXY="http://userid:password@proxyaddress:portno/"
export FTP_PROXY="http://userid:password@proxyaddress:portno/"

ここではファイル名を「env.txt」にした。そしてさっきの関数にファイル名を指定して実行する。

secenv env.txt

パスワードを2回聞かれるので入力する。暗号化された情報が「~/.secret_environment_value」に保存される。そして、env.txtを残しておくと危険なので削除。

rm env.txt

これで準備は完了。後は環境変数の読み込みが必要になった時に次のコマンド実行してパスワードを入力すれば良い。

secenv

関数内の処理の肝は「gpg」のファイル指定に「<」を使っている事と「`」を使って実行している事。「gpg」を「<」を付けずに実行すると、暗号化した内容が実ファイルとして出力されてしまう。環境変数の反映には「source」を使うべきだと勝手に思い込んでいたが、「source」は引数にファイルしか指定できないようなのでどうしようか悩んだけど、「`」の存在を思い出した。関数を弄れば反映させる環境変数を選択することも可能になると思う。

2009/05/08 追記関数にした理由

当初は以下のような方法で済むと考えてた。

alias make-secenv="gpg -c --output ~/.secret_environment_value"
alias secenv="`gpg <~/.secret_environment_value`"

しかし、この方法だとうまくいかなかった。.zshrcは正確には設定ファイルではなく、あくまで実行スクリプト(のはず)なので、別名を設定しようとした時、つまりzshの起動時に復号化してしまう。JavaScriptであればこのような場合、無名関数に閉じ込めて遅延評価をさせたりする。shellでも同様な事ができないかと調べていたら関数でできそうだとわかった。実は、shellの関数を書いたのははじめてだったりする。

2009/05/08 追記 hist_ignore_space

zshであれば履歴に残さないようにする設定があると、複数の人から聞いた。

setopt hist_ignore_space

履歴に残したくないコマンドははじめにスペースを入れておくと良いらしい。お手軽だけど「shoulder hacking」の危険があって一長一短かな。

2009/05/08 追記 chmod 600

はてなブックマークで、permissionを600にしておくというアイディアを頂いた。なるほど。これでも用途によっては大丈夫そうだ。欠点はroot権限保持者に見られる可能性とcygwinの場合は対応できないことか。

2009/05/08 追記 secenv関数の短所

柔軟性には欠けると思う。他に何か欠点ってあるのかな。

2009/05/08 追記どの方法をとるべきか

関数・hist_ignore_space・permissionのどの方法を採用するのか。まあ、それぞれ一長一短なので長所短所を踏まえた上で選択すればいいのかな。

Kanasansoft Web Lab.