rsync+ssh（ホストベース認証）

今回の環境

今回の設定はFreeBSD6.1とCentOS4.4で行っています。
Linux系でもほぼ同じ方法でいけると思います。多分・・・・

rsync + sshにてバックアップを行う

自分だけは大丈夫だと思っていても、その日は突然やってきます「HD障害」・・・そのときになって焦っても後の祭りです。
重要だけど、面倒くさくてついついサボりがちな「バックアップ」も 一度自動化してしまえばあとは毎日パソコン君が汗水たらしながらバックアップをしてくれます。:-)

今回の条件

• rootでバックアップを実行(ユーザごとにバックアップの設定をするが面倒なので）
• 全部自動化させたい！！
• データのバックアップは暗号化でセキュリティを高めよう！！
• 複数ユーザのホームディレクトリ上にあるデータを取る

イメージ図
　Webサーバ　　　　　　　　　　　　　　　　　　バックアップサーバ
  +--------------------+                       +----------------------+
  | バックアップ元     |                       | バックアップ先       |
  | OS: FreeBSD 6.1    |    ------------ > 　  | OS: CentOS4.4        |
  | IP: 192.168.85.131 |                       | IP: 192.168.85.128   |
  | hostname: www      |( コンテンツのコピー ) | hostname: backup     |
  +--------------------+                       +----------------------+

実現方法

今回の条件をクリアするための方法として以下の方法をとることとします。

• セキュリティを考慮してsshで通信経路を暗号化
• データのバックアップはrsync
• バックアップの自動実行はcron

バックアップの方法はこの方法以外にも無数にあるのですが、今回この方式をとることとします。 （機会があったら他の方法も試して見たいと思います。）

ssh + rsync + cron の利点

なんでssh + rsync + cron なのかというと・・・

• rsyncは差分バックアップができる（バックアップ時間の短縮）
• rsyncデータのパーミッションやuid,gidなどの情報を保持できる。（リカバリーを考えると、これ重要です！！）
• sshで通信経路を暗号化することで、セキュリティがアップ
• cronで決まった時刻にバックアップを自動実行させれば、とり忘れの心配もなくなります

以上の点から、ssh + rsync + cronを選択しました。

ssh + rsync + cron の問題点

良いこともあれば問題となることもあります。主な問題点は

• FreeBSDではsshによるrootユーザログインが禁止されている（linuxではできるのもあります)
• sshのrootログインを許可すると、インターネットに接続しているサーバに直接rootログインを許可するのはセキュリティ上不安
• ssh接続時パスワードの入力を求めらる（完全自動化するには大きな問題）

以上の3点をクリアするために、設定変更行っていきます。。

前提条件

ssh + rsync + cron を実現させるため前提条件として、お互いのサーバで名前解決が出来るなければいけません。

私の環境ではDNSに名前解決が行われていませんでしたので、/etc/hostsへ以下の項目を追加しました。

192.168.85.128   backup
192.168.85.131   www

バックアップ元サーバ

sshのrootユーザログイン許可の危険性対策

rootでバックアップを行うには、sshでrootログインを許可させる必要があります。 しかし、ネットに公開しているサーバのSSHでrootログインを許可するのは気分がよろしくありません。 どうしたものか・・・

いろいろ考えた結果、外部より直接接続できない別ポートで待ち受けるバックアップ専用 sshdを起動させるという方法をとることにしました。
（インターネットに接続しているルータでは、www smtp pop sshのポートしか空けていません）
これで若干セキュリティ面が向上するかも・・・ :-) （NICに空きがあるならば、外部から直接接続できないバックアップ用のネットワーク作るとより安全でしょう。）

パスワード入力の省略

バックアップを完全自動化させるには、ssh接続時のパスワード入力を省略させなくてはいけません。
sshログイン時のパスワード入力を省略させる方法として私が知っているのは以下の2通りです。

