クラスタシステムとssh

　ちょっと番外編。
　heartbeat等でクラスタシステムを構築した場合に、1点問題になることがある。それは「ssh」。

　クラスタを構成する各ノードを指定してsshやslogin等を実行する場合は通常のサーバに対するものとなんら変わることが無いが、クラスタのVIPに対してアクセスしようとすると、クラスタの稼動系が切り替わったタイミングで…

[root@chiaki .ssh]# ssh nfscl01 uname -a
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
90:82:**:**:**:**:**:**:**:d1:56:72:61:05:b2:8b.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:5
RSA host key for nfscl01 has changed and you have requested strict checking.
Host key verification failed.

　こんな感じの（もっと違うメッセージになることもある）エラーになって困ってしまう。

　これは、クラスタシステムに組み込まれているsshのキーペアがノードによって異なるために生じる問題だからだ。
　上記の例（このblogでheartbeatの解説をしている環境）では、

　　・nfs001　…　クラスタに参加しているノード　その１
　　・nfs002　…　クラスタに参加しているノード　その２
　　・nfscl01　…　クラスタシステムに割り当ててあるVIP（必ず稼動しているほうのサーバにアクセスできるアドレス）

　ということになっているが、

Node: nfs002.mycompany.com (6a838508-67eb-47f3-9a46-72e755b88326): online
Node: nfs001.mycompany.com (47e72b74-c47c-426f-8dc4-18077e2dcd57): online

Resource Group: nfs_service
    ipaddr      (heartbeat::ocf:IPaddr):        Started nfs001.mycompany.com

　という状態であれば、nfscl01というアドレスでアクセスできる先のサーバは「nfs001.mycompany.com」であるが、

Node: nfs002.mycompany.com (6a838508-67eb-47f3-9a46-72e755b88326): online
Node: nfs001.mycompany.com (47e72b74-c47c-426f-8dc4-18077e2dcd57): online

Resource Group: nfs_service
    ipaddr      (heartbeat::ocf:IPaddr):        Started nfs002.mycompany.com

　という状態であれば、nfscl01というアドレスでアクセスできる先のサーバは「nfs002.mycompany.com」になってしまうのである。

　クライアントからサーバにアクセスしたときに提示されるサーバの公開鍵が、「nfs001.mycompany.com」のものだったり、「nfs002.mycompany.com」のものだったりするから困った事態になってしまうのである。

　そこで、解決方法の一つとしてよく用いられるのが、サーバ側のキーペアファイルを「nfs001.mycompany.com」と「nfs002.mycompany.com」とで同じものを用いてしまおうというもの。セキュリティ的にどうなの？という指摘があるかもしれないが、その辺はそういうことに詳しい人にお任せするとして、ここではこの方法でエラーを回避する方法を紹介する。

---

　まず、手順は以下の通り。
①：片方のサーバのキーペアファイルを稼動系サーバからコピーして上書きする
②：サーバにアクセスするクライアントの「known_hosts」ファイルから、VIPに対するキーの記述されている行と、キーペアファイルをコピーして上書きしたクラスタノードの行を削除する
③：クラスタのVIPと、待機系サーバに対してsshあるいはsloginなどを実行する。

---

①：片方のサーバのキーペアファイルを稼動系サーバからコピーして上書きする
　まず、サーバ側のキーペアファイルを統一する作業を行う。

　サーバのsshキーペアファイルは、通常は/etc/ssh配下に保存されている。

[root@nfs001 ~]# cd /etc/ssh
[root@nfs001 ssh]# ls -la
合計 184
drwxr-xr-x  2 root root   4096  2月  9 12:36 .
drwxr-xr-x 81 root root   4096  3月 18 04:02 ..
-rw-------  1 root root 132839  9月 13  2010 moduli
-rw-r--r--  1 root root   1827  9月 13  2010 ssh_config
-rw-------  1 root root    672  2月 28 14:22 ssh_host_dsa_key
-rw-r--r--  1 root root    590  2月 28 14:22 ssh_host_dsa_key.pub
-rw-------  1 root root    963  2月 28 14:22 ssh_host_key
-rw-r--r--  1 root root    627  2月 28 14:22 ssh_host_key.pub
-rw-------  1 root root   1675  2月 28 14:22 ssh_host_rsa_key
-rw-r--r--  1 root root    382  2月 28 14:22 ssh_host_rsa_key.pub
-rw-------  1 root root   3323  9月 13  2010 sshd_config

