Използване на Rsync и SSH

Source page: http://troy.jdmz.net/rsync/index.html

www.jdmz.net troy.jdmz.net

Ключове, Валидиране и Автоматизация

Този документ обхваща използване cron, ssh, и rsync да архивни файлове в локална мрежа или Интернет. Част от моята цел е да се гарантира, не се налага намесата на потребителя, когато компютърът се рестартира (за пароли, ключове или ключови мениджъри).

Харесва ми да се резервно копие на някои сеч, поща, както и информация за конфигурацията понякога на домакините в мрежата и интернет, и тук е така, аз не съм намерил да го направя. Ще имате нужда от тези пакети, инсталирани:

• rsync

• openssh

• сron (или vixie-cron)

Моля, обърнете внимание на тези инструкции може да са специфични за Red Hat Linux версии 7.3, 9 и Fedora Core 3, но се надявам, че няма да бъде твърде трудно да се адаптират към почти всеки тип *NIX операционна система. Страниците на човека за “ssh” и “rsync” трябва да бъдат от полза за вас, ако искате да промените някои неща (използвайте “man ssh” и “man rsync” команди).

На първо място, аз ще се определят някои променливи. По мое обяснение, аз ще се синхронизира файлове (копиране само нови или променени файлове) по един начин, а аз ще се започне този процес от приемащата искам да копирате неща. С други думи, аз ще се синхронизира файлове от /remote/dir/ на remotehost, като remoteuser, до /this/dir/ на thishost, като thisuser.

Искам да се уверите, че “Rsync” над “SSH” работи на всички, преди да започне да се автоматизира процеса, така че аз го тестват първо като  thisuser:

$ rsync -avz -e ssh remoteuser@remotehost:/remote/dir /this/dir/

и въведете remoteuser@remotehost парола при подкана. Трябва да се уверя remoteuser има права за четене /remote/dir/ на remotehost, и това thisuser има разрешения за писане /this/dir/ на thishost. Също, “rsync” и “ssh” трябва да бъде в пътя на thisuser (използвайте “които ssh” и “които rsync”), “rsync” трябва да бъде в пътя remoteuser, и “sshd” трябва да работи на remotehost.

Конфигуриране  thishost

Ако това всичко се нареди, или в крайна сметка го направи да работи, аз съм готов за следващата стъпка. Имам нужда да се генерира частен/публичен двойка ключове, за да се даде възможност на връзка “SSH” без да иска парола. Това може да звучи опасно, и то е, но е по-добре от съхраняване на потребителска парола (или ключ парола) като чист текст в сценария [0]Също така мога да поставя ограничения върху която връзките, направени с този ключ могат да идват от, и за това какво могат да направят, когато е свързан. Както и да е, аз се генерира ключа ще използвам по  thishost (както  thisuser):

$ ssh-keygen -t rsa -b 2048 -f /home/thisuser/cron/thishost-rsync-key 
Generating public/private rsa key pair. 
Enter passphrase (empty for no passphrase): [press enter here] 
Enter same passphrase again: [press enter here] 
Your identification has been saved in /home/thisuser/cron/thishost-rsync-key. 
Your public key has been saved in /home/thisuser/cron/thishost-rsync-key.pub. 
The key fingerprint is: 
2e:28:d9:ec:85:21:e7:ff:73:df:2e:07:78:f0:d0:a0 thisuser@thishost
и сега имаме ключова, без парола в двата файла споменати по-горе [1]. Уверете се, че никой друг неоторизиран потребител може да чете файла с частния ключ (този, без разширението “.pub”).
Този ключ е безпредметно, докато ние поставяме общодостъпната част на файла “authorized_keys” [2] на  remotehost, по-специално тази за  remoteuser:
/home/remoteuser/.ssh/authorized_keys
Аз използвам scp за зареждане на файла към  remotehost:
$ scp /home/thisuser/cron/thishost-rsync-key.pub remoteuser@remotehost:/home/remoteuser/
и след това мога да се подготвят нещата на  remotehost.
Конфигуриране  remotehost

Аз “ssh” към  remotehost:

