Копирование файлов в автоматическом режиме с множества компьютеров через SSH::Журнал СА 12.2004
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 1943
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1973
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1530
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1117
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1693
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

Электронка - 2020!

 Копирование файлов в автоматическом режиме с множества компьютеров через SSH

Архив номеров / 2004 / Выпуск №12 (25) / Копирование файлов в автоматическом режиме с множества компьютеров через SSH

Рубрика: Администрирование /  Продукты и решения

РАШИД АЧИЛОВ

Копирование файлов в автоматическом режиме с множества компьютеров через SSH

Постановка задачи

Предположим, имеется некоторое количество компьютеров под управлением операционной системы UNIX (Windows) с запущенным SSH-сервером, на которых автоматически по расписанию в некоторое время стартует программа, создающая резервные копии некоторых каталогов (например, /etc, /usr/local/etc) и складывающая их в определенное место. Пример такого скрипта, адаптированного под систему periodic во FreeBSD, можно скачать с http://www.granch.ru/~shelton/fileZ/130.backup-dirs. Все используемые параметры описаны в начале скрипта. Для обеспечения сохранности данных архивов было бы неплохо копировать их все в одну точку, откуда их можно было бы перенести на съемный носитель, например. Копирование должно проводиться в автоматическим режиме, все имена каталогов – быть уникальными, требовать минимум настроек и обеспечивать максимум безопасности при передаче данных по сети (если, например, архив /etc попадет в чужие руки, можно получить столько проблем, что мало не покажется). С этой целью был разработан скрипт копирования файлов через SCP2 (программу безопасного копирования, входящую в комплект SSH2) без ввода паролей, используя авторизацию с помощью публичных ключей. Скрипт выполняет копирование файлов, размещенных в некотором, заранее обусловленном каталоге, отмечает каждое действие в собственном файле журнала. В статье скрипт будет приводиться по частям (которые, будучи объединены вместе, тем не менее дадут полноценный скрипт), полный текст скрипта можно загрузить с http://www.granch.ru/~shelton/fileZ/safecopy.

Для разработки скрипта, отладки и применения использовался компьютер с операционной системой FreeBSD 4.10-STABLE и SSH2 от SSH Communications Inc., установленный из портов (/usr/ports/security/ssh2). Скрипт имеет некоторые адаптационные возможности для работы с OpenSSH, но работоспособность этих возможностей не проверялась и может содержать ошибки. Для работы скрипта использовалось имя пользователя rmbackup.

Настройка SSH

SSH – это протокол связи двух компьютеров через TCP/IP c шифрованием передаваемых данных. Этот протокол обеспечивает надежный и безопасный доступ к удаленному компьютеру, расположенному... да неважно где, лишь бы у него был выход в Интернет. С точки зрения рядового системного администратора SSH обычно рассматривается как безопасное средство удаленного управления сервером, для чего ранее использовалась программа telnet. Конечно, есть и другие средства шифровки трафика, но их мы рассматривать не будем.

