FreeBSD で ZFS と共に GELI を使う2010年07月21日 04時59分27秒

FreeBSD でディスクの暗号化と言えば GELI。GEOM_ELI が正式なモジュールの名前になっている。

geli init で -a を使うと更に、データの整合性も調べられるようになる。データのハッシュ値を保存して、もしデータの破損が確認される。なお、-a オプションを使わないとこの機能は有効にはならない。ただ、データの有効性を調べるだけなので、壊れてしまったら直すことは出来ない。raid3 や mirror などの別の方法でデータ破損に備える必要がある。

そのため、zfs を暗号化するために、geli を用いるのであれば、百害あって一利無しとなる。zfs では、最初からデータの整合性の確認は有効になっていて、破損していても raid-z や mirror では、しっかりと対処してくれる。

ssh_exchange_identification で失敗する理由2009年01月21日 00時28分07秒


ssh_exchange_identification: Connection closed by remote host

ssh が上記のエラーを表示して失敗することがある。

これについて検索をすると、/etc/hosts.allow および/etc/hosts.deny の設定の可能性が多々指摘されている。幾つかの件では、実際にこれで問題が修正されたみたいだ。

他にも、sshd を inetd で立ち上げようとしたが、-i を指定していなかったために、同じメッセージを出して失敗していた物も見つかった。

今回は別件の問題に遭遇した。ssh を使って連続的に大量の並列接続をする時もこのエラーに遭遇する。初期値では接続認証中の最大数が MaxStartups で 10 になっている。ssh をバックグラウンド処理にして、ループで大量の接続を試みると、すぐにこの予約分が使い尽くされて、失敗するようになる。ssh の接続認証に時間が掛かるので、意図せずにこの認証制限に引っかかるのだ。

この原因の特徴としては、まず、一回ずつ手で試すと問題が無い点だろう。そして、大量の接続を行なう様な環境が二つ目だ。スクリプトで処理しようとして接続が失敗する事が出てきたら、この値を疑ってみると良い。

FreeBSD-SA-09:03/042009年01月14日 03時11分35秒

OpenSSL の SAに伴って変更が必要な物が上がってきた。ntpbind だ。前回の SA に絡んだ変更になっている。

なんだか、小出しにチョコチョコと見つかっていて煩わしい。手元では、bind も ntp も使っていないので、今回の更新は見送るつもりでいる。

SSH の FallBackToRsh を再度有効にする方法2009年01月11日 04時05分29秒

OpenSSH では rsh への後方互換は削除された。しかし、移行途中や古いシステムがあるため、rsh を使わざる得ない環境もある。

データが流れない為ネットワーク上を覗かれても関係ない、またネットワークが完全にプライベートで構成されていて、不法侵入を試みようとするのなら、物理的に警備を潜って侵入しなければならないなどの理由で、わざわざ ssh を使わない所もある。その様な所でも、規制などの理由により、好まないながらも移行を試みなければいけない所もある。

Re: rsh fallback にて、このオプションが無効にされた時の変更があげられている。これをリバースパッチとして、組み込めば FallBackToRsh を再び使うことが出来るそうだ。自身では試していないのでこれで、正しく動作するかまでは試していない。

FreeBSD-SA-09:02.openssl に amd64 で対応する時の注意点2009年01月07日 21時13分14秒

FreeBSD から FreeBSD-SA-09:02.openssl が出された。

EVP_VerifyFinal() 関数が返り値を正しく処理していない為に、DSA か ECDSA を用いた時に、問題のある署名でも正しいと判断される事があるそうだ。

基本的にはパッチを当てた後に、ライブラリだけを作り直せば済む。しかし、ビルドの処理の仕方の為だろうか、amd64 システムにて、lib32 を使っている場合は、buildworld をやらないと、修正が取り込めない。i386 の互換を使っている時である。

OpenSSH の FallBackToRsh2009年01月03日 09時56分46秒

現在、rsh を主体としたリモートアクセスを ssh に移行する準備をしている。面倒なのは、ホストの中に SunOS 4.1.4 があることだ。とても古い。最新の OpenSSH をコンパイルしようとすると、configure が失敗する。

ただ、この SunOS 4.1 のシステムは、そんなに長くはないかもしれない。そんな状況なので、段階的に移行していくことにし SunOS 4.1 は最後に更新すると言う建前で、実はシステム自体が無くなるのを待つと言う本音作戦が一番楽な手だ。

どうせ、十年来 rsh で使っていたシステムみたいなので、急に全てを変える必要もあるまい。ホストの数も結構ある。また、色々とシステムの出来が悪く、あちこちに rsh/rcp が散見されて一貫性が無い。また、システム間で同期されているファイルとされていないファイルがある。そんなこんなで。一括変換は何かと問題が置きやすいシステムなのだ。

そこで、ssh の rsh への後方互換に付いて探っていた。OpenSSH では、ssh_config を見ると FallBackToRsh と言う記述があれば、この ssh のバイナリは ssh プロトコルを試して駄目ならば、rsh プロトコルを試す。これは、バイナリの名前等には依存しない。つまり ssh で呼ばれても、rsh を使うことが出来る。そして、rsh を ssh バイナリに置き換えることにより、部分的な ssh プロトコルを実装できる。

この FallBackToRsh なのだが、OpenSSH にて実装が削除されたそうだ。暗号化されている筈の ssh が暗号化されていない方法を使うのが、気に入らないかららしい。完全にコードから削除されていた。

こういうものは、デフォルトでは切ってあり、コンパイル時の設定により有効になるようにすると、利便性を損なわずに、暗号化の目的も果たせる。しかし、OpenSSH の開発者達は、この方法すら気に入らないらしい。

