Наскоро ми се наложи да организирам бекъп от (наследен) сървър под FreeBSD на машина под Linux.
Оригиналната система за бекъп от сървъра беше Bacula, която никак не е лоша. Личните ми вкусове за системи с малко компютри в тях обаче клонят към rsync. Затова, когато дискът на бекъп машината се препълни и се наложи да бъде сменен с по-голям, реших да заложа на легендарния си любимец. Както винаги, той не ме подведе.
Сблъсках се обаче с интересен проблем – не ми беше лесно да организирам връзката през шифрован канал. Споделям тук как се справих, за ако някой някога се мъчи с подобна ситуация.
За канала използвам SSH. Задавате на rsync опция -e ssh (в моя случай SSH беше разумно настроен на нестандартен порт: -e "ssh -p 12345") и информацията тече във вид, неприятен за любопитните по трасето. За да настроите обаче автоматиката, ви трябва логване чрез ключ. А по някаква причина SSH сървърът упорито отказваше да ми приеме ключа и настояваше за парола. Прверките на правопис на имената на файловете, пермишъни за тях и директориите и чопленето за информация през -v, -vv и -vvv опциите на SSH не дадоха резултат.
След половин час чоплене и зяпане накрая видях очевадното: на сървъра имаше инсталирани както SSH, така и SSH2, и работеше вторият. Наругах се здравата и откопирах authorized_keys файла в ~/.ssh2, с отново същия резултат. След пет минути ровене из мрежата последва второ самонаругаване – SSH2 използва различна система на описване на оторизираните за връзка ключове.
~/.ssh2# mv authorized_keys backup.pub
~/.ssh2# echo "Key backup.pub" >> authorization
И… нещата отново не проработиха.
Този път падна около час четене и ровене, докато не открих втората логична до очевадност разлика – форматът на публичните ключове за SSH и SSH2 е различен. Изконвертирах формата на линуксовската машина:
~# ssh-keygen -e -f ~/.ssh/id_rsa.pub > ~/.ssh/id_rsa_ssh2.pub
и вече този файл, копиран като ~/.ssh2/backup.pub, свърши чудесна работа. 🙂