среда, 28 сентября 2016 г.

Rsync через ssh



У нас есть два сервера:
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
chown -R user1:user1 /home/user1

В файл ~/.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/

Взято тут.