Разумеется, шифрование сессии во время работы по SSH выполняется, но возможности SSH не исчерпываются только этим. Я не буду приводить здесь описание всех возможностей SSH, это тема для отдельной статьи, всех интересующихся отсылаю к документации на SSH2 (http://www.ssh.fi/support/documentation/online/ssh/adminguide/32).

Одной из возможностей SSH является то, что он может выполнять авторизацию пользователей и организовывать удаленное выполнение команд в SSH-сессии без ввода пароля, с помощью так называемого публичного ключа. Эта возможность основана на стандартном методе авторизации с помощью асимметричных ключей – приватного и публичного.

Приватный ключ доступен только пользователю и тщательно им оберегается от хищения, публичный же ключ, наоборот, размещается во всех местах, где только можно его разместить. На мой взгляд, наиболее удачное описание того, как работает SSH и как его использовать (не считая, конечно, man ssh2, man ssh.conf и прочих манов) – это книга «SSH, the Secure Shell: Definitive Guide» [1].

После того как принято решение о включении данного компьютера в автоматическое копирование файлов, но перед тем как начинать собственно копирование, необходимо выполнить следующие шаги по настройке SSH:

1. Создаем пользователя, от имени которого будет выполняться копирование файлов. Пользователь может не иметь пароля («*» в поле пароля в /etc/master.passwd), но должен иметь действительный shell, поскольку он (shell) будет выполнять некоторые команды. Пользователь должен быть создан на всех компьютерах, с которых будут копироваться файлы, и на всех компьютерах иметь одинаковые настройки и имя. Это не обязательно с точки зрения SSH, но необходимо для скрипта, поскольку тот использует одно фиксированное имя пользователя. Интерактивной работы на компьютерах, с которых будут копироваться данные, никогда не будет, поэтому /bin/sh будет вполне достаточно. На компьютере, на котором будет выполняться скрипт (назовем его «мастер») установите любой привычный shell.

2. Создаем ключевую пару для данного пользователя на данном компьютере. Для этого используется программа ssh-keygen2. Порядок создания ключей не важен, следует только помнить, что мастер-компьютер обращается ко всем компьютерам, с которых копируются данные, а к самому мастер-компьютеру не обращается никто. Поскольку предполагается автоматическая работа, то создается ключевая пара, не защищенная паролем. Пример создания ключевой пары приведен ниже:

>ssh-keygen2 -P

Опускать -P здесь нельзя – опция указывает на необходимость создания ключа, не защищенного паролем. После создания ключевой пары появляются файлы id_dsa_2048_a (приватный ключ) и id_dsa_2048_a.pub (публичный ключ). Подробную информацию о создании ключевой пары см. man ssh-keygen2. Публичный ключ мастер-компьютера, переименованный, например, в rmbackup_master.pub, нужно поместить в подкаталог .ssh2 домашнего каталога пользователя rmbackup на всех компьютерах, с которых будут копироваться файлы.

3. Настраиваем конфигурационные файлы идентификации и авторизации. Эти файлы определяют имя файла (файлов – в SSH2 их может быть несколько) приватного ключа (ключей) и имена файлов, задающие ключи, авторизация с которыми разрешена на данном компьютере для данного пользователя. По умолчанию имена этих файлов identification и authorization. На мастер-компьютере файл authorization можно не создавать – на него никто не будет заходить данным пользователем. На компьютерах, с которых будут копироваться данные, файл authorization обязательно должен содержать имя файла ключа мастер-компьютера. Примеры файлов:

identification:

IdKey id_dsa_2048_a

authorization:

Key rmbackup_master.pub

Следует иметь в виду, что если планируется заходить с нескольких компьютеров, ключ каждого компьютера должен быть помещен в подкаталог .ssh2 данного компьютера и описан в файле authorization. Более подробная информация о настройке авторизации по публичному ключу приведена в man ssh.conf и man sshd.conf.

4. В первый раз заходим с мастер-компьютера на компьютер, с которого будут копироваться файлы в интерактивном режиме. Это необходимо для создания хост-ключей в подкаталоге hostkeys каталога .ssh2. Хост-ключи идентифицируют SSH-сервер в целом. При отсутствии хост-ключа в подкаталоге hostkeys перед началом сессии мастер и удаленный компьютер обмениваются хост-ключами, и хост-ключ удаленного компьютера помещается в подкаталог hostkeys для пользователя rmbackup. При этом на консоли появляется следующий запрос:

>ssh mybox

Host key not found from database.

Key fingerprint:

xocob-bicub-vatun-mofos-nutym-parok-sahet-hefer-papuh-kepyz-rexox

You can get a public key"s fingerprint by running

% ssh-keygen -F publickey.pub

on the keyfile.

Are you sure you want to continue connecting (yes/no)? yes

Host key saved to /usr/home/rmbackup/.ssh2/hostkeys/key_22_mybox.pub

host key for mybox, accepted by rmbackup Wed Nov 03 2004 23:44:10 +0600

Проверка того, что авторизация настроена правильно, очень проста – набираете команду ssh remote на мастер-компьютере, где remote – имя или адрес удаленного компьютера. Удаленная SSH-сессия должна начаться сразу же, без дополнительных запросов пароля. Если появится запрос пароля на разблокировку ключа:

>ssh mybox

Passphrase for key "/usr/home/rmbackup/.ssh2/id_dsa_2048_a" with comment "2048-bit dsa, rmbackup@mybox.com, Fri Jul 23 2004 12:50:25+0700":

значит ключ был сгенерирован с паролем. Такой ключ следует удалить и создать заново, но без пароля (см. пример выше).

Если же появляется стандартный запрос пароля:

>ssh mybox

rmbackup"s password:

значит, существуют проблемы в настройке авторизации. В разделе «Возможные ошибки и изменения скрипта» приведены примеры того, что может пойти не так во время настройки, и некоторые советы по исправлению создавшегося положения.

Дополнительные вопросы безопасности

Поскольку созданный нами публичный ключ не имеет парольной защиты, то всегда существует ненулевая вероятность, что данный ключ может быть похищен и использоваться не по назначению. Для того чтобы сделать такую возможность как можно менее привлекательной, пользователя, от имени которого выполняется копирование, поместим в chroot-окружение.

Что это такое? Это отдельная настройка SSH-сервера, при которой он передает клиенту информацию о том, что домашний каталог пользователя – это корень файловой системы. Естественно, выше корня двигаться невозможно. Технология изоляции критичных системных сервисов в «песочницы» (sandboxes) применяется уже достаточно давно и успешно. Правда тут есть одно «но» – нам понадобится обеспечить работоспособность сервера в данном окружении. Поскольку абсолютно все, что находилось выше домашнего каталога в режиме chroot, недоступно, следует создать собственную иерархию каталогов со всем необходимым. Правда, этого необходимого крайне мало. В домашнем каталоге пользователя rmbackup на удаленном компьютере следует создать каталоги /bin и /etc. В каталог /bin поместить файлы (переписать из стандартного /bin) ls, sh и (ВНИМАНИЕ!) исполняемый файл sftp-server, собранный таким образом, что у него отсутствуют динамические ссылки на библиотеки. Такой режим обычно применяется для программ, используемых в процессе восстановления системы. Исполняемый файл sftp-сервера должен быть обязательно собран с отключением динамических библиотек, иначе придется дублировать всю структуру динамической загрузки – /usr/libexec/ld-elf.so, /var/run/ld-so.hints и все остальное. Исполняемый файл такого типа можно получить, дописав в каталоге, где лежат исходные тексты ssh, в подкаталоге apps/ssh в файл Makefile в строчку 273 (или около того) LDADD=<флаги> флаг -static и пересобрать SSH. Как проверить, является ли полученный исполняемый файл статически или динамически собранным?

> ldd sftp-server2

Ldd: sftp-server2: not a dynamic executable

Приведенный выше ответ является правильным, если вместо него появляется что-то типа:

> ldd sftp-server2:

        libm.so.2 => /usr/lib/libm.so.2 (0x280bb000)

        libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x280d7000)

        libutil.so.3 => /usr/lib/libutil.so.3 (0x280f0000)

        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x280f9000)

        libc.so.4 => /usr/lib/libc.so.4 (0x2813b000)

