 |
|
|
|
Копирование файлов в автоматическом режиме с множества компьютеров через 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
Проверка того, что авторизация настроена правильно, очень проста – набираете команду ssh remote на мастер-компьютере, где remote – имя или адрес удаленного компьютера. Удаленная SSH-сессия должна начаться сразу же, без дополнительных запросов пароля. Если появится запрос пароля на разблокировку ключа: >ssh mybox
значит ключ был сгенерирован с паролем. Такой ключ следует удалить и создать заново, но без пароля (см. пример выше). Если же появляется стандартный запрос пароля: >ssh mybox
значит, существуют проблемы в настройке авторизации. В разделе «Возможные ошибки и изменения скрипта» приведены примеры того, что может пойти не так во время настройки, и некоторые советы по исправлению создавшегося положения. Дополнительные вопросы безопасности Поскольку созданный нами публичный ключ не имеет парольной защиты, то всегда существует ненулевая вероятность, что данный ключ может быть похищен и использоваться не по назначению. Для того чтобы сделать такую возможность как можно менее привлекательной, пользователя, от имени которого выполняется копирование, поместим в 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:
значит, это динамически собранный исполняемый файл, и он не годится. На самом деле его тоже можно использовать. Но для этого придется создать /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-сервера об этом делается специальная отметка:
Предварительная подготовка завершена. Мы настроили компьютеры, с которых (и на которые) будут копироваться данные таким образом, что можно выполнять команду на удаленном компьютере через 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 и формирует в журнале записи такого формата:
при этом выводимая в журнал строка передается в переменной 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 Итак:
Проверка командной строки и обнаружение 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. Дополнительная информация:
|
РАШИД АЧИЛОВ| Комментарии |
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