$ ssh remoteuser@remotehost
remoteuser@remotehost's password: [type correct password here]
$ echo I am now $USER at $HOSTNAME
I am now remoteuser at remotehost
да се направят някои работи.
Трябва да се уверете, че имам директорията и файловете, което трябва да се разреши връзки с този ключ  [3]:
$ if [ ! -d .ssh ]; then mkdir .ssh ; chmod 700 .ssh ; fi 
$ mv thishost-rsync-key.pub .ssh/ 
$ cd .ssh/ 
$ if [ ! -f authorized_keys ]; then touch authorized_keys ; chmod 600 authorized_keys ; fi 
$ cat thishost-rsync-key.pub >> authorized_keys
Сега ключът може да се използва за направата на връзки към този хост, но тези връзки могат да бъдат от всяка точка (че SSH демона на  remotehost  позволява връзки от) и те могат да направят нищо (че  remoteuser  може да направи), а аз не искам това, аз редактирате файла “authorized_keys” (с vi) и промяна на линията с “thishost-rsync-key.pub” информация за него. Аз ще се добавят само няколко неща, в предната част на това, което вече е там, промяна на линията (и това, което следва, е само една линия с лошо симулиран пренасянето на нов ред) от това:
ssh-dss AAAAB3NzaC1kc3MAAAEBAKYJenaYvMG3nHwWxKwlWLjHb77CT2hXwmC8Ap+fG8wjlaY/9t4u
A+2qx9JNorgdrWKhHSKHokFFlWRj+qk3q+lGHS+hsXuvta44W0yD0y0sW62wrEVegz+JVmntxeYc0nDz
5tVGfZe6ydlgomzj1bhfdpYe+BAwop8L+EMqKLS4iSacNjoPlHsmqHMnbibn3tBqJEq2QJjEPaiYj1iP
5IaCuYBhuTKQGa+oyH3mXEif5CKdsIKBj46B0tCy0/GC7oWcUN92QdLrUyTeRJZsTWsxKpRbMliD2pBh
4oyX/aXEf8+HZBrO5vQjDBCfTFQA+35Xrd3eTVEjkGkncI0SAeUAAAAVAMZSASmQ9Pi38mdm6oiVXD55
Kk2rAAABAE/bA402VuCsOLg9YS0NKxugT+o4UuIjyl6b2/cMmBVWO39lWAjcsKK/zEdJbrOdt/sKsxIK
1/ZIvtl92DLlMhci5c4tBjCODey4yjLhApjWgvX9D5OPp89qhah4zu509uNX7uH58Zw/+m6ZOLHN28mV
5KLUl7FTL2KZ583KrcWkUA0Id4ptUa9CAkcqn/gWkHMptgVwaZKlqZ+QtEa0V2IwUDWS097p3SlLvozw
46+ucWxwTJttCHLzUmNN7w1cIv0w/OHh5IGh+wWjV9pbO0VT3/r2jxkzqksKOYAb5CYzSNRyEwp+NIKr
Y+aJz7myu4Unn9de4cYsuXoAB6FQ5I8AAAEBAJSmDndXJCm7G66qdu3ElsLT0Jlz/es9F27r+xrg5pZ5
GjfBCRvHNo2DF4YW9MKdUQiv+ILMY8OISduTeu32nyA7dwx7z5M8b+DtasRAa1U03EfpvRQps6ovu79m
bt1OE8LS9ql8trx8qyIpYmJxmzIdBQ+kzkY+9ZlaXsaU0Ssuda7xPrX4405CbnKcpvM6q6okMP86Ejjn
75Cfzhv65hJkCjbiF7FZxosCRIuYbhEEKu2Z9Dgh+ZbsZ+9FETZVzKBs4fySA6dIw6zmGINd+KY6umMW
yJNej2Sia70fu3XLHj2yBgN5cy8arlZ80q1Mcy763RjYGkR/FkLJ611HWIA= thisuser@thishost
за тази [4]:
from="10.1.1.1",command="/home/remoteuser/cron/validate-rsync" ssh-dss AAAAB3Nza
C1kc3MAAAEBAKYJenaYvMG3nHwWxKwlWLjHb77CT2hXwmC8Ap+fG8wjlaY/9t4uA+2qx9JNorgdrWKhH
SKHokFFlWRj+qk3q+lGHS+hsXuvta44W0yD0y0sW62wrEVegz+JVmntxeYc0nDz5tVGfZe6ydlgomzj1
bhfdpYe+BAwop8L+EMqKLS4iSacNjoPlHsmqHMnbibn3tBqJEq2QJjEPaiYj1iP5IaCuYBhuTKQGa+oy
H3mXEif5CKdsIKBj46B0tCy0/GC7oWcUN92QdLrUyTeRJZsTWsxKpRbMliD2pBh4oyX/aXEf8+HZBrO5
vQjDBCfTFQA+35Xrd3eTVEjkGkncI0SAeUAAAAVAMZSASmQ9Pi38mdm6oiVXD55Kk2rAAABAE/bA402V
uCsOLg9YS0NKxugT+o4UuIjyl6b2/cMmBVWO39lWAjcsKK/zEdJbrOdt/sKsxIK1/ZIvtl92DLlMhci5
c4tBjCODey4yjLhApjWgvX9D5OPp89qhah4zu509uNX7uH58Zw/+m6ZOLHN28mV5KLUl7FTL2KZ583Kr
cWkUA0Id4ptUa9CAkcqn/gWkHMptgVwaZKlqZ+QtEa0V2IwUDWS097p3SlLvozw46+ucWxwTJttCHLzU
mNN7w1cIv0w/OHh5IGh+wWjV9pbO0VT3/r2jxkzqksKOYAb5CYzSNRyEwp+NIKrY+aJz7myu4Unn9de4
cYsuXoAB6FQ5I8AAAEBAJSmDndXJCm7G66qdu3ElsLT0Jlz/es9F27r+xrg5pZ5GjfBCRvHNo2DF4YW9
MKdUQiv+ILMY8OISduTeu32nyA7dwx7z5M8b+DtasRAa1U03EfpvRQps6ovu79mbt1OE8LS9ql8trx8q
yIpYmJxmzIdBQ+kzkY+9ZlaXsaU0Ssuda7xPrX4405CbnKcpvM6q6okMP86Ejjn75Cfzhv65hJkCjbiF
7FZxosCRIuYbhEEKu2Z9Dgh+ZbsZ+9FETZVzKBs4fySA6dIw6zmGINd+KY6umMWyJNej2Sia70fu3XLH
j2yBgN5cy8arlZ80q1Mcy763RjYGkR/FkLJ611HWIA= thisuser@thishost
където “10.1.1.1” е IР (версия 4 [5]) адрес на  thishost и “/home/remoteuser/cron/validate-rsync” (която е само една от няколко възможности,  [6], включително и персонализиране [7]  за подобряване на сигурността) е скрипт, който изглежда по следния начин:
#!/bin/sh 