• 公開鍵を使って認証
• ホストベース認証

公開鍵を使って認証

この方法は以前やったことがあるので、今回はパスします:-p
時間が出来て、気が向いたらこっちの方法の手順もまとめたいと思います。設定時のメモはあるんで・・・

ホストベース認証

ssh接続される側のsshdの設定でホストベース認証の許可設定と、ユーザの~/.shostsファイルに。 ホスト名とログインを許可するユーザ名を設定することでパスワードの入力を省略させることができます。

ただ、この方法だとセキュリティ的にないのですが、色々なことができるので使い勝手は非常に良いです。
(信頼しているホストが乗っ取られると、無条件にこちらにも進入を許してしまいます）

ということで、今回はホストベース認証を採用します。

作業項目

SSH設定　（バックアップ元）

• 別ポートで待ち受けるバックアップ専用設定の作成(ポート 10022 でssh接続を待ち受け)
• rootユーザのログインを許可
• バックアップサーバからホストベース認証でパスワードなしログインが出来る

10022ポート接続 + ホストベース認証　SSH設定

sshサーバの設定ファイルである、sshd_configをコピーし ホストベース認証および10022番ポートで待ち受けるsshd用のbackup_sshd_configというファイルを作成して編集します。

( ※ファイル名はbackup_sshd_configと決まっているわけではありませんので、任意の名前で良いです 今回は私が適当に決めただけです )

# cp -p /etc/ssh/sshd_config /etc/ssh/backup_sshd_config
# vi /etc/ssh/backup_sshd_config

Port 10022                          # ポート10022で待ち受け
PermitRootLogin yes                 # rootユーザログイン許可
RSAAuthentication no                # RSA認証を不許可
PubkeyAuthentication no             # 公開鍵認証を不許可
IgnoreRhosts no                     # .shosts .rhosts の使用を許可
RhostsRSAAuthentication no          # デフォルトでnoのはず
HostbasedAuthentication yes         # ホストベース認証を許可
PasswordAuthentication no           # パスワード認証を不許可
ChallengeResponseAuthentication no  # PAMチャレンジレスポンス認証を禁止

接続許可ホストの設定

接続を許可させるユーザのホームディレクトリに.shostsの設定を作成し、接続を許可させるホストとユーザを指定します。
今回はrootユーザにてバックアップを行いますので、/root/.shostsファイルを作成します。

# vi /root/.shosts

今回は以下のように設定しました。

パーミッションの変更

# chmod 600 /root/.shosts

10022番ポートsshd起動

10022番ポートsshd用に作成した設定ファイル(/etc/ssh/backup_sshd_config)を　-f　オプションで指定してsshdを起動させます。

# /usr/sbin/sshd -f /etc/ssh/backup_sshd_config

起動確認

正常に起動できているかどうか、sshでlocalhostの10022番ポートにログインしてみます。

# ssh -p 10022 localhost
Permission denied (hostbased).

10022番ポートにsshで接続出来てホストベース認証だとメッセージ返ってきていますので正常に sshdが起動していることを確認できます。

※Permission denied (hostbased).と表示されてログイン自体は出来ませんが、それはlocalhostからの接続の 許可を.shostsにて設定を行っていないためなので、今は問題ありません。

自動起動

毎回手動でsshdを起動させるのは面倒ですし、忘れてしまいそうなのでサーバ起動時に自動起動するように設定します。

FreeBSDの場合

/usr/local/etc/rc.d/ にsshd起動用のシェルを作成します。

# vi /usr/local/etc/rc.d/sshd_10022.sh

とりあえず動けばいいので、以下のようなスクリプトを作ります。

作成したシェルスクリプトに実行権限を与えて、スクリプトを実行できるようにします。

# chmod 755 /usr/local/etc/rc.d/sshd_10022.sh

これで、サーバ起動時にバックアップようのsshdが起動してくるはずです。

Linux系の自動起動

ホストキーの作成

バックアップ元サーバからバックアップ先サーバにSSHでログインすればOK

# ssh backup
The authenticity of host 'backup (192.168.85.128)' can't be established.
DSA key fingerprint is ae:59:22:52:4d:9d:97:6e:f9:d2:ca:1a:c8:44:3e:45.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'backup' (DSA) to the list of known hosts.

root@backup's password:
Permission denied, please try again.
root@backup's password:
Permission denied, please try again.
root@backup's password:
Permission denied (publickey,gssapi-with-mic,password).

ちなみに、上記のログではバックアップサーバにrootログインは出来ない設定になっているので rootでログインしようとして「Permission denied, please try again.」といってログイン出来ていませんが、 /root/.ssh/known_hostsにbackupサーバのホストキー情報が書き込まれていますので特に問題はありません。

ホストキーの内容

# cat /root/.ssh/known_hosts
backup ssh-dss AAAAB3NzaC1kc3MAAACBAIgFVw/FzXD+MOpprvIZCNNABna1aFR
fbCxKlAFRNJCN+2iV4KPYm0Lb3iU3TmfK9kaeSMRlnU2C9CgsUF/bZqrc00PdvGPTD
te9BkacF0BFdd6D8S7jjfeAJXb/RqgBOkeiN5l4MOB2HKNbwAyvxD1ytUsOFwLtSXL
MUF0rBh9DAAAAFQDZ4OHXrtSkZ+fFtVBKtlwIdzEeoQAAAIAq1tiYu/qVgxAEglZwJ
Wo6Ug9egqvtkjGa3FWFmFZQ/td5OxilHZpCjecXZdexzJ2bp2jSzlWcsm/WossuLoq
Ajp8ZUIc8UFBkdfX2RYMIvwn8gy0eoC7rHjhseOTZ63Th2Ydu05B5FOKyguCtODwlL
uY5ce1IEZnZ+YO3N1/tMQAAAIATSpYOEZh7gfuI1EjT1fvEj551Hw5+adH3kzMKBKO
HoXGEmBADNOyZ4NPmjX9LTIWp7ZQ7RXHO0Bt1hSz02/1oOckbnHACvzX1IQfaZlelx
2ctnaKoEFgYrtAOKykWC7rIIXR0NNRizXbdxxcBfzuYHXHn9ARLO3Jw6u5ga4789g==

ホストキーの情報は実際には1ホスト1行で記述されます。

SSH設定　（バックアップ先）

sshクライアント設定変更

バックアップ先からhostベース認証を使用して、バックアップ元に接続するにはsshクライアントの 設定ファイルである/etc/ssh/ssh_confiの設定変更が必要となります。

# vi /etc/ssh/ssh_config

以下の項目をssh_configに追加します。

HOST www
HostbasedAuthentication yes
PreferredAuthentications hostbased,publickey,password

sshへのsetuid

# chmod 4555 /usr/bin/ssh

# chmod 4511 /usr/libexec/ssh-keysign

sshで接続

sshクライアントの設定変更が完了しましたら、実際にssh接続を行ってみます。
sshでの接続がはじめて場合のみホストキー（DSA key）を登録するかの確認がありますので、yesと入力してホストキーの登録を行ってください。 一度登録すると、2度目以降は聞いてきません。

# ssh -p 10022 root@www
The authenticity of host 'www (192.168.85.131)' can't be established.
DSA key fingerprint is bb:92:0e:d8:15:92:bb:2d:2c:04:9e:f4:e2:fb:e7:e2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'www,192.168.85.131' (DSA) to the list of known hosts.
Last login: Thu Jan 25 17:36:40 2007 from vm-2
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.  All rights reserved.

FreeBSD 6.1-RELEASE (GENERIC) #0: Sun May  7 04:32:43 UTC 2006

Welcome to FreeBSD!

Before seeking technical support, please use the following resources:

o  Security advisories and updated errata information for all releases are
   at http://www.FreeBSD.org/releases/ - always consult the ERRATA section
   for your release first as it's updated frequently.

**********************    省略   *****************

www #
www # ifconfig lnc0
lnc0: flags=108843 mtu 1500
        inet6 fe80::20c:29ff:feec:9a92%lnc0 prefixlen 64 scopeid 0x1
        inet 192.168.85.131 netmask 0xffffff00 broadcast 192.168.85.255
        ether 00:0c:29:ec:9a:92
www # exit
logout
Connection to www closed.
#

パスワードの入力無しでログイン出来ることを確認してください。

注意

ホストベース認証を行う際には、/etc/hostsやDNSに互いの名前を登録しておいてください。名前解決ができないと、Permission denied (hostbased). とかいってエラーになります・・・
※私はここで2時間はまったです・・・

バックアップテスト

正常にバックアップされるか必ずテスト行って確認してください 設定間違い（転送方向を間違ったり）などがあると、最悪データが消えちゃうことがあります。 はじめはテストデータを作って、そのデータきちんとバックアップ先サーバに コピーできることを確認してから、本当のバックアップ用のrsyncコマンドを実行しましょう。

バックアップ元サーバ（wwwサーバ）

実際のデータをいきなりrsyncでデータ転送するのは怖いので、バックアップする前にテストデータを作成してrsyncによるバックアップテストを行ってみます。

バックアップテスト用データ作成

# touch /tmp/test

バックアップ先サーバ(バックアップサーバ)

バックアップディレクトリ作成

バックアップサーバにて、バックアップ元サーバよりコピーしてきたデータを保存するためのディレクトリを作成します。 フォルダは任意の場所に自由に作成してもらって良いのですが、今回は分りやすく /backup という ディレクトリを作成します。

# mkdir /backup

データ転送テスト

バックアップ元サーバに作成したテストデータ（/tmp/test)を/backup転送します。