Sys V 系のグループ権限の実装の方が安全だ2008年12月26日 10時53分05秒

Sys V 系と BSD 系で違った動作をするグループ権限に実装だが、Sys V 系の方が、制限の方が厳しい。

最近は以前より、/tmp で作業をする事が多くなった。メモリが GB 単位で手に入る時代になったので、数時間で消されるファイル、統計や解析などを行うときは、まずここでする。

/tmp は root:wheel で、 777 の設定が多い。BSD 系でも、そのままで見られる人達は wheel に属する人達ではあるので、ある意味ここではどちらの実装でもあまり関係ない。

しかし、書き込める場所であれば、意図的では無かったにしても、BSD 系の実装では、うっかり他のグループが読めるファイルを作ることが出来てしまう。その点、Sys V 系では、自分の属するグループなので、その影響は限られている。

しかし、Sys V 系の実装では、誰かに故意にファイルを作られて権限を操作されると、ディレクトリを消したくても自分では消せないファイルが出来てしまうと思う。これは、困る。

rsh から ssh への移行2008年12月20日 15時46分04秒

rsh を主体で使っている所で、ssh への移行を頼まれた。実践で学ぶ、一歩進んだサーバ構築・運用術 第 11 回 ssh (後編)が参考になる。

基本的には、rsh のバイナリ自体を ssh に置き換えれば出来るみたいだ。なお、パスワードに関する設定は除く。

しかし、システムアドミニストレータと、開発/運用で異なる人がかかわる場合、また、大人数の人達が働くプロジェクト等では、rsh と書かれていて実は、ssh で動いていますというのは、自分の足元に地雷を蒔く行為だ。システムの更新の時に、バイナリの入れ換えを忘れたり、一見して呼ばれているプログラムが分からないのは、後々の混乱の元になる。

現在予定している手順は以下の通り。

  1. スクリプト内の rsh/rcp の記述を全て、ssh/scp に置き換える。
  2. rsh のバイナリを ssh を差すシンボリックリンクにする。

一度、試験環境で実験してからの、移行になる。少し落ち着いてからになると思う。

geli を使うと書き込みの方が早い2008年10月13日 04時12分56秒

FreeBSD で geli を使い、ディスクを暗号化して使っている。暗号化しているので、ディスクのパフォーマンスに付いてはある程度は諦めている。

幾つかのデバイスを暗号化して使っているが、デフォルトの AES の 128 bit 鍵で使っている。


cryptosoft0: <software crypto> on motherboard
GEOM_ELI: Encryption: AES-CBC 128
GEOM_ELI:     Crypto: software

systat で眺めていると、大きなファイルなどをコピーする時などの、連続的にディスクにアクセスする時に、書き込みが読み出しよりも二倍ほど早い。また、systat によるディスクの読み出し時の占有率は、50% になっている。gstat で、.gli デバイスを見ると、100% になっているので、復号化の方が負荷が高いと言うことなのだろう。

バックアップから復元する時に、異常にディスクの利用率が低かったので気が付いた。

geli のデータ整合が恐くなった2008年10月05日 16時45分23秒

ディスクを間違って初期化してしまったので構築し直す必要があった。折角の機械なので、geli の比較的新しい機能を使ってみることにした。geli でデータの整合性の点検をすることが出来る。

geli init -a を行なった時点から、ディスクから読み出されるデータがチェックサムと合うか検証される。その為、少なくとも先頭領域を dd で削除しないと、newfs が出来ない。恐らく数十 MB ぐらいをゼロ書き込みするのが手っ取り早い。その後の newfs 自身が、newfs が使うブロックを初期化するので、全てのディスクをゼロ書き込みする必要は無いと思われる。UFS のバージョン 2 は遅延初期化をするので、必要の無いブロックにはすぐには書き込まない。

softupdate を有効にして、このディスクに rsync で書き込みを行なっていた。バックアップディスクが微妙に不安定で、運悪く panic を起こしてしまったようだ。

その後、この新しく整合性の点検を入れたディスクの fsck を行なった。書き込みの最中に止まったので、ファイルシステムは否が応にも不整合が起きている。しかし、今回はそれだけでなく、geli のレベルでも問題があった。チェックサムが合わなくなっていた。そして、geli dmesg に問題があるのを報告し、ゼロクリアされたデータを返している様だった。そして fsck はファイルシステムを修正しようとする。しかし、大量の意図しない結果が返ってきているようだった。そして、このファイルは存在しない、あのファイルは存在しないと言い出し、大量のファイルの削除を試み始めた。

どうも、home 以下の重要なディレクトリを更新している最中に、システムが止まり、home の i-node の書き込みが一番中途半端な所で終わってしまった様だ。softupdate は新しい home の内容を指すブロックを作る。そして、home の i-node を更新する。この書き込みが行なわれている間に、失敗したようだ。

整合性の点検が無い場合は、home の i-node は新しいブロックか古いブロックのどちらかを指している。その為、存在していたディレクトリは少なくとも、どちらの場合もそのまま残っている。今回は、この i-node 更新中のブロックのチェックサムが壊れた様だ。fsck が home を点検している時に、uyota など無いと言われた。その後、uyota 以下のファイルを参照している i-node が無いと、削除を始めた。

この一件で、整合性の点検を有効にした geli が恐くなったので、使うのを止めた。大量にファイルが消えたのは偶然かも知れないが、一回目の fsck で、ファイルが消えるような状況にでくわすと出会すと不安になる。