　このうちの、「ssh_host_*」の６ファイル（場合によっては４ファイルだったり、８ファイルだったりすることもあるが、その場合はそれら４ファイルまたは８ファイルの全てが対象となる。以下同じ）を、もう一方のクラスタノードからコピーしてきて上書きしてしまう。
　ここでは、nfs002が稼動系でnfs001が待機系になっているので、nfs002 → nfs001とコピーすることにする。

　scp -p nfs002:'/etc/ssh/ssh_host*' /etc/ssh/

　これでキーペアファイルが上書きされる。なお、秘密鍵ファイルの（拡張子「.pub」が付いていない）ほうはパーミッションが600でなければならないので、必ずチェックするように。

　そしたらsshdを一旦再起動する。

　service sshd restart

　これでサーバ側のキーペアファイルが更新された。

---

②：サーバにアクセスするクライアントの「known_hosts」ファイルから、VIPに対するキーの記述されている行と、キーペアファイルをコピーして上書きしたクラスタノードの行を削除する

　さて。この状態だと、クライアントから見たらサーバの公開鍵が変更されているので、known_hostsに保存されている情報と食い違うこととなり、sshがエラーを返すようになってしまう。そこで、known_hostsから該当するサーバの情報を削除しなければならない。

　known_hostsは、ログインディレクトリの下に「.ssh」というディレクトリが作成され、その中に保存されている。rootユーザーなら　/root/.ssh/known_hosts　だし、piro791というユーザーなら、おそらく　/home/piro791/.ssh/known_hosts　であるはずだ。

　known_hostsがデカすぎて探すのが面倒なときは、わざとエラーを発生させて、そのメッセージの中から行数を取得するのがいい。（笑）例えば、このアーティクルの冒頭で紹介したsshのエラーだったら、

Offending key in /root/.ssh/known_hosts:5

　というように出ているので、「/root/.ssh/known_hosts」の5行目にその削除すべき行があることがわかる。これを削除すればよい。なお、サーバが複数のNICを持っていたり、Aliasアドレスを持っている場合は複数の行が記録されていることも考えられるので、それら全てを削除するように。

---

③：クラスタのVIPと、待機系サーバに対してsshあるいはsloginなどを実行する。

　で、新しい公開鍵情報をknown_hostsに書き込む必要があるが、これはsshコマンドにやらせるのが面倒無いだろう。（コピー元になったサーバの行をコピーして編集してもいいけどね…）

[root@chiaki .ssh]# ssh nfs001 uname -a
The authenticity of host 'nfs001 (172.16.40.101)' can't be established.
RSA key fingerprint is 90:82:**:**:**:**:**:**:**:d1:56:72:61:05:b2:8b.
Are you sure you want to continue connecting (yes/no)? 

　こんな具合に、known_hostsに公開鍵情報を書き足してもいい？と質問してくるので、「yes」と答えればOK。

[root@chiaki .ssh]# ssh nfs001 uname -a
The authenticity of host 'nfs001 (172.16.40.101)' can't be established.
RSA key fingerprint is 90:82:**:**:**:**:**:**:**:d1:56:72:61:05:b2:8b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'nfs001,172.16.40.101' (RSA) to the list of known hosts.
Linux nfs001.mycompany.com 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

　こんな具合に公開鍵が保存される。鍵交換が済んでいてパスワードなしでログインできるようになっていれば、これ以降のsshアクセスなら…

[root@chiaki .ssh]# ssh nfs001 netstat -in
Kernel Interface table
Iface       MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth1       1500   0    33452      0      0      0    33410      0      0      0 BMRU
eth2       1500   0    33540      0      0      0    33497      0      0      0 BMRU
eth4       1500   0   986955      0      0      0     2141      0      0      0 BMRU
lo        16436   0    39845      0      0      0    39845      0      0      0 LRU

　こんな風に改めて鍵交換をするまでも無くパスワードなしでアクセスすることが可能だ。