openssh 3.7.1p2 chroot のインストール

〜パスワードログインとパスワード変更〜

2003-12-16 作成福島

2005-09-23 更新福島

2005-10-10 更新福島

・openssh-chroot のインストール

特権分離ユーザ sshd の作成

$ su
# mkdir /var/empty
# chown root:sys /var/empty
# chmod 755 /var/empty
# groupadd sshd
# useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd
# exit

コンパイル＆インストール

$ tar xzf openssh-3.7.1p2-chroot.tar.gz
$ cd openssh-3.7.1p2-chroot
openssh-3.7.1p2-chroot$ ./configure --with-tcp-wrappers --with-pam
openssh-3.7.1p2-chroot$ ./configure --prefix=/usr/local/ssh-chroot --with-tcp-wrappers --with-pam 違うところへまとめてインストールする場合
openssh-3.7.1p2-chroot$ make
openssh-3.7.1p2-chroot$ su
openssh-3.7.1p2-chroot# make install
openssh-3.7.1p2-chroot# cp -p contrib/redhat/sshd.pam /etc/pam.d/sshd

あとは普通のインストールと同様。

・例 user01 のルートを /home/user01 にする場合

$ su
# vipw

wu-ftpd と同様にルートを指定します。
user01:x:500:500::/home/user01/./:/bin/bash

# cp -pr /etc /home/user01/. 乱暴だけど、各ディレクトリツリーをそのままコピー
# cp -pr /dev /home/user01/.
# cp -pr /bin /home/user01/.
# cp -pr /usr /home/user01/.
# cp -pr /lib /home/user01/.

# mkdir -p /home/user01/var/log 各作業ディレクトリを作成
# mkdir -p /home/user01/var/spool
# mkdir -p /home/user01/var/tmp
# mkdir -p /home/user01/tmp
# chmod a+rwxt /home/user01/var/tmp
# chmod a+rwxt /home/user01/tmp

# mkdir -p /home/user01/boot df のエラーがうるさいのでディレクトリを作成
# mkdir -p /home/user01/proc/bus/usb

・困ったときのコマンド
# chroot /home/user01 実際に chroot して様子を見る
# ldd /home/user01/bin/* chroot したあとの /bin/* が正常に lib とリンクできるか確認する

パスワード変更に対処

chroot することでセキュリティが保たれ、非常に便利なのですが、自分でパスワードを変更できないという弊害があります。

/usr/bin/passwd コマンドを実行しても、変更されるのは /home/usr01/etc/shadow ばかりで、本当の /etc/shadow に変化が無いのでパスワード変更は空回りします。

chroot された環境から /usr/bin/passwd コマンドを実行したい理由には、以下に挙げる背景があります。

せっかく便利な環境を作成しても、管理者が些細な問題に関わるのは良くない。
管理者なら当然 /etc/shadow を変更できるが、パスワード管理はユーザに任せたい。
/etc/shadow にハードリンクを張るのは危険すぎるし、
LDAP を導入すると解決できますが、大げさすぎるので避けたい。

私はこれを解決するために chpassd (chpassd.c)という名前のデーモンを作成しました。
ローカルポートの 33 (TELNET が 23 なので 33 にしました) で接続を受けると認証を行い、その後に /usr/bin/passwd コマンドを起動するというデーモンです。

chpassd は chroot する前のサーバプログラムなので、chroot したあとの環境から元の環境にアクセスすることが出来ます。

実行例

$ telnet localhost 33
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
login: user01 自分のログイン ID を入力
password: ******** 現在のパスワードを入力 (実際は表示無し)
Changing password for user user01.
Changing password for user01
(current) UNIX password: ******** 現在のパスワードを入力
New password: ******** 新しいパスワードを入力
Retype new password: ******** もう一度新しいパスワードを入力
passwd: all authentication tokens updated successfully.
Connection closed by foreign host.
$

実行例を見れば分りますが、他人のパスワードを知っていれば、その人のパスワードも変更できてしまいます。

GCC 3.2.2 で i386 用にコンパイルしたバイナリをココに置きます。

使い方は、好きなところにコピーして xinetd から起動するだけです。
下記は chpassd を /usr/local/sbin/ に置いた場合の設定例です。
/etc とあるのは、当然 /home/usr01/etc ではなく、/etc のことです。

/etc/services

chpassd         33/tcp

/etc/xinetd.d/chpassd

service chpassd
{
	flags           = REUSE
	socket_type     = stream
	wait            = no
	user            = root
	server          = /usr/local/sbin/chpassd
	disable         = no
}

/etc/hosts.allow

chpassd:        LOCAL

# service xinetd restart

公開鍵ログインを使わない理由

他所様では公開鍵ログインを推奨していますが、ここでは信じられないことにパスワードログインを推奨しています。

公開鍵ログインを否定しているわけではありません。
両方を併用すれば良いと思います。

パスワードログインを推奨する理由は以下です。

最初にログインする端末にはパスワードログインが必要
複数人で使用する端末のセキュリティを確保するのは困難です
(隔離・施錠された環境からの接続なら公開鍵ログインを行ってください)
初心者に公開鍵を理解させるには無理がある
ユーザが少ないうちは管理者が全ての端末を設定できますが、数には限界があるし、その端末が個人所有の場合、管理権限を他人が持つことになりかねません。
CGI を利用できるプロバイダはほとんどがパスワードログイン
これも初心者の条件と重なりますが、一般的な環境に近づけることにより、シェル操作のハードルを低くできます

このとおり、技術的な問題ではありません。人的な問題です。
コンピュータネットワークが一般に浸透してきたのは良いことですが、その反面、技術者としてのレベルや環境を高く保てないのが現状です。

そういう人たちにこそ chroot 環境が必要と考えます。