значит, это динамически собранный исполняемый файл, и он не годится. На самом деле его тоже можно использовать. Но для этого придется создать /usr/libexec в домашнем каталоге пользователя rmbackup, перенести туда ls-elf.so, создать /usr/lib и поместить туда все библиотеки, перечисленные в выводе ldd, создать /var/run/ld-so.hints командой ldconfig. С моей точки зрения, пересобрать программу значительно проще.

В каталог /etc помещаются файлы group и master.passwd. Из файла group удаляются все реальные пользовательские группы, важно, чтобы там присутствовала группа, прописанная как ChrootGroup в конфигурационном файле SSH-сервера. Из файла master.passwd удаляются все пользователи с паролями, пароль root заменяется на «*». После чего создаются файлы passwd, pwd.db и spwd.db командой:

>pwd_mkdb -p -d . master.passwd

Теперь файл master.passwd можно стереть. Кроме того, в конфигурационном файле SSH-сервера указывается группа, к членам которой будет применяться chroot (по умолчанию это группа sftp):

ChRootGroups     sftp,guest

Кроме того, проследите, чтобы параметр AllowedAuthentications содержал publickey, а RequiredAuthentications не содержал password. Еще лучше, чтобы он был удален или закомментирован. Как убедиться в том, что сессия идет в chroot? В файле регистрационного журнала SSH-сервера об этом делается специальная отметка:

connection from "192.168.1.1"                                              

Public key /usr/local/share/rmbackup/.ssh2/rmbackup_mybox.pub used.     

Public key authentication for user rmbackup accepted.                    

User rmbackup, coming from mybox, authenticated.              

User "rmbackup" will be chrooted to directory "/usr/local/share/rmbackup".

Now running on rmbackup"s privileges.