case "$SSH_ORIGINAL_COMMAND" in 
*\&*) 
echo "Rejected" 
;; 
*\(*) 
echo "Rejected" 
;; 
*\{*) 
echo "Rejected" 
;; 
*\;*) 
echo "Rejected" 
;; 
*\<*) 
echo "Rejected" 
;; 
*\>*) 
echo "Rejected" 
;; 
*\`*) 
echo "Rejected" 
;; 
*\|*) 
echo "Rejected" 
;; 
rsync\ --server*) 
$SSH_ORIGINAL_COMMAND 
;; 
*) 
echo "Rejected" 
;; 
esac
Ако  thishost  има променлива адрес или споделя неговия адрес (чрез NAT или нещо подобно) с домакини нямате доверие, пропуснете “from=”10.1.1.1″,” част от линията (включително запетаята), но оставете частта “command”. По този начин само “rsync” ще бъде възможно от свързвания с помощта на този бутон. Направи  някои, че скриптът “validate-rsync” е изпълнима от  remoteuser  на remotehost  и да го тестваме.
ВНИМАНИЕ:  частният ключ, въпреки че сега донякъде ограничени в това, което той може да направи (и се надяваме, където тя може да бъде направено от), позволява на притежателя да копирате  всеки  файл от  remotehost  че  remoteuser  има достъп. Това е опасно, а аз трябва да предприеме всички предпазни мерки, аз смятат за необходими за поддържането на сигурността и поверителността на този ключ. Някои от възможностите би било осигуряването на правилните разрешения файлове са възложени  [8], помислете за използване на ключ за кеширане демон, и считат, ако наистина имам нужда автоматизирате този процес стихове на риска.
СЪЩО ТАКА ИМАЙТЕ ПРЕДВИД:  друг детайл сигурност е да се помисли конфигурацията на SSH демон на  remotehost. Този пример се фокусира върху един потребител (remoteuser), който не е  root. Не препоръчваме използването на  root като отдалечен потребител, тъй като  root, има достъп до всеки файл на  remotehost. Това сам способност е много опасно, както и санкциите за грешка или неправилно конфигуриране може да бъде далеч по-стръмни от тези за “нормална” употреба. Ако не използвате  root като отдалечен потребител (някога) и да вземете решения за сигурност за  remotehost, препоръчвам или:
PermitRootLogin no
 или:
PermitRootLogin forced-commands-only
да бъдат включени в “/etc/ssh/sshd_config” файл на remotehost. Това са глобални настройки, а не само свързани с тази връзка, затова не забравяйте, че не се нуждаете от възможността за забрана на тези опции за конфигуриране [9].
“AllowUsers”, “AllowGroups”, “DenyUsers”, и “DenyGroups” ключовите думи могат да се използват за ограничаване на достъпа до SSH до определени потребители и групи. Те са документирани в страницата на човека за “sshd_config”, но ще спомена, че всички те могат да използват “*” and “?” като заместващи клавиши за разрешаване и отказване на достъп до потребители и групи, които съответстват на моделите. “AllowUsers” и “DenyUsers” може също да се ограничи от хоста, когато моделът е в USER@HOST форма.
Отстраняване на проблеми

Сега, когато имам ключ, без парола на място и е конфигурирана, че трябва да го тествате, преди да я сложите в работа Cron (която има свой собствен малък набор от багаж). Аз излизане от сесията на SSH за  remotehost  и се опитват  [10]:

$ rsync -avz -e "ssh -i /home/thisuser/cron/thishost-rsync-key" remoteuser@remotehost:/remote/dir /this/dir/
Ако това не се случи, ще извадя ограничението “команда” на ключа и ще опитам отново. Ако той поиска парола, ще проверя разрешенията на файла с частен ключ (на thishost, трябва да е 600), на “authorized_keys” и (на remotehost, трябва да е), на “~/.ssh/” директорията (и на двата хоста, трябва да бъде 700), както и в домашната директория (“~/”) (и на двата хоста, не трябва да се записва от никой освен от потребителя). Ако възникне някаква криптична протоколна грешка “rsync”, в която се споменава “validate-rsync” скрипт, ще се уверя, че разрешенията са “validate-rsync” (на remotehost, може да бъде 755, ако всеки remotehost потребителят има доверие) да позволи на remoteuser да го чете и изпълнява.
Ако нещата все още не работят, може да се намери полезна информация в дневниците. Журналните файлове обикновено се намират в /var/log/ директория на повечето linux хостове и в /var/log/secure файл на журнала на linux хостове Red Hat. Най-полезните регистрационни файлове в този случай ще бъдат намерени на remotehost, но localhostможе да предоставя някои от страна на клиента информация в своите дневници  [11]Ако не можете да стигнете до трупи, или са просто нетърпелив, можете да кажете на “ssh” изпълнимия да се дадат някои сеч с  “verbose” команди: “-v”, “-vv”, “-vvv”. Колкото по v, толкова по-многословно изход. Един от тях е в командата по-горе, но този по-долу трябва да предостави много по-изход:
$ rsync -avvvz -e "ssh -i /home/thisuser/cron/thishost-rsync-key" remoteuser@remotehost:/remote/dir /this/dir/
Надяваме се, че тя винаги ще работи безотказно просто така че никога не трябва да се разшири информацията за отстраняване на изброените тук  [12].
Настройване на заданието за Cron

Последната стъпка е Cron скрипт. Аз използвам нещо като това:

#!/bin/sh 

RSYNC=/usr/bin/rsync 
SSH=/usr/bin/ssh 
KEY=/home/thisuser/cron/thishost-rsync-key 
RUSER=remoteuser 
RHOST=remotehost 
RPATH=/remote/dir 
LPATH=/this/dir/ 

$RSYNC -az -e "$SSH -i $KEY" $RUSER@$RHOST:$RPATH $LPATH

защото е лесно да се променят бита и парчета от командния ред за различните хостове и пътеки. Аз обикновено го наричат, подобно на “rsync-remotehost-backups”, ако той съдържа архиви. Тествам сценария също, само в случай, че внимателно поставена грешка някъде.

Когато отида на скрипта работи успешно, аз използвам “crontab -e”, за да вмъкнете ред за тази нова cron работни места:
0 5 * * * /home/thisuser/cron/rsync-remotehost-backups
за ежедневно синхрон 5 AM, или:
0 5 * * 5 /home/thisuser/cron/rsync-remotehost-backups
за всяка седмица (5 AM в петък). Месечни и годишни от тях са по-редки за мен, така че гледат на “man crontab” или тук  за съвет относно тези.

Добре! С изключение на ежедневието “в крак с кръпки” нещо, коварните “скрити недостатъци конфигурация” страна, и незабравимо “пълния провал на човешката логика” набор от проблеми, моята работа тук е свършена. Наслади се!

Забележки:
[0] Причината за избора на ключ SSH, без парола, с течение на опции като  SSH-агент  или  ключодържател, е, че автоматизиран процес ще оцелее рестартиране на хост машината и изпълнение на следващото планирано време без намеса от моя страна (не всички машини така автоматизирано винаги достъпен). Ако не разполагате с тези изисквания, тези и други възможности могат да подкрепят внедряването на по-голяма сигурност.
[1] Ако  remotehost  само е инсталирал SSH1, може да се наложи да използвате друг ключов тип. Вместо “rsa” ще трябва да използвате “rsa1”. Можете да използвате “dsa” dvtcnj “rsa”, но тя все още ще бъде само от полза за връзка SSH2 (и дължина на ключа може да е проблем, както е отбелязано тук  – благодаря ви @avenjamin). SSH2 връзки са по-сигурни, отколкото SSH1 връзки, но ще трябва да се търсят другаде за подробности за това (“man ssh-keygen” и Google). Също така, ключов създаването може да се направи с помощта на командата (ssh-keygen -b 2048 -f keyfile -t rsa -N ”) за да се автоматизира” без ключ парола част”, или (ssh-keygen -b 2048 -f keyfile -q -t rsa -N ”) за да се елиминира всякакъв изход от командата.
[2] Някои конфигурации използват “authorized_keys2” вместо “authorized_keys”. Потърсете “AuthorizedKeysFile” в “/etc/ssh/sshd_config”.
[3] Ако използвате черупка, различни от “bash” (или друг съвместим борн черупка), като “csh” или “tcsh”, командите, изброени може да не работят. Преди да ги изпълнява, стартиране на “bash” (или “sh”, “ksh”, или “zsh”) обвивка с помощта на “bash” (или “sh”, “ksh”, или “zsh”) команда.След завършване на командите, ще трябва да излезе от черупката “bash” а след това да излезете от черупката си домакин хайвера нормално.
[4] Не забравяйте да не въвежда никакви нови редове в “authorized_keys” файла. Основната информация, както и въведените команди, свързани с този ключ, всички трябва да са на един ред. Ключът генерирате (безсмисленото неща по линията на ключа), ще бъде различен от този тук. Избор на редактора, че не автоматично “обвивка” (вписват новите редове) текстът може да бъде изключително важен тук.
[5] Виждал съм един хост игнорира правилно представени IPv4 адрес, а вместо това видя входящия връзката като IPv6 вид адрес (“::fff:10.1.1.1”). Намерих адреса в “/var/log/messages” за домакен Fedora Core 3 Linux, и това не позволява връзки от този хост с IPv6 версия във файла “authorized_keys”.
[6] Друг вариант за проверка (и повече) е Perl скрипт намира тук: http://www.inwap.com/mybin/miscunix/?rrsync, макар че е по-сложно. А версия на тази Perl скрипт сега е част от пакета с източника на rsync тук: http://www.samba.org/ftp/unpacked/rsync/support/rrsync (с подобрения). Ако пишете специален скрипт който какъвто и език по Ваш избор, погледнете вътре в този един за предложения.
[7] По времето, когато “validate-rsync” сценария работи, връзка SSH е направено с клавиша SSH ви свързва с тази команда във файла “authorized_keys”. Този пример скрипт основно опитва да се върне “Rejected” за нищо друго, освен една команда, която започва с “rsync –server”, което е това, което rsync над ssh прави на другия край на връзката.Открих това като пуснете “ps auxw | grep rsync” на отдалечения край на връзката след инициализиране на дълго тичане rsync работа, но rsync pro каза, че може да се добави “-v -v -n” на вашите опции за командния ред за rsync и той ще покаже на командата ще използва на края на сървъра, така че да използва това, за да си скрипт команда по-конкретен, ако желаете. Първите шест “Rejected” линии се опитват да елиминиране черупки символи, които ще позволят на човек да изпълнява повече от една команда в рамките на една сесия (например, кратък rsync и някои палав команда не искате работи от разстояние). Можете също така да принуди трансферът да се четат само чрез промяна на команда, за да “rsync –server –sender*” (благодарение на Дейвид Фред).
[8] Чрез подходящи файловите права, искам да кажа сигурни файла разрешения. В това, което по същество защитава remotehost от remoteuser, така че remoteuser не би била в състояние да променят тази настройка по никакъв начин.Това означава, че remoteuser няма да притежава, или е в състояние да пиша, скрипта за валидиране или дори remoteusers authorized_keys файла. В този момент, обаче, може да искате да обмисли възможността за използване “Match User” в /etc/ssh/sshd_config и използвайте ChrootDirectory и/или ForceCommand да ги съдържат, ако сигурността е много важно за вас. Отиди толкова далеч, колкото вижда нужда да отида. (Благодаря ви Янек Мартинсън).
[9] “PermitRootLogin no” прави това, което той казва: на root потребителят няма право да влезете чрез SSH. “PermitRootLogin forced-commands-only” изисква всички връзки, чрез SSH като root, трябва да се използва публичен ключ (с ключ, като “thishost-rsync-key.pub”) и че команда да се асоциира с този ключ (като “validate-rsync”). За повече обяснения, използвайте “man sshd_config” команда. Ако използвате Ubuntu, моля уверете се, че пакетът “openssh-server” е инсталирана (не се инсталира по подразбиране).
[10] Могат да бъдат включени всички видове ключове линия SSH командни (цитирано) в рамките на Rsync “-e” линия превключвател команда, като нестандартни SSH сървъра пристанищни връзки (например: “-p 2222”, ако SSH връзки на порт 2222), в освен частния ключ (“-i identity_file”) ключа. (Пер Функе предложи това и съотнесени http://mike-hostetler.com/blog/2007/12/rsync-non-standard-ssh-port).
[11] Можете да разберете какво лог файл SSH ще се пише за, като погледнете в два файла: “/etc/ssh/sshd_config” и “/etc/syslog.conf”. “sshd_config” съдържа параметър  “SyslogFacility”, която по подразбиране е настроен на “AUTH”, но Red Hat обикновено тя определя за “AUTHPRIV”. Който и да е, не забравяйте, настройката и ще я търсим във файла  “syslog.conf”. Обикновено ще намерите линия с “authpriv.*” последвана от някои раздели и след това лог файл, който търсите. Не обръщайте внимание на линии “сauthpriv.none” в тях, тъй като те са вероятно вземе в рамките на много видове съобщения, но забраняващ на тези от “authpriv” системен съоръжението.
[12] Едва ли.

Звена:

© 2003-2015 Troy Johnson

 

 

Leave a Reply