Итак, если кратко, то надо сгенерировать закрытый и открытый ключи на стороне, где будем запускать скрипты (назовем такую машину «клиент»), положить открытый ключ туда, куда будем коннектится (назовем его условно «сервер») и настроим, чтобы сессия для такого-то аккаунта Unix запускалась не от Unix пароля, а от ключа (с паролем, но ниже будет показано, как настроить, чтобы вводить его однократно за весь день, например)

1. На стороне клиента генерируем ключ типа DSA:

   mkdir -p ~/.ssh
   chmod 700 ~/.ssh
   cd ~/.ssh
   ssh-keygen -t dsa
   Enter passphrase (empty for no passphrase): …
   Enter same passphrase again: …
   chmod go-rwx ~/.ssh/*

   Я рекодмендую обязательно указать пароль. Рекомендуется указывать пароль, который не используется для аккаунта Unix. Если вы не укажите пароль (сделаете пустым), то любой, кому попадет ваш закрытый ключ-файл, сможет зайти на удаленный сервер под вашим аккаунтом без всяких проблем. Конечно, чтобы файл попал к кому либо, надо, чтобы были нарушены права доступа в Unix. Но файл может «утечь» случайно с утилитами синхронизации, бекапа или т.п.. Далее, я расскажу, как настроить, чтобы вы сами в дальнейшем не вводили часто пароль для закрытого ключа.

2. Копируем ключ на сервер:

   scp -p id_dsa.pub remoteuser@remotehost:
   Password: ********

3. На уделенном сервере делаем:

   ssh -l remoteuser remotehost
   Password: ********
   mkdir -p ~/.ssh # Создать директорию, если ее нет
   chmod 700 ~/.ssh
   cat id_dsa.pub >> ~/.ssh/authorized_keys  # Добавление к файлу, если он уже есть
   chmod 600 ~/.ssh/authorized_keys
   mv id_dsa.pub ~/.ssh # Не обязательно, но можно сохранить открытый ключ на всякий случай
   logout

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

4. Следующий шаг – настройка ssh-agent. Он может нам понадобится, если мы не хотим постоянно вводить пароль для закрытого ключа. Если же вы на шаге 1 указали пустой пароль, то можете пропустить 4 -6 пункты – вам не потребуется демон ssh-agent для кеширования пароля – его попросту нет – он не будет запрашиваться утилитами, использующими протокол ssh, и все эти утилиты могут работать из скриптов прямо на этом этапе.
   Демон ssh-agent висит в памяти и за операциями подписи и криптования к нему обращаются программы ssh & scp (и другие). Этот демон хранит в своей памяти ваш пароль для закрытого ключа определенное время, заданное вами. Это очень удобно, если вы повседневно используете openssh, например, даже для git pull & git push.

   crontab -e

   Вставляем в редакторе в crontab файл:

   @reboot ssh-agent -s | grep -v echo > $HOME/.ssh-agent

   Эти команды говорят крону, что во время ребута системы запустить ssh-agent, а его вывод – переменные среды окружения с настройками записать в файл $HOME/.ssh-agent. Этот файл необходим нам для того, чтобы программы ssh, scp знали, куда коннектится (в них сохраняются пути до Unix сокетов коммуникации с ssh-agent).
   Чтобы нам не ждать перезагрузки, запускаем демон сразу же:

   nohup ssh-agent -s > ~/.ssh-agent

5. Теперь, в ваши скрипты, которые используют ssh & scp, надо добавить такую строку:

   . ~/.ssh-agent

   Также, рекомендую добавить следующие строки в ~/.bashrc (для bash shell-а):

   . $HOME/.ssh-agent
   alias keyon="ssh-add -t 10h"
   alias keyoff='ssh-add -D'
   alias keylist='ssh-add -l'

   Тем самым, при заходе на клиентскую машину ssh сессией, у вас загрузятся настройки для работы с ssh-agent, а также определятся алиасы команд для повседневной работы. Например, выполнив в bash команду «keyon», от вас ssh-add команда потребует ввести пароль для ключа. После ввода он будет еще работать 10 часов. В это время вы можете запускать команды ssh, scp и любые другие, что используют ssh для коннекта на сервер (rsync, git), и все эти команды будут работать без запроса пароля.

6. Второй вариант настройки ssh-agent (если его выбираете, можете пропустить пункты 4 и 5):
   В файле ~/.bash_profile прописываем:

   SSHAGENT=/usr/bin/ssh-agent
   SSHAGENTARGS="-s"
   if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
   eval `$SSHAGENT $SSHAGENTARGS`
   trap "kill $SSH_AGENT_PID" 0
   ssh-add
   fi

   Этими командами вы говорим при логине, если если нет таких-то переменных, запустить ssh-agent, выполнить команды вывода ssh-agent в текущем шеле (eval), а по завершении shell-а пристрелить процесс ssh-agent-а (trap). Здесь также при логине у вас единожды запросится пароль для ключа. Затем он будет в памяти ssh-agent

Подробнее и всесторонне об ssh-agent можете прочитать в статье Mark A. Hershberger

Также рекомендуется к чтению:

1. 20 советов по безопасному использованию сервера OpenSSH
2. OpenSSH Public Key Authentication

Итак, что же это за такая rsync? Это действительно, утилита рекурсивного копирования (копирует все файлы и поддиректории) с одного хоста на другой, или даже внутри одной машины. На этом все ее отличие от, например, утилиты cp заканчивается. И вот тут самое интересное – она при копировании каждый файл или директории, которые копируем, проходит блоками, и отслеживает только изменения блоков в сравнении с уже скопированными блоками. Грубо говоря, она копирует только «дельты» файлов и директорий! Что это значит? Это значит, что второй, третий и так далее запуски этой программы на определенную цель (куда копировать) будут занимать гораздо меньше времени, операций копирования и передачи данных по сети при повторном копировании уже изменившихся файлов. Вот несколько примеров ее использования:

1) Быстрый перенос баз данных (на примере SQL).

Имеем два сервака – один рабочий A, второй Б – куда будем резервировать свои базы данных (там где нет работающего SQL). Тогда для резервирования можно периодически запускать rsync на сервере A, не прекращая работы SQL сервера (назовем это «рабочим резервом»). Но чтобы нам иметь полностью правильные базы в резервной директории сервера Б, нам надо временами останавливать SQL на серваке А, и пока там нет работаюшего SQL, делать повторное копирование (назовем это «фиксированным резервом»). Вот тут то rsync и пригождается! Во время «рабочего резерва» многие файлы успевают устареть, ведь SQL продолжает работать. Во время «фиксированного резерва» копируются только дельты с последнего запуска «рабочего резерва». Если время между этими запусками мало, то дельты копируются очень быстро – на больших базах это может быть не более минуты, например. Для снижения времени простоя, надо просто выполнить повторный «рабочий резерв» прямо перед остановкой MySQL сервера. Плюсы такого способа – минимальный даун по времени, минимум человеческих ошибок, простота. Я не знаю другого способа на данный момент, чтобы сделать быстрый резерв больших баз данных на другую машину, и при этом свести время простоя к минимуму.

Команды (смотрите не перепутайте! Тут все как в теории относительности )
На стороне сервера Б (можно и на стороне А, но тогда надо поменять пути местами), куда копируем, запускаем команды копирования во время «рабочего резерва»

cd
nohup /bin/nice -n 20 ionice -c3 rsync --rsync-path='/bin/nice -n 20 ionice -c3 rsync' -avz --delete IP.ADDRESS.SERVER.A:'/path/to/source/folder/' /path/to/target/folder/

Краткие пояснения (ВАЖНО):
Некоторые утилиты могут отсутствовать, примеры даны для Linux! Здесь nohup – «оторвать» ввод/вывод от терминала. Это нам потребуется, когда мы захотим оставить запущенный «резерв» в фоновом режиме. Сразу мы не можем этого сделать (то есть не ставлю ‘&’ в конце), так как rsync при копировании использует ssh, и раз мы копируем на другой сервак, он запросит у нас пароль (если авторизация через openssh ключи + ssh-agent, то можно и поставить ‘&’, но об этом в другой раз, в другой статье). После ввода пароля уже можно будет нажать Ctrl+Z в shell и затем "%1 &" для запуска в фоновом режиме первой запущенной задачи (см. man bash). Команда nice – выставить приоритет для процессора, а ionice – приоритет для операций при работе с диском – все приоритеты ставяться на понижение, чтобы продолжалась нормальная работа сервера. Опция --delete для rsync – удалять все файлы в целевой директории (от слово «цель», target), которых нет в исходной (source). То есть, после копирования получим полностью равную директорию по содержанию.
Слеш в конце исходной директории (/path/to/source/folder/)  – важная штука! Если в конце слеш – директория рассматривается rsync-ом как комплект директорий и файлов в ней для копирования, а если слеша нет – как один объект, целая директория со своим именем – в обоих случаях копирование рекурсивное, но если из примера убрать слеш в конце первого пути (сделать /path/to/source/folder), то в /path/to/target/folder/ будет создана папка folder и туда скопируется ее содержимое! Почитайте man-ы, если хотите понять, как присутствие или отсутствие слешей в конце директории влияет на ход событий

2) Перенос сайтов.

Способом, описанным выше, также можно переносить и сайты вместе с их базами. Для баз мы используем способ выше, а для переноса контента делаем все то же самое, но при работающем apache. Как и в первом способе, apache мы останавливаем только на несколько минут или секунд, быстро запускаем rsync для «фиксированного резерва», а после окончания запускаем apache снова. После остается сменить только DNS на новый IP адрес и все! Для повышения скорости переноса не забудьте за неделю до переноса выставить часовой TTL в вашем DNS для SOA записи зоны и для всех ее остальных записей. Тогда при смене IP весь трафик на сайт переместится за один час! Но это, как говориться, уже другая история.

Если вы работаете раз от разу в bash, tcsh и других shell-ах, вы можете не знать про следующие, но очень удобные команды, которые облегчать вам жизнь под Unix:

• Ctrl + A – переход в начало текущей строки;
• Ctrl + E – переход в конец текущей строки;
• Стрелка вверх / Стрелка вниз - хождение по history командам соответственно к более старым командам / к более новым (это вы навярняка знаете)
• Ctrl + U – стирает все слева от текущей позиции курсора, то есть чтобы быстро очистить строку, можно сделать Ctrl + E и затем Ctrl + U
• Esc -> d – стирает слово справа (сначала нажимаем Esc, отпускаем, затем ‘d’)
• Tab - формирует законченный вид не до конца набранной команды, файла или директории. Для MySQL -  еще таблицы, имени колонки. Если нет однозначности, то после повторного нажатия Tab выдаются варианты. Очень ускоряет процесс работы в командной строке, если вы не знали про это
• Ctrl + PageDown - переход к самой последней (свежей) команде в history
• Ctrl + PageUp - переход к самой старой (первой) команде history
• Ctrl + R - самая ценная команда для меня – поиск в history. Делается так: нажимаем Ctrl + R, появляется приглашение ввести подстроку поиска ( (reverse-i-search)`’: ), далее мы вводим, например, «mysql» – видим самую последнюю команду shell-а, где встречалось подстрока «mysql». Если она нас не устраивает, то для повтора поиска тут же надо снова нажать Ctrl + R. Каждое нажатие Ctrl + R перемещает нас к более старым командам с подстрокой «mysql», которые мы когда либо исполняли. Если же нас найденная команда устраивает, нажимаем «Стрелка вправо» или «Стрелка влево» и приступаем к редактированию и исполнению команды. Это очень удобная и нужная команда!

Все эти команды – подмножество команд библиотеки readline (man 3 readline). Ее используют и другие программы, например MySQL. Но в MySQL есть то ли баг, то ли так задумано разработчиками. Суть ее в том, что MySQL версий 3.x, например, прекрасно исполнял команду поиска (Ctrl + R), но потом, по каким то причинам, новые релизы – MySQL 4.x & 5.x перестали работать с поиском. Скорее всего, это связано с тем, что раньше MySQL использовал readline библиотеку, но потом разработчики перешли на editline. И последняя перестала работать с поиском. Я долго мучался, пока не нашел решение. Оно следующее:

Создать файл ~/.editrc – конфиг для editline. Там мы пишем следующие строки:

bind «\e[3~» ed-delete-next-char
bind «^R» em-inc-search-prev

После этого в MySQL 4.x & 5.x у нас будет работать Ctrl + R.

Другим решением для MySQL вместо редактирования .editrc будет использовать rlwrap программу (установка в Linux Fedora Core, например, такая: yum install rlwrap) – она «обертывает» stdout запускаемой программы и создает history для вводимых строк (хранит в ~/.commandname_history). У нее есть некоторые недостатки – на ввод паролей она делает echo, то есть пароль будет виден на экране. Можно с помощью опций отключить это, но это не идеально. Зато можно в нее обернуть любую программу, которая даже не имеет history вообще (rlwrap perl -MCPAN -e shell , например). Итак, второе решение для MySQL может быть таким:

alias mysql=’rlwrap -a mysql’

Это ставиться в ~/.bashrc, например. Или вместо алиаса можно просто запустить:

rlwrap -a mysql -uroot -p mysql

Man на rlwrap вы можете найти на сайте разработчика.

Вот такие вот тонкости, которые на 100% облегчат вам работу в Unix.

Но тот один пакет, который она пропускает, валит систему на 9 месяцев…

И вот, наконец, сегодня я прочел грамотную доку, а также в другом месте нашел объяснение моим проблемам. Оказывается, в sed есть очень мелкие, но важные отличия, поняв которые, вы сможете писать sed команды легко.

Итак, оказывается, по историческим причинам, чтобы не нарушать работу старых sed команд, в sed группировка (‘(‘, ‘)’) и некоторые другие спец. символы (‘+’ , ‘?’) были заменены на символы со слешем. Вот эти отличия:

Самое главное, на чем я спотыкался всегда – я никак не мог додуматься, что ‘\’ должен ставиться перед ‘(‘, или перед ‘?’ и ‘+’ символами, например. Я видел иногда эти слеши в примерах, но я думал, что эти слеши относились к shell, но оказалось, что это тонкость sed-а.

P.S. Возникает вопрос, а как же тогда заменять сами символы: «?+{}()» в sed? А оказывается, их просто не надо ескейпить символом ‘\’. Получается как бы наоборот – эти символы сами по себе не ескейпяться, а когда нужно их специальное назначение, то перед ними ставим ‘\’. Типа все с ног на голову, если сравнивать с perl.