UNIXやLinux: 2009年5月アーカイブ

GnuPG の設定で、サーバ側で鍵情報を作成しようとしたらエントロピーが足りないと言われ処理が止まっちゃう。（ssh でリモート接続して作業中）

# gpg --gen-key
gpg (GnuPG) 1.2.6; Copyright (C) 2004 Free Software Foundation, Inc.
＜略＞
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.++++++++++...+++++.++++++++++.++++++++++++++++++++.++++++++++.+++++..++++++++++>+++++++++++++++

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 283 more bytes)

なので、適当に何百文字もキー入力してみるのだが全然動き出す気配無し。
エントロピーというのは、乱数の「素」にするための「不確定性、乱雑、無秩序」なデータのことで、あるタイミングで計ったディスクアクセス数であったり、キーイン数であったり、マウスの位置であったり、そういう値なのだが、それが足りないとおっしゃる。

Windows 上で鍵を作る時はマウスを思いっきり動かしたりしてエントロピーを溜めるわけだが、ssh で接続したリモートサーバの場合はどうすんのかね？
かなりの文字数を入力してみたが、全然足りないようだ。

と思ってググってたら、別の ssh セッションで接続して、そっちで意味の無いディスクアクセスを大量に発生させちゃえばいいぜ！という情報発見。

別の ssh セッションで、

$ dd if=/dev/urandom of=/tmp/mass bs=1M count=512

としたら、一回り（512回転）では駄目で、もう一回、200回弱書込を行ったところでエントロピーが十分取得できたようだ。
自動的に再度、キー情報の作成処理が実行された。

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
..+++++.++++++++++..+++++++++++++++++++++++++..+++++++++++++++++++++++++..+++++++++++++++++++++++++.++++++++++.++++++++++++++++++++++++++++++>+++++......>+++++<.+++++..............+++++^^^^^^^^^^^^^^^
gpg: /root/.gnupg/trustdb.gpg: trustdb created
public and secret key created and signed.
key marked as ultimately trusted.

pub  1024D/F985786F 2009-05-25 Exsample WWW Server Administrator <admin@exsample.jp>
     Key fingerprint = C809 47C7 0B8C XXXX CF43  BB0C XXXX A085 F996 796F
sub  1024g/AA8FFA04 2009-05-25

ばっちりですな。

しかし、エントロピーが足りないなんて言われたのは初めてだ。

某マスコミ系会社のサーバや、WebARENA 上のホスティングサーバなどで作業をしたことがあるが、どれも ssh セッション上の作業で全然問題なく鍵情報が作られたんだけどな。
しかも、今回作業したサーバは、けっこう Web サイトへのアクセス数もあるサーバなのだが・・・

どうも、ここのところ見積り外の作業が発生するケースが多いような・・・(^^;

最近、Red Hat Enterprise Linux で扱う FTP サーバはずっと vsftpd ばかりだった。
ところが今週触ったサーバが ProFTPD で、あまりに久しぶりなんで戸惑ってしまった。

FTP 用のユーザ追加して、ちゃんと chroot してるか /etc/proftpd.conf の DefaultRoot をチェックして、

DefaultRoot                     ~ !wheel

うん、wheel グループ以外のユーザは DefaultRoot が ~（自分のホームディレクトリ）になってるな・・・と確認。
ほんじゃ、接続してみますか・・・と ftp コマンド叩いたんだけど、認証ではじかれるじゃーん！？

Name (localhost:hoge9999): hoge9999
331 Password required for hoge9999.
Password:
530 Login incorrect.
Login failed.

他のユーザの設定を見て、どうも ftpusers というグループに所属してないと駄目だということはわかったんだけど、さて、その設定はどこにあるのやら？？？
穴が開くほど /etc/proftpd.conf を眺めてみたけど、そんな設定、あったっけぇ～？？？と、しばし悩む。

で、/var/log/messages 見てみたら、proftpd が「FTP session opened.」なメッセージを吐いた後、同じ PID で PAM が続けてメッセージを吐いてるじゃん。
なんだ。PAM 使ってるのか。

てことで、/etc/pam.d/ftp 見てみたら、

auth       required     pam_succeed_if.so user ingroup ftpusers
auth       required     pam_stack.so service=system-auth
auth       required     pam_warn.so

ああ、やっぱり。

ログインユーザが ftpusers グループに含まれていれば OK という設定がありますな。

と思って、もう一度 /etc/proftpd.conf を見てみると、

AuthOrder                       mod_auth_pam.c* mod_auth_unix.c

ああ、認証で PAM 使うって、ここに書かれてたのね。(^^;