# rsync -au -e  "ssh -p 10022" www:/tmp/test /backup
# ls -la /backup/
合計 12
drwxr-xr-x   2 root root 4096  1月 14 17:03 .
drwxr-xr-x  25 root root 4096  1月 14 16:57 ..
-rw-r--r--   1 root root    0  1月 29  2007 test

データが転送されていることを確認します。

# ls -la /backup

バックアップ設定

データ転送のテストも問題なく完了しましたら、いよいよ実際のデータのバックアップを行います。 初回は実行時は、全てのデータを転送するので時間が掛かると思いますが、2回目以降は差分バックアップを行いますので それほど時間は掛からないと思います。

バックアップサーバにて rsync の実行

バックアップデータにディレクトリを指定する場合は、必ず最後に/(スラッシュ)をつけましょう。
/(スラッシュ）がついている場合とついていない場合では、動作が違いますので注意してください。

# rsync -au -e  "ssh -p 10022" www:/home/tamohiko/public_html/ /backup/tamohiko/public_html

バックアップデータの確認

無事バックアップが取れたか確認してみます。

# ls -lR /backup/tamohiko/
/backup/tamohiko/:
合計 4
drwxr-xr-x  3 1002 1002 4096  1月 29  2007 public_html

/backup/tamohiko/public_html:
合計 8
drwxr-xr-x  2 1002 1002 4096  1月 29  2007 data
-rw-r--r--  1 1002 1002   91  1月 29  2007 index.html

/backup/tamohiko/public_html/data:
合計 4
-rw-r--r--  1 1002 1002 11  1月 29  2007 dummy

無事取れていました:-)

