もっとキーキャップを印刷した。

ミッチリつめて、レップリ片手分を一気にいってみた。 6時間ぐらいかかって、31g分の印刷。

keys weight

sshfsとautofsをセットアップした。

デスクトップと印刷用マシンを分けたので、その間で印刷するファイルを共有する必要がある。

FreeBSDのNASに、Debianのマシンを接続してファイルをやりとりしてる。

手作業でsshfsを使っていたんだけど、一旦サスペンドするとコネクションが切れるので、 gnukを入れてアンロックしてという手順が必要になるので、めんどうになった。そこで、ちょっと自動化したい。

鍵認証

gnukの代わりに、鍵ファイルをパスワードなしにしたものを使いたい。一方それだと危険なので、アクセスできるディレクトリを制限したい。

まず、そもそも、sshfsはどうやってファイルにアクセスしてるのかわからんので、調べたら、sftpを使っているみたい。

authorized_keysに何かうまく書いたら、ディレクトリを制限できるかなと思ったが、 sftp-serverにはそういうオプションはないようだ。 (読み込みオンリーオプションや、初期値ディレクトリだけ)

chrootしてsftp-serverを起動するプログラムを書けばいいんだと思うけど、そのプログラムにはroot権限がいるので、あんまりやりたくない。

しかたないので、新しいユーザーを作り、 /etc/ssh/sshd_configに、次のように書いて作った。

Match User sftp-user
       ChrootDirectory /tank/insecure-data
       X11Forwarding no
       AllowTcpForwarding no
       PermitTTY no
       ForceCommand internal-sftp

/tank以下には実行権限があるファイルは置けないようにしていて、 sftp-serverをここに配置する事はできない。どうしようかと思ったら、internal-sftpを設定すると、 sshd内蔵のsftpサーバーが使えるらしい。

この時に、chrootするディレクトリは、rootが所有して、他のユーザーが書き換えできないようにしないと駄目みたい。次のエラーがでる。

fatal: bad ownership or modes for chroot directory "/tank/insecure-data"

そもそも、何で一般ユーザーでchrootできないんだろう、 plan9とかならできるよなぁ、と思って、調べた感じだと、rootにsetuidしたプログラムに偽のファイルを見せる攻撃ができるから、が原因みたい。 chrootで偽の/etc/sudorsを用意してsudoに読ませるとかね。 setuidがないplan9ならこの問題はない。書き込み権限があるディレクトリにchrootするのが危険なのも同じかな。

autofs

パスフレーズの入力なしにsshfsできるようにしたので、 sshfsコマンドの実行を自動化したい。

今迄使った事なかったのだけど、こういうのはautofsでできるはずだ。

調べたところ、autofsは設定ファイルが2つあるみたい。まず、/etc/auto.masterにautofsを使う親ディレクトリと子の設定ファイルを設定して、子の設定ファイルで、親ディレクトリ内のどこに何をマウントするかを設定するみたい。

今回は次のようにした。

/etc/auto.master

/auto /etc/auto.ssh --timeout=60,--ghost

/etc/auto.ssh

insecure -fstype=fuse,rw,allow_other,IdentifyFile=/path/to/key,port=1234 :sshfs\#user@host\:

親と子に分かれてるのは、親のマウントポインを使って、アクセスを検知してるのかな？

–ghostはマウントしてないディレクトリが見えるようにするオプション、 allow_otherはroot以外のユーザーもマウントしたファイルシステムにアクセスできるように必要

まとめ

これでサスペンドから戻っても、共有ディレクトリにアクセスしたら、 sshfsが復活してシームレスに見れて便利。

他の方法として、unisonで自動syncしようかと思ったけど、衝突した時に自動で解決できなさそうで、パス。結局chrootも解決できないし。家の中だし重複してファイルを持たなくてもいいだろうし。全部ユーザー権限で済むのは魅力的なんだけど。