これってOpenstack熟練者には基本的な事なのでしょうか。。
ちなみに、Centos6以外でも通用する技のはず。
OpenStackのCentOSのqcow2イメージのroot奪還計画！
です！
OpenStackのCentOSのqcow2というのは、以下のサイトから取得できるイメージです。
このイメージをOpenStackのイメージに登録する事で、気軽にCentOSを利用する事が出来ます。イメージに登録した後にインスタンスを起動するだけでOK。非常に簡単。
でも、一つだけ、困った事があります。
このイメージはデフォルトで「非ルート」になるように設定されています。
これは、OpenStackのイメージで一般的な措置のようです。つまり、非ルートにして、OSのハードニングをしている訳。
で、OpenStackのインスタンス起動時に、自分の公開鍵をつっこんで、通常は一般ユーザー(centosとか）でログインする。そして、必要に応じてsudoで操作する。AWSのAMIでも同じですね。
でも、自分の好きなようにカスタマイズしたい場合、どうしてもrootが欲しい事があります。非ルートにするとか、細かいセキュリティ上のハードニングは、自分がカスタマイズした後にやりたい。
多分同じ事を考えている人は多いはず。
以前はインスタンス起動時にスクリプトを追加する事で対応しました。
今回はguestfishというモジュールでcloud.cfgを修正する方法を紹介します。まぁ、これでも非ルート奪還できなかったってのが今回の趣旨なのですが・・・あ、解決はしましたよ。
guestfishは簡単！
本当に簡単です。
正直、私が前回の方法でのroot取得を考えていたのは
「guestfishって何か、なんとなく、聞くだけで難しそう・・・」
と思ってたからです。
でも、本当に簡単です！なので、こっちの方がお勧めです。
guestfishとは？
端的に言うと「イメージファイルの中身を簡単に編集できるソフト」です。
これがあればLinuxからqcow2イメージの中を操作できるのです。
実際にやり方を含めて紹介します。
guestfishを実際に利用する
まず、guestfishをyumでインストールします。インストールする環境は別にOpenStackと関係ないどこでもいいのですが、OpenStackのホストOSをお勧めします。理由は後述。
yum -y install guestfish
次に、libguestfs-toolsをインストールします。でも、これはOpenStackが入っていたら追加インストールが不要なはず。
yum -y install libguestfs-tools
これで準備が整いました。あ、当然ですが、guestfishを入れた環境に、いじりたいqcow2イメージを転送しておきます。
では、guestfishを利用して、qcow2イメージの中に入りましょう。
guestfish -a CentOS-6-x86_64-GenericCloud.qcow2
上のように最後に編集するqcow2を指定します。
その後、以下の通り入力し、guestfish内にqcow2イメージ内のデバイスをマウントします。
(100%・・・という箇所は、表示上の箇所です）
><fs> run 100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ --:-- ><fs> mount /dev/sda1 /
あとは、普通のLinuxと同様にviとかでファイルの編集が出来ます。
/etc/shadowの修正・・・まだダメ
ここからが本番です。
まずは、/etc/shadowのrootパスワードを変更してみました。ちなみに、修正後はquitでguestfishを抜ければOK。
これで大丈夫だろうと軽く見ていましたが・・・
変更したイメージでもrootでログインできません・・・
/etc/passwdの修正・・・まだダメ
次に、/etc/passwdでパスワードなしでログインできるようにしてみました。
・・・まだrootでログインできません。
cloud.cfgの設定変更で今度こそ！・・・ダメ
ここで「あぁ、またcloud.cfgか・・・」と思い出しました。
AWSやOpenStackのイメージは、何度もデプロイする事を想定して「ホスト名の変更」「公開鍵の挿入」など、汎用的な操作を導入直後に自動化するcloud-configが入っています。
細かい話は省きますが、この挙動の中に「ルートアカウントのロック」というのも入っています。
具体的には/etc/cloud/cloud.cfgの中の以下の箇所です。（初めの方）
disable_root: 1 ssh_pwauth: 0
上を以下のように変更します。
disable_root: 0 ssh_pwauth: 1
これでrootがenableになるはず。そして、sshをパスワードでログインできるはず。
ちなみに、ネットでググってみても、基本的にこれでログインできるはずとのことでした。
・・・でもrootでログインできない！！
あーーーもう！
ラスボスは「S99local」だった
何度やってもうまくいかない・・・cloud.cfgは正しい（ルートがenableになる）はず。。
・・・ふと思って、cloud-config自体を停止してブートしてみました。
・・・・これでもログインできない！
ということは、、cloud-configの「後に」起動されるサービスで何かやってるのか？
とうことで、参考までにrc3.d付近を見てみました。
><fs> cd /etc/rc3.d/ /etc/rc3.d/K10saslauthd /etc/rc3.d/K95cgconfig /etc/rc3.d/S12rsyslog /etc/rc3.d/S50kdump /etc/rc3.d/S90crond /etc/rc3.d/K61nfs-rdma /etc/rc3.d/K95rdma /etc/rc3.d/S15mdmonitor /etc/rc3.d/S51cloud-init /etc/rc3.d/S99local /etc/rc3.d/K86cgred /etc/rc3.d/S08ip6tables /etc/rc3.d/S25netfs /etc/rc3.d/S52cloud-config /etc/rc3.d/K87restorecond /etc/rc3.d/S08iptables /etc/rc3.d/S26acpid /etc/rc3.d/S53cloud-final /etc/rc3.d/K89netconsole /etc/rc3.d/S10network /etc/rc3.d/S26udev-post /etc/rc3.d/S55sshd /etc/rc3.d/K89rdisc /etc/rc3.d/S11auditd /etc/rc3.d/S50cloud-init-local /etc/rc3.d/S80postfix
cloud-config周りは51/52/53ら辺で起動されているのが分ります。
ということは・・・55のsshd？crond？いやいや
・・・99localがあやしい。
中を見てみました。（実態はシンボリックリンク）
# set a random pass on first boot if [ -f /root/firstrun ]; then dd if=/dev/urandom count=50|md5sum|passwd --stdin root passwd -l root rm /root/firstrun fi if [ ! -d /root/.ssh ]; then mkdir -m 0700 -p /root/.ssh restorecon /root/.ssh fi
こ・れ・だ。
てな訳で、これ以上面倒くさいので、中身を全部消したイメージをロードしたところ・・・
無事rootでログインが出来ました！
結論、CentOS6イメージは99localの修正が必要
このネタ、USのサイト含めてググっただけでは見つかりませんでした。こんな所でLinuxスキルが役立つとは・・
CentOS7はこんな操作はなかった気がするのですが・・
これって、Linux詳しい人には常識なのでしょうか。
ていうか、cloud-configを含めて色んな所で非ルートにする設定が入っているのって意味があるのでしょうか。。
とりあえず解決しましたが、非常に疲れました・・
コメント