sshfsは便利だ。リモートのファイルシステムをローカルのファイルシステムにマウントして扱うことができる。これにより、ローカル側のGUIのファイルシステムビューワーやエディターを使った温かみののある手作業による管理ができる。
ところで、Ubuntu Serverではrootが無効化されている。そのため、sshfs root@host:remote_path local_path はできない。代わりに、root権限が必要な操作はsudoを使って行う。しかし、sshfsではsudoができない。一体どうすればいいのだろうか。
試していないが、調べたところ、sftp_serverを指定する方法で行けるようだ。
まず、sudoのcredentialをキャッシュさせるために、ssh軽油でsudo -vを実行しておく。
そして、以下のようにsshfsでsftp-serverを指定する。
sshfs user@host:remote_path local_path -o sftp_server="/usr/bin/sudo /path-to/sftp-server"
おそらく行けるはずである。
少くとも最近のdebianではsudoのcredential cacheはtty毎に分離されてるのでそれだと上手くいかないと思いますがubuntuだと大丈夫なんですかね？
ReplyDeletesudoersでtty_ticketsを無効化すればtty毎ではなくなるようですが
こんにちわ、いつも勉強というか拝聴させてもらっております。
ReplyDelete実は私、日本語の人工知能の研究を専門というほどでは無いのですがしてまして。
文章最後2行目の軽油の部分は経由の間違いであってるでしょうか？
前後の文章からだとそのように推測してしまうのですが、
江添さんの事だから万が一思惑があるのかなぁ、と思ってしまった次第です。
冗長な文章になってしまって申し訳ありません。
こういうふうに設定の複雑度を上げるよりは、
ReplyDeletesshd_config で、PasswordAuthentication と ChallengeResponseAuthentication を no にした上で、
PermitRootLogin yes に変更して運用した方が、むしろ安全になる気がする。
PermitRootLogin no がデフォルトなのは、パスワードが破られたり、sshd に未知の穴があるケースを想定しているからの筈。
そして、そういう想定が成立している場合、sudo の結果が長時間キャッシュされていたら、結局、root 権限は破られてしまうわけで、なんか本末転倒に設定を複雑化しているだけのような。
sshd に未知の穴があるケースはもう仕方ないので、パスワード認証を禁止して root ログインを有効にした方がむしろ安全だと思う。
※ root ログインを禁止する理由には、監査目的で、sudo するユーザーをログに残したいというケースもあるので、そういう目的がある場合にはまた話が別。ただし、今回は管理者はたぶん一人だよね？
あと ChallengeResponseAuthentication は時々名前に騙されている人を見るけど、実態は keyboard interactive authentication のことなので、パスワード認証を禁止するなら、no に変更すべき。
なるほど。
ReplyDelete