Rsync через ssh

Теги: SSH Linux Rsync Резервное копирование

У нас есть два сервера:

1) 1.1.1.1 - основной сервер (файлы, почта, что угодно иное), пользователь user1.
2) 2.2.2.2 - сервер, на котором хранятся резервные копии, пользователь user2.

Считаем, что раньше вы не настраивали доступ по ssh к серверам по ключам, а используете пароли. Заодно от паролей избавимся.

Идея: находясь на сервере 2.2.2.2, мы запускаем процесс копирования данных с основного сервера 1.1.1.1 (к себе, на 2.2.2.2).

Проверяем коннект ssh с паролем

Если мы с сервера 2.2.2.2 не сможем с паролем соединиться по ssh к 1.1.1.1, то дальше можно и не продолжать.

Готовим почву

На серверах установим rsync:

yum install xinetd rsync

Редактируем конфиг xinetd для rsync:

nano /etc/xinetd.d/rsync

...
disable = no
# flags = IPv6
...

Создадим отдельного пользователя rsync без домашней директории и /sbin/nologin. Да, я люблю вместо общего nobody для важных задач создавать отдельных пользователей. Никогда не знаешь наперед, когда придется анализировать, что и где глючит.

Редактируем (создаем) минимальный конфиг rsync на сервере 1.1.1.1:

nano /etc/rsyncd.conf

uid = rsync
gid = rsync
use chroot = true
max connections = 5
pid file = /var/run/rsyncd.pid
motd file = /etc/rsync.motd

# Logging
log file = /var/log/rsyncd.log
transfer logging = true
log format = %t %a %m %f %b
syslog facility = local3
timeout = 300

service xinetd restart

Проверим:

netstat -lnpt | grep 873
tcp 0 0 :::873 :::* LISTEN 16269/xinetd

Ок, xinetd слушает порт rsync и при запросе запустит его.

На сервере 2.2.2.2 (с которого будем коннектится) сгенерируем сертификат для доступа без пароля:

# ssh-keygen -f ~/.ssh/id_rsa -q -P "" -b 4096

где:

-q - silense
-f - имя файла ключа
-P "" - пустой пароль
-b 4096 - размер ключа, бит

Просмотрим публичный ключ, который надо будет скопировать на 1.1.1.1, куда будем впоследствии подсоединяться:

# cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDLVDBIpdpfePg/a6h8au1HTKPPrg8wuTrjdh0QFVPpTI4KHctf6/
FGg1NOgM++hrDlbrDVStKn/b3Mu65//tuvY5SG9sR4vrINCSQF++a+YRTGU6Sn4ltKpyj3usHERvBndtFXoDxsYKR
CtPfgm1BGTBpoSl2A7lrwnmVSg+u11FOa1xSZ393aaBFDSeX8GlJf1SojWYIAbE25Xe3z5L232vZ5acC2PJkvKctz
vUttJCP91gbNe5FSwDolE44diYbNYqEtvq2Jt8x45YzgFSVKf6ffnPwnUDwhtvc2f317TKx9l2Eq4aWqXTOMiPFA5
ZRM/CF0IJCqeXG6s+qVfRjB root@cloudads

На сервере 1.1.1.1 (откуда будем копировать файлы).

Скопируем этот ключ на сервер 1.1.1.1, на который будем логиниться, в директорию пользователя user1, под которым будем логинитсья, в файл ~/.ssh/authorized_keys file.

Если директории .ssh на 1.1.1.1 не существует, создадим ее:

mkdir ~/.ssh
chmod 0700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 0644 ~/.ssh/authorized_keys

В файл ~/.ssh/authorized_keys копируем содержимое публичного ключа, созданного на сервере 2.2.2.2 (файл id_rsa.pub) и перезапускаем sshd:

# service sshd restart

Все, мы готовы проверить соединение с 2.2.2.2 на 1.1.1.1 по ssh:

ssh -i /home/user2/.ssh/id_rsa -p 22 user1@1.1.1.1

Если соединение прошло, можно двигаться дальше. Если нет - надо обязательно понять, где проблема (firewall, ошибка copy/paste ключа, забыли restart sshd, что-то еще).

Запускаем rsync через ssh

Мы будем копировать файлы /data/* с сервера 1.1.1.1 на сервер 2.2.2.2 в папку /backup/.

Формат простой: rsync [опции] [откуда] [куда]

rsync -avz -e "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress 1.1.1.1:/data/data.zip /backup/

или так:

rsync -avz -e "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress user1@1.1.1.1:/data/* /backup/

или даже так:

rsync -avz -e "ssh -p 22" --progress user1@1.1.1.1:/data/* /backup/

-e "ssh ..." - указываем, что хотим все передавать по ssh;
-p 22 - указываем порт, на котором работает ssh на сервере 1.1.1.1;
-a, --archive – архивный режим, включает рекурсивное копирование и сохранение прав и владельца;
-v - расширенный вывод;
-z - использовать компрессию данных;
user1 - локальный пользователь сервера 1.1.1.1, настроенный на логин по ssh по ключу.

Естественно, пользователь user1 должен иметь права доступа в /data/.

Вот и все. После копирования проверим, создался ли файл на сервере 2.2.2.2:

ls -al /backup/

Взято здесь.

Авторизуйтесь для добавления комментариев!