Предварительная подготовка завершена. Мы настроили компьютеры, с которых (и на которые) будут копироваться данные таким образом, что можно выполнять команду на удаленном компьютере через SSH2 без ввода паролей с помощью авторизации по публичному ключу.

Настройка скрипта

Настройка скрипта выполняется через задание переменных в конфигурационном файле /etc/periodic.conf. Эти переменные используются скриптом резервного копирования, упомянутым в начале статьи, и скриптом, описываемым в данной статье.

Скрипт использует следующие переменные:

daily_backup_owner="rmbackup" # Owner of backup files

daily_backup_group=”wheel” # Group of backup files

daily_backup_mode="0600" # Mode of backup files

daily_backup_dirmode="0700" # Mode of intermediate dirs

Это соответственно переменные, задающие пользователя, группу, режим доступа к файлам и каталогам, создаваемым скриптами. Скрипт не устанавливает значения переменных по умолчанию, поэтому все переменные должны быть заданы в /etc/periodic.conf или /etc/defaults/periodic.conf.

Заголовок и вспомогательные функции

#!/bin/sh

# Safe updating, so – copying current daily backup directory from remote server to local. Used SSH2 publickey auth

# method, so you need a working installation before starting. This is an open-source software, licenced by BSD license.

# Written by CityCat 23.07.2004

# $Id: safecopy,v 1.5 2004/08/10 04:26:40 shelton Exp $

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

В приведенном выше заголовке нет ничего необычного. Переустановка переменной PATH нужна для того, чтобы находить программу SSH2, даже если пользователь ее изменил.

# Logging function

# Logged string in variable logline!

safe_logger()

{

  logdate=`date +"%d/%m/%Y %T"`

  echo "$logdate [$$] safering: $logline" >> $logfile

}

Функция записи информации в регистрационный журнал, который ведется программой, имитирует работу программы logger и формирует в журнале записи такого формата:

07/08/2004 05:00:02 [70241] safering: File _etc.tar.bz2 from host mybox was succesfully transferred

при этом выводимая в журнал строка передается в переменной logline.

# Go down function

# Set variable godown to downing directory name

go_down()

{

  if [ ! -e $godown ]; then

    mkdir $godown

    chown $daily_backup_owner:$daily_backup_group $godown

    chmod $daily_backup_dirmode $godown

  fi

  cd $godown

}

Функция перехода в подкаталог, задаваемый переменной godown. Если каталог отсутствует, он будет создан, и ему будут установлены права доступа, заданные в конфигурационном файле.

# If there is a global system configuration file, suck it in.

#

if [ -r /etc/defaults/periodic.conf ]; then

  . /etc/defaults/periodic.conf

  source_periodic_confs

fi

Загрузка значению по умолчанию для скрипта, если они заданы (обычно вписываются в /etc/defaults/periodic.conf).

Переменные

Единственная переменная, которую имеет смысл настраивать в скрипте, вынесена перед строкой предупреждения. Разумеется, все остальные переменные тоже можно менять – это же скрипт. Но все же делать это не рекомендуется без понимания механизма его работы.

# Variables

# There is only maintained variables!

# This is a root folder for all subordinated folders

sysdir="/usr/local/share/rmbackup"

# NO CHANGES BEHIND THIS LINE!! YOU HAVE BEEN WARNED!!

backupdir="backup"

ringdir="$sysdir/backup"

maintdir="$ringdir/maint"

hostlist="$maintdir/cphosts"

logfile="$maintdir/saferlog"

wsyear=`date +"%Y"`

wsmon=`date +"%m"`

wsday=`date +"%d"`

# We assumed SSH2 by SSH Com. presence and locating config in /usr/local/etc/ssh2

openssh=0

sshconf="/usr/local/etc/ssh2/ssh2_config"

sshome="$HOME/.ssh2"

scpname=scp2