バックアップの自動化

データ転送が完了しましたら、今度はrsyncによるバックアップをcronに登録して、バックアップを自動的に とってくる設定を行います。

cron設定(バックアップサーバ)

# crontab -e 

設定内容

とりあえず、毎時10分にバックアップを実行するように設定しました。

rsyncに --delete オプションをつけてバックアップ元(www)サーバ上で削除されたデータはバックアップ(backup)サーバでも削除されるようにしてみました。

--deleteオプションを使用すると、バックアップ元サーバで削除されたデータはバックアップサーバ側でも削除されて、コピー元とコピー先が完全に一致するようになります。--deleteを使用する場合は気を付けてください。
要は、コピー元サーバでファイルを消すと、次回のrsync時に「バックアップ先サーバのデータからもそのファイルが消えちゃうよ！！だから使用するときは注意してね」ということです。

10 * * * * root /usr/bin/rsync -au -e --delete "ssh -p 10022" www:/home/tamohiko/public_html/ /backup/tamoiko/public_html

後は勝手にバックアップがとれているはずです:-)

注意

rsyncでのバックアップはバックアップデータの世代管理は行いませんので、オペミスなどでデータを消去してしまった場合等の 障害には対応できませんので、そこのところは十分に注意願います。。

おまけ

CentOSでもバックアップsshdの自動起動設定を行ってみたので、その方法をメモしておきます。

