他のホストで、いちいちパスワードを打つのが面倒になったので公開鍵認証することにした。
とりあえず、~/.ssh/authorized_keys
に自分の公開鍵を記述する。今回はファイル自体が無かったので、vim を使ってファイル作成とそこへ公開鍵を書いた。これで繋がるはずなので、接続時にペアの秘密鍵を使うようにして接続したところ“Server refused our key”と言われてしまった。
原因がよく分からず、とりあえず /etc/ssh/sshd_config なども弄ってみるが効果無し。諦めかけていたが、ssh にてパスワードを使用しないでログインする方法に原因が書いてあった……。
.ssh/authorized_keys(2) のパーミッションは、所有者に対しては read/write を許可し、 他のユーザーには、アクセスを許可しないで下さい。同ファイルに至るディレクトリの パーミッションにも注意して下さい。ユーザー以外に write を許可してはいけません。 パーミッションが正しく設定されていないと、パスワードを要求されてしまいます。
ssh にてパスワードを使用しないでログインする方法
よく見るとパーミッションは 664 になっていた。と、Redhat 系ディストリビューションのホストということを思い出し、umask が標準で 0002 なのだ。umask はファイルやディレクトリを作成するときのパーミッションを決定する際のビットマスク。例えばファイルを作成するときは 0666 のパーミッションに umask = 0002 の否定して積をとる。つまり 0666 & ^0002 = 0666 & 7775 = 0664 となる。
Debian 系など他のディストリビューションであれば、恐らく umask は 0022 が標準である。というのも、Redhat 系は User Private Group (UPG) というユーザ管理ポリシーを用いており、複数人のプロジェクトを運用する際に少し幸せになれる。
- ユーザを追加したら初期グループはユーザ名と同じグループに所属する
- ユーザ名と同じグループには、そのユーザしか所属しない
- この時点で umask が 0022, 0002 のいずれもファイルは保護される
- 複数人で編集する必要のあるファイル・フォルダには、複数人をまとめたグループ(例えば team-a)を所有グループにする
- ディレクトリを作るときに setgid しておく(管理者の仕事)
- ファイル・ディレクトリを作ると自動的に所有グループが team-a になる
- もちろん新たにディレクトリを作ると、自動的に setgid してくれる
- 所有グループに対して書き込み権限がなければ、所有者でない人は編集できない
- umask が 0022 であると、作成する度に chmod g+w file する必要がある
- ここで umask は 0002 である方が有利になる
ちゃんと運用するには、作業ディレクトリに setgid をしておく。しなければ、作業ユーザのデフォルト所属グループが所有グループになってしまうため、所有者が chgrp(或いは chown)して所有グループを変更するしか、他のユーザが編集する手段が無くなる。逆に言えば setgid をしておくことで、そのディレクトリで作成したファイルはグループの他の人も編集できるようになるのだ。ユーザに「忘れずに chgrp して下さい」と言っても忘れてしまうことが多いので(管理者が setgid するのも忘れるでしょうが :-p)、setgid しておいた方が後の管理は楽でしょう。
この umask の設定は、自宅サーバの CentOS 5.0 で確認したところ /etc/bashrc に書かれていた。従って zsh や tcsh などをログインシェルにすると、umask 設定がされないため 0022 になる。ログインシェルを変更せずに zsh を起動すると、umask は 0002 になる。
公式パッケージを利用しているので、どうせなら /etc/zshrc にも同様の管理ポリシーを適用して欲しいな。root は bash しか使わせないだろうけど、普段 root を使うわけではないし、bash より zsh の方が使い勝手はよいだろう。個人利用ならともかく、プロジェクトを運用するには UPG ポリシーは良いと思う。
Related Entries
There is not related articles.
Trackbacks
Trackback URI: http://blog.c--v.net/trackback/2007/09/30/1
There is no trackback.
There is no comment.