SSHdサーバの冗長化を実現するためのサーバ側公開鍵構築

先日、客先でSFTPのサーバがあり、これに対して送信した処理がエラーになったというトラブルがあった。
原因は、ロードバランサーによるホットスタンバイに切り替わった時、以前接続したときに取得したサーバ側公開鍵
(~/.ssh/known_hosts)と違っていたからだという事が判明。

先方の担当者からはどのようにして改善してよいのか分からないので、SSHクライアントのほうでオプションを付け加え、サーバの公開鍵チェックを外してほしいという事だった。

例:クライアント側でサーバのホストキーチェックをしないオプションや設定
SSHでknown_hostsをの警告無視する設定はどうなるか?

しかし、これをサーバの設定に入れてしまう(/etc/ssh_config)と他全ての構築ポリシーに影響してしまうし、かといって接続プログラムのほうの修正だと、接続先ごとにオプションを管理するカラムを追加しなくてはいけない。

そもそも、ホットスタンバイの冗長化ができていないサーバに合わせて構築するシステムなんて本末転倒と言わざるを得ない。なので、サーバ側の公開鍵を共通化することで問題の解決をしてほしいという示唆をすることにした。

それに当たって、参考になる構築記事はないかと探したのだが、「SSHサーバ 冗長化」とかでも出ないし、「ssh_host_rsa_key 冗長化」(ファイル名を知らないと探せない単語だけどピンポイントで探せるはず)でも出てこない。

こういったやり方は一般的ではないかもしれないが、こういったハードルを下げていかないとSFTPの導入は進まないし、いつまでたってもFTPサーバのシステムがそのままになって、攻撃対象になるので書いていきたいと思う。

■対象ファイルやディレクトリの調査

※今回の対象はRedhat系のOS
/etc/ssh/ 同期対象ディレクトリ

-rw-------   1 root root 123K Jun 22 23:20 moduli
-rw-r--r--   1 root root 2.0K Jun 22 23:20 ssh_config
-rw-------   1 root root  672 Apr 26  2012 ssh_host_dsa_key
-rw-r--r--   1 root root  590 Apr 26  2012 ssh_host_dsa_key.pub
-rw-------   1 root root  963 Apr 26  2012 ssh_host_key
-rw-r--r--   1 root root  627 Apr 26  2012 ssh_host_key.pub
-rw-------   1 root root 1.7K Apr 26  2012 ssh_host_rsa_key
-rw-r--r--   1 root root  382 Apr 26  2012 ssh_host_rsa_key.pub
-rw-------   1 root root 3.8K Apr 26  2012 sshd_config



moduli                  係数
ssh_config              SSHクライアントの設定
ssh_host_dsa_key        SSH2サーバホスト秘密鍵
ssh_host_dsa_key.pub    SSH2サーバホスト公開鍵
ssh_host_key            SSH1サーバホスト秘密鍵
ssh_host_key.pub        SSH1サーバホスト公開鍵
ssh_host_rsa_key        SSH2サーバホスト秘密鍵 (通常使用)
ssh_host_rsa_key.pub    SSH2サーバホスト公開鍵 (通常使用)
sshd_config


■同期コマンド

※前提としてバックアップサーバにて実行

# rsync -az [masterサーバのIP]:/etc/ssh/ /etc/ssh/
# service sshd restart


これ以上は書く必要がないぐらい、これで冗長化されたSSHサーバの出来上がり。

■追加調査

どうしてこんなことをしなくてはいけないのか?という疑問が出たりすると思うので、追加調査。
まず、moduli。これは何かというと、ssh-keygenとかの元みたい。
http://man.he.net/man5/moduli
次に、「ssh_host_rsa_key.pub」これが今回の肝だったわけだけれど、意外にこのSSHの認証でサーバ側のキーが同名ているのか、何に使われるのか知らない人のほうが多いというか、解説している記事が少ないように感じた。

http://www.turbolinux.co.jp/products/server/11s/user_guide/sshconnect.html
たぶんこのページの図が一番わかりやすいと思う。
成りすましを防ぐために行っているという事がわかるかなと。公開鍵は取得できても、秘密鍵が取得できないので成りすましサーバを立てるのは困難だから。

DSAとRSAがあって、なぜRSAだけ?という疑問が出るかもしれないけれど、SSHクライアントの設定のデフォルトは上記のページに「HostKeyAlgorithms ssh-dss,ssh-rsa」の説明箇所があって、デフォルトがRSAの場合が多いから。