起動スクリプトの作成

一からスクリプトを作るのは面倒なので、/etc/rc.d/init.d/ディレクトリにある、 通常のsshd起動スクリプトをコピーして作成することにします。

# cp -p /etc/rc.d/init.d/sshd /etc/rc.d/init.d/backup_sshd
# vi /etc/rc.d/init.d/backup_sshd

編集箇所

start()
{
        # Create keys if necessary
        do_rsa1_keygen
        do_rsa_keygen
        do_dsa_keygen

        echo -n $"Starting $prog:"
#       initlog -c "$SSHD $OPTIONS" && success || failure
        initlog -c "$SSHD -f /etc/ssh/backup_sshd_config " && success || failure
        RETVAL=$?
        [ "$RETVAL" = 0 ] && touch /var/lock/subsys/backup_sshd

太字の箇所を変更しています。

start()
{
        # Create keys if necessary
        do_rsa1_keygen
        do_rsa_keygen
        do_dsa_keygen

        echo -n $"Starting $prog:"
        initlog -c "$SSHD -f /etc/ssh/backup_sshd_config " && success || failure
        RETVAL=$?
        [ "$RETVAL" = 0 ] && touch /var/lock/subsys/backup_sshd

起動確認

# /etc/init.d/backup_sshd start
sshd を起動中:                  [  OK  ]
# ps -ef | grep sshd
root      5022     1  0 14:09 ?        00:00:09 sshd: root@pts/0
root      5414     1  0 16:46 ?        00:00:00 /usr/sbin/sshd
root      5683     1  5 17:25 ?        00:00:00 /usr/sbin/sshd -f /etc/ssh/backup_sshd_config
root      5687  5024  0 17:25 pts/0    00:00:00 grep sshd
# ssh -p 10022 localhost
Permission denied (gssapi-with-mic,hostbased).

自動起動設定

chkconfig コマンドにて自動起動設定を行います。

# chkconfig  backup_sshd on
# chkconfig --list backup_sshd
backup_sshd     0:off   1:off   2:on    3:on    4:on    5:on    6:off

動かないときは？

なんか色々エラーが出たときのヒントです:-)

Permission denied (hostbased)がでた！！

• お互いのサーバで名前解決できていますか？（/etc/hostsかDNSに名前を登録しましょう)
• ip指定で接続しようとしてませんか？ホスト名指定で接続しないとエラーがでるようです。
• バックアップサーバ側でホストベース認証許可（/etc/ssh_config）の設定はすんでいますか？
• rsync接続先サーバの、~/.ssh/known_hostsにホストキーの登録はすんでいますか？（バックアップ元サーバからホスト名を使用してsshで接続してみましょう）

# rsync -au -e  "ssh -p 10022" www:/home/tamohiko/public_html/  /backup/tamohiko/public_html
Permission denied (hostbased).
rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(359)