Итак:

  • Переменная sysdir указывает корневой каталог системы кольцевого копирования. Обычно это домашний каталог пользователя rmbackup, хотя можно указать любой другой. В этом каталоге будут располагаться все остальные каталоги.
  • Переменная backupdir указывает на каталог с резервными копиями на удаленном компьютере.
  • Переменная ringdir указывает на каталог с резервными копиями на мастер-компьютере.
  • Переменная maintdir указывает на каталог с регистрационным журналом, списком компьютеров, с которых будут копироваться данные, и собственно скриптом.
  • Переменные hostlist и logfile задают соответственно имена файлов списка компьютеров и регистрационного журнала.
  • Переменные wsyear, wsmon и wsday хранят текущие год, месяц, день.
  • Переменная openssh указывает на то, что SSH, обнаруженный скриптом, является OpenSSH (используется для адаптации путей и работы с конфигурационными файлами).
  • Переменная sshconf указывает на расположение конфигурационного файла SSH по умолчанию.
  • Переменная sshome указывает на пользовательский каталог с настройками, ключами и т. д. для SSH (имена каталогов отличаются в SSH2 и OpenSSH).
  • Переменная scpname задает имя программы безопасного копирования SCP (в SSH2 и OpenSSH они отличаются).

Проверка командной строки и обнаружение SSH

# Check commandline

