１．きっかけ
普段キーボードもディスプレイも繋いでいないサーバのデータを手元にバックアップしようとしたら、CDで起動するCloneziillaのような「まるごとバックアップ」アプリは使用できない。
ArchLinuxのArchWikiには、以下のように記載されている。
SSH を使った自動バックアップ
SSH を使ってリモートホストにバックアップする場合、以下のスクリプトを使用:
/etc/cron.daily/backup
—————————————-#!/bin/bash
rsync -a –delete -e ssh /folder/to/backup remoteuser@remotehost:/location/to/backup &> /dev/null
でも、この方法には問題が３つほどある。
- バックアップ先（リモートホスト）を外付けHDD（USBなど）するために特権ユーザにならなければならない。これは常時接続しておくことで解決できるが！
- バックアップ元（サーバ）のデータをできるだけまるごと（すなわちrootしかアクセスできないデータも）コピーしたい。
- SSHサーバはrootログインを禁じている。
１の問題はクリアーできたとしても、２と３の問題は「あちらを立てればこちらが立たず」の関係だ。
2023/12/13 追記
- 以下の記述では、サーバ、リモートホストの用語が出てくる。サーバはバックアップされるファイルが入っているところ、リモートホストはバックアップしたファイルを保存するところとして理解しているが、https://wa3.i-3-i.info/word12770.htmlによると、リモートホストよりローカルホストのほうがわかりやすい。したがってサーバのデータをローカルホストにバックアップするの意味で、サーバ、ローカルホストとして整理した。
- サーバにローカルホストが取りに行くか、サーバがローカルホストにバックアップさせるか？２通りの方法が可能と思われるが、後者の方法だと、サーバに共通鍵と秘密鍵の両者を設置することになりリスクが高くなるので、ローカルホストからサーバに取りに行く方法を選択した。これだと共通鍵だけの設置で済むからだ。
２．サーバ側の設定
（１）一般ユーザでサーバにアクセス
$ ssh 一般ユーザ＠IPアドレス
（２） rootのsshディレクトリを作成して、すでに使っている公開鍵をそこに移動.必要なパーミッションを設定
$ su
# mkdir ~/.ssh
# chmod 700 ~/.ssh
# cp /home/一般ユーザ/.ssh/authorized_keys ~/.ssh
# chmod 600 ~/.ssh/authorized_keys
sshd_configファイルでrootでのアクセスを許可するよう設定し、SSHDを再起動する
# nano /etc/ssh/sshd_config
PermitRootLogin yes
PubkeyAuthentication yes
鍵認証方式なので、これだけ良いと思われたが、どうしてもPermission denied (publickey).エラーが発生したので、とりあえずパスワード認証を復活させ、SSHDを再起動。
PasswordAuthentication yes
# systemctl restart sshd.service
３．ローカルホスト側での準備
特権ユーザー用の専用ディレクトリを作成し、すでにある秘密鍵をコピー、パーミッションを設定
$ su –
# mkdir ~/.ssh
# cp /home/一般ユーザ/.ssh/id_rsa ~/.ssh/
# chmod 600 ~/.ssh/id_rsa
# exit
４．コマンドラインから実行
（１）主なrsync オプション
- -a =>-rlptgoD オプションと同義 (recursive, links, perms, times, group, owner, devices)
- –delete => サーバにないファイルをリモートホスト側で削除
- –exclude={ } => バックアップの対象としない
- -e “ssh -p ポート番号 -i 秘密鍵” => rsyncにSSH（オプションあり）を使うようにする。
- root@IPアドレス:/ 特権ユーザの接続先 => バックアップするディレクトリ
（２）実際のコマンド
sudo rsync -a --delete --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/home/一般ユーザ/.cache/*","/lost+found"} -e "ssh -p ポート番号 -i /root/.ssh/id_rsa" root@IPアドレス:/ /保存に使用するディスクとディレクトリ５．より安全に
快適になったのですが、どうもパスワード認証やrootでの接続を許すなど、セキュリティ上問題ではないか？少なくとも精神衛生上よくない。
そこで、port番号の変更以外で、SSHの設定を見直すことでセキュリティをもっとアップさせたいと調べてみた。
６．サーバ側の設定ファイルの見直し
（１）sshd_configの見直し
$ sudo nano /etc/ssh/sshd_config
PermitRootLogin without password
※これはパスワードの使用を禁止するものですが、やはりConnection refusedされ、使えません。PermitRootLogin forced-commands-only
※これはrootで接続しても、実行できるコマンドを制限するものです。どのコマンドを許可するのか？それはauthorized_keysに設定します。
（２）キーファイルの見直し
$ su
# nano ~/.ssh/authorized_keys
※公開鍵のファイルはssh-rsa ………….のように記載されています。
これを↓のように修正します。
command=”/usr/lib/rsync/rrsync -ro /” ssh-rsa …………………
これで、rootで認証しても「できることはrsync」のみ。
（３）sshd.serviceを再起動します。
# systemctl restart sshd.service
# exit
$ logout
７．テスト
$ su
# ssh -p 公開ポート番号 root@サーバのIPアドレス
（１） 公開鍵のパスフレーズの入力を無視してパスワード認証に進むと３回の入力ミスで、入力できなくなる。
Enter passphrase for key ‘/root/.ssh/id_rsa’: ←無視
root@IPアドレス’s password:
Permission denied, please try again.
root@IPアドレス’s password:
Permission denied, please try again.
root@IPアドレス’s password:
Permission denied (publickey).
（２）公開鍵の正しいパスフレーズを入力するとsshdからrsyncを呼び出すことができないとして切断された。
sshで接続したらいきなり指定のコマンドを実行（すなわち、いきなり指定のコマンドを実行するようsshdに接続）すべきで、コマンドプロンプトの状態に入ろうとするのはルール違反ということか？
Enter passphrase for key ‘/root/.ssh/id_rsa’: ←正しく入力
usr/lib/rsync/rrsync: Not invoked via sshd
Use ‘command=”/usr/lib/rsync/rrsync [-ro|-wo] SUBDIR”‘
in front of lines in /root/.ssh/authorized_keys
Connection to IPアドレス closed.
コメント