if [ $# -ne 0 ]; then

  if [ $1 = "-h" ]; then

    echo "Safering updater. Copying current daily backup dir from remote server."

    echo " Usage: safecopy [hostlist-location-and-name]."

    exit

   else

     hostlist=$1

  fi

fi

# Check on presence SSH in system and detect their version

wssh=`which ssh2'`

if [ -z $wssh ]; then

  wssh=`which ssh'`

  if [ -z $wssh ]; then

    logline="No any SSH program was detected, install it first"; safe_logger

    exit

   else

     wsver=`$wssh | awk '{printf "%s %s %s",$1,$2,$3}'`

     sshome="$HOME/.ssh"

     scpname=scp

     wsx=`$wssh | awk '{print $3}'`

     if [ $wsx = "SSH" ]; then

       openssh=1

       sshconf="/etc/ssh/ssh_config"

      else

        logline="Broken SSH1 from SSH Communicationc Inc. probably detected"

        safe_logger

        exit

     fi

  fi

 else

  wsver=`$wssh -V 2>&1 | awk '{printf "%s %s %s %s",$2,$3,$4,$5}'`

fi

# Log detected version

logline="Detected version: $wsver"; safe_logger

Допустимыми параметрами командной строки являются -h или имя файла со списком компьютеров, с которых производится копирование. Если имя файла не задано, будет использоваться файл cphosts в каталоге $maintdir.

Первым делом ищется программа ssh2 (which ssh2). Если она найдена, то выбирается информация о версии (переменная wsver будет содержать «SSH Secure Shell x.x.x.x», где x.x.x.x – номер версии SSH), и полученная информация выводится в регистрационный журнал. Если же она не найдена, производится попытка обнаружить программу ssh (which ssh), и если она найдена, проверяется, что за программа обнаружена. Если это OpenSSH (определяется по характерному признаку – третье слово при запуске без параметров содержит «SSH»), то переменные sshome, scpname, sshconf и openssh устанавливаются в соответствующие значения. Иначе скрипт завершает работу, поскольку работа с SSH1 от SSH Communications не поддерживается (по причине его небезопасности).

Проверка наличия файла идентификации и разбор списка компьютеров

Как уже говорилось выше, файл идентификации обязательно должен быть создан, если предполагается использовать авторизацию по публичному ключу. Поэтому отсутствие данного файла обозначает ситуацию, когда авторизация по публичному ключу еще не была настроена.

# Taking identity file name, drop down comment field

identity=`grep IdentityFile $sshconf`

idfirst=`echo $identity | awk "{print $1}"`

if [ $idfirst = "#" ]; then

  idfile=`echo $identity | awk "{print $3}"`

 else

  idfile=`echo $identity | awk "{print $2}"`

fi

# For OpenSSH drop down path from pathname

if [ $openssh -eq 1 ]; then

  idname=${idfile##*/}

 else

   idname=$idfile

fi

# Check on existance identification file. When doesn"t – SSH dodn"t setup to work with publickey auth method

if [ ! -e $sshome/$idname ]; then

  logline="Publickey auth method did not configured yet"; safe_logger

  exit

fi

Скрипт проверяет наличие параметра IdentityFile в конфигурационном файле сервера (даже если он отмечен знаком комментария). Для OpenSSH дополнительно отбрасывается путь к IdentityFile, если он там указан. Потом проверяется существование файла, описанного как IdentityFile. Если он не существует, скрипт прекращает работу.

Разбор списка компьютеров осуществляется установкой переменной IFS в значение « ». Для этого не нужно писать «IFS=” ”» – shell не интерпретирует метасимволы. Следует написать «IFS=”», нажать «перевод строки» и закрыть кавычку – внутри кавычек окажется символ перевода строки. После считывания файла организовывается стандартный цикл по списку переменных-строк:

# Taking hosts list

IFS="

"

hosts=`cat $hostlist`

cd $ringdir

# Doing safering update

for host in $hosts

 do

Разбор строки и получение списка файлов для копирования

# Parse host line

   hostname=`echo $host | awk "{print $1}"`

   hostadr=`echo $host | awk "{print $2}"`

   fullpath=$backupdir/$wsyear/$wsmon-$wsyear/$wsday-$wsmon-$wsyear

# Take list of files to backup

   wls=`$wssh -o "BatchMode yes" -q $hostadr "cd $fullpath 2> null && /bin/ls -1"`

Один из двух наиболее важных моментов. Скрипт копирования файлов создает каталоги вида YYYY/MM-YYYY/DD-MM-YYYY, где YYYY – текущий год, MM – текущий месяц, DD – текущий день. Можно было бы, конечно, создавать папки типа YYYY/MM/DD, но мне удобнее просматривать список в mc, когда видна полная дата. В переменной wls после выполнения команды будет результат команды «перейти в заданный каталог и получить список файлов в нем». Если предполагается копировать нечто другое, следует задать соответствующий путь в переменной fullpath.

Если команда завершилась аварийно, то список будет пуст, и скрипт перейдет к другому узлу из списка или завершит работу, если этот список уже кончился. Результат выполнения последней команды хранится в переменной status. Если команда выполнена успешно, то выполняется последовательный переход в каталоги: имя удаленного компьютера, YYYY, MM-YYYY, DD-MM-YYYY, например: cd myhost; cd 2004; cd 12-2004; cd 15-12-2004. Если такой каталог отсутствует, он создается с правами, заданными параметрами. Мы говорили об этом в разделе «Настройка скрипта».

# When list is empty, do nothing

# (and don"t create directories)

   status=$?

   if [ $status -ne 0 ]; then

     continue

    else

# Go down the ladder

      godown=$hostname; go_down

      godown=$wsyear; go_down

      godown=$wsmon-$wsyear; go_down

      godown=$wsday-$wsmon-$wsyear; go_down

   fi

Пофайловое копирование

 for file in $wls

    do

      $scpname -q -Q $hostadr:$fullpath/$file . 2> null

      status=$?

# Check on operation return code

      if [ $status -ne 0 ]; then

        logline="Transfer of file $file unsuccesful, return code is $status"; safe_logger

       else

         logline="File $file from host $hostname was succesfully transferred"; safe_logger

         chown $daily_backup_owner:$daily_backup_group $file

         chmod $daily_backup_mode $file

      fi

    done

# Return to top

 cd $ringdir

 done

Последнее и самое важное действие скрипта – поочередное копирование файлов из списка, полученного на предыдущем шаге. Выполняется команда scp, и результат ее работы заносится в переменную status. В зависимости от значения переменной status выдается сообщение либо об успешном завершении копирования (при этом устанавливаются права и режим доступа, соответствующие параметрам, перечисленным в пункте «Настройка скрипта»), либо об аварийном завершении (и тогда в журнал заносится код ошибки, расшифровку которого можно посмотреть в man ssh2).

Возможные ошибки и изменения скрипта

Если скрипт работает не так, как ожидается, то, скорее всего, имеет место ошибка в настройке SSH (по крайней мере, почти все ошибки, с которыми я сталкивался после завершения его разработки, были такого плана). Это очень просто проверить – достаточно с консоли мастер-компьютера набрать ssh remotebox, где remotebox – имя любого компьютера, с которого должны копироваться данные. Если сразу же открывается терминал удаленного компьютера – все нормально (при этом motd показываться не должно). Если же появляется запрос пароля на разблокирование ключа, запрос пароля на регистрацию на удаленном компьютере или какие-либо сообщения об ошибках – следует устранить ошибки и повторить.

Единственной ошибкой, которую можно совершить при генерации ключа, является запуск ssh-keygen2 без ключа -P. При этом при генерации ключа будет запрошен пароль. Если при генерации ключа появился запрос пароля, лучше генерацию прервать и запустить ssh-keygen2 заново с ключом -P.

Самой распространенной ошибкой авторизации является то, что ключ мастер-компьютера не помещен в каталог .ssh2 пользователя rmbackup удаленного компьютера, не описан в файле authorization, или в имени ключа допущена банальная опечатка. Если ключ для пользователя rmbackup создавался через su rmbackup от пользователя root, возможно, установлены неверные права на файлы identification и authorization (при создании файлов владельцем становится создатель). Второй распространенной ошибкой является задание параметра RequiredAuthentication password в конфигурационном файле sshd.conf на удаленном компьютере, требующего обязательной аутентификации по паролю.

Если терминальная сессия на удаленном компьютере открывается нормально, то следует попробовать вручную ввести команду (вместо 192.168.1.1 подставить IP или имя компьютера, с которого должны быть получены файлы):

>su rmbackup

>ssh2 -o "BatchMode yes" -q 192.168.1.1 "cd /etc && /bin/ls -1"

Если в результате выполнения этой команды получается оглавление каталога /etc (в chroot это файлы group, passwd, pwd.db и spwd.db) – значит, следует проверить работу scp. Иначе следует проверить файл журнала, в который выводятся сообщения от SSH-сервера на удаленном компьютере на предмет сообщений об ошибках и устранить их.

Если предыдущая команда завершена успешно, следует проверить работу команды scp следующим образом (заменить 192.168.1.1 на IP-адрес или имя компьютера, с которого должны быть получены файлы. Файл .profile должен существовать на удаленном компьютере):

scp2 192.168.1.1:.profile  ./profile-tmp

(Внимание! Точка – элемент команды!)

Если в текущем каталоге появился файл .profile-tmp, следует уточнить код ошибки по руководству к ssh2 (man ssh2) и устранить ошибки. Если же нет – проверить файл журнала, в который выводятся сообщения от SSH-сервера на удаленном компьютере на предмет сообщений об ошибках, и устранить их. Здесь наиболее частой ошибкой может быть неверный sftp-server2, который не собран в соответствии с рекомендациями раздела «Дополнительные вопросы безопасности», а просто переписан и для работы требует наличия динамического загрузчика, libc и пр.

Как можно изменить место, откуда берутся копируемые файлы на удаленном компьютере? Для этого достаточно изменить формирование переменной fullpath, описанной в разделе «Разбор строки и получение файлов для копирования».

Как можно изменить место и организацию каталогов, в которые раскладываются файлы на мастер-компьютере? Для этого в функцию go_down передается значение переменной godown – каталог будет создан по ее содержимому. Можно вообще все складывать в один каталог – для этого нужно закомментировать строки с «godown=...; go_down».

Заключение

Данный скрипт – инструмент системного администратора из разряда «настроил и забыл». После его настройки он не требует какого-либо сопровождения, кроме, пожалуй, регулярного резервного копирования каталога с файлами, скопированными с удаленных компьютеров. Ну и, конечно, обеспечения необходимых мер безопасности по отношению к каталогу, в котором хранятся резервные копии. Разумеется, он разрабатывался для решения определенной частной задачи, но его нетрудно адаптировать для копирования чего угодно откуда угодно. Ошибки в самом скрипте исключены ввиду его достаточной простоты, как правило, все ошибки связаны с ошибками самого SSH.

Дополнительная информация:

  1. Daniel J. Barrett, Richard Silverman. SSH, the Secure Shell: Definitive Guide. O’Reilly & Associates, 2001, 558 pages. ISBN: 0-596-00011-1.
  2. http://www.ssh.fi/support/documentation/online/ssh/adminguide/32 – SSH Secure Shell for Servers Version 3.2 Administrator’s Guide.
  3. http://www.opennet.ru/docs/RUS/ssh_faq – Faq по SSH в русской редакции. Русская редакция: Андрей Лаврентьев (lavr@unix1.jinr.ru).
  4. man ssh2, man sshd2, man ssh.conf, man sshd.conf, man ssh-keygen2.

Комментарии
 
  20.06.2008 - 02:02 |  FAIRY

Собственно, в начале статьи приведены ссылки на пример скрипта и его полный текст. Обе ссылки не работают. Буду признателен, если кто подскажет, откуда можно скачать!

  20.06.2008 - 12:01 |  citycat4

ничего удивительного - я уже давным-давно в Гранче не работаю. Скрипт можно скачать с http://www.askd.ru/~shelton/fileZ/safecopy, скрипт для periodic, упоминаемый в начале статьи - с http://www.askd.ru/~shelton/fileZ/130.backup-dirs

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru