bookmarks-on-tranquilizers

Я труслив :) Во-первых, я делаю бэкапы. Во-вторых, я их боюсь передать без шифрования и, в третьих, иногда и храню их зашифрованными.

Как правильно организовать передачу бэкапов с одного сервера на другой? Дампы этого блога у меня передаются по http. Они зашифрованны, да и особо ценных данных здесь нет, поэтому http меня не смущает. А как поступить с данными по-важнее? Конечно, ssh. А как при этом запретить пользователю выполнять какие-либо действия, кроме как копирования к себе бэкапа? Представим себе, что бэкап-сервер находится во вражеском дата-центре или просто вы не можете проконтролировать к нему доступ (в т.ч. физический). Нас выручит опция command файла authorized_keys.

Например, если необходимо предоставить доступ только к файлу backup.tgz, то в authorized_keys в самом начале соответствующей строки можно дописать следующее “command=’cat backup.tgz’”. Теперь при каждом коннекте будет автоматически выполняться команда cat backup.tgz, вам остается только перенаправить вывод в файл. Если дампов несколько, то можно написать небольшой скриптик вида:#!/bin/sh
read file
case "$file" in
"foo") cat foo.tgz ;;
"bar") cat bar.tgz ;;
esac И прописать его в качестве команды по умолчанию. Да, не лишним было бы добавить опции no-port-forwarding, no-pty и все прочие no-*

Теперь копировать файл с удаленной машины можно вот такой командой:echo "foo" | ssh backup@server > foo-`date +%Y-%m-%d`.tgz

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

По-моему, все, что я описал примитивно по сложности и вместе с тем весьма надежно. Так может быть прекратим без надобности дописывать authorized_keys на серверах? Одна запись для себя, любимого, одна для бэкапов, одна для мониторинга.. ой, еще каких-то две.. дальше продолжать? :)

Кстати, а есть ли способы более тонко настраивать уровень доступа к ssh?

А получится sshfs.
sshfs позволит вам монтировать каталоги на удаленных машинах по протоколу SFTP; пользоваться им настолько просто, что даже рассказать в этой заметке практически нечего: ни тебе интрижки с накладыванием патчей и сборкой пакета, ни тебе объектного языка конфигурационных файлов. Тоска, одним словом.

Но для sshfs это, вобщем-то, плюс. Итак, начнем с установки пакета и добавления себя в группу fuse, делается это так:
apt-get install sshfs
sudo adduser your_name fuse


Команда adduser в таком контексте ничего, кроме добавления уже существующего пользователя в группу не делает, так что не нужно смущаться от ее неожиданного выхода на сцену. После этого нам нужно перелогиниться, чтобы изменения в /etc/group вступили силу.

Мне пришлось выполнить еще одну операцию: сменить группу у устройства /dev/fuse. Я думаю, это особенность лично моего дистрибутива, но если у вас тоже попытки монтирования будут завершаться ошибкой “что-то там permission denied”, то вот вам команда:
chgrp fuse /dev/fuse
По-хорошему, ее надо прописать куда-нибудь в автозагрузку, например, в /etc/rc.local.

Теперь все готово для монтирования:
mkdir mount_point
sshfs remoteuser@remotehost:/some/folder ~/mount_point
ls mount_point


Ну вот, собственно, и все, можно работать.

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

В итоге, мы имеем отличную замену scp/sftp или fish (встроенная в mc и konqueror оболчка для sftp) для случаев, когда нужно выполнить действия посложнее, чем копирование.

Дальнейшее чтение: FAQ по sshfs, Другие основанные на fuse файловые системы

Как всегда, существует уйма способов запускать графические программы удаленно. Не все из них основаны на туннелинге X-трафика, но именно с ним играться интересней всего.

Приступим :)

Собственно, на практике страшная фраза “сделать туннелинг Х-протокола” обозначает, что нужно добавить опцию X к ssh. Получается, что в простейшем случае запустить удаленную графическую программу можно так:
ssh -X user@host firefox

Kdesktop от других программ ничем не отличается:
ssh -X user@host kdesktop

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

Я это сделал так:
xinit /usr/bin/ssh -X user@host startkde -- :1
Набирать команду следует из обычной, неиксовой консоли (Ctrl-Alt-F1), и работать она будет только в случае, если на удаленной машине уже лежит наш публичный ключик, т.к. не будет возможности ввести пароль. (что такое публичный ключ). Полный путь к ssh на некоторых дистрибутивах обязателен.

Теперь сочетанием клавиш Ctrl-Alt-F7 и Ctrl-Alt-F9 можно переключаться между локальным и удаленным рабочим столом (хотя F9 для удаленной машины – это лично у меня, у вас может быть также F8 или F10). Да, и делать это лучше только если соединение между машинами быстрое, иначе нервных расстройств не избежать :)

Этот пост написан с рабочего десктопа, но через ноутбучную оперу :)

А что интересного с помощью ssh удавалось сделать вам?

UPD через 20 мин: Отправил ноутбук в ребут и через некоторое время понял, что работаю на удаленной машине. 5 секунд паники, 10 – на сохранение и минута чтобы понять, что я ошибся :) Вобщем, для людей со слабым сердцем не рекомендую так работать, а сам я теперь осторожен, как сапер на минном поле :)

[5]. Допустим, есть огромный (5Gb) файл, из которого нужно извлечь все строки, содержащие слово “error”, а также посчитать md5 и количество строк. Можно сделать это в пять приемов и потратить полчаса, но есть способ проще и быстрее:
#cat big_file | tee >(md5) >(wc -l) | grep "error" > big_file_errors
Т.е. все нужные действия производятся за один цикл чтения!

Таким же образом можно скопировать файл с удаленного хоста и одновременно посчитать md5:
#ssh remote_host "cat /home/user/file" | tee >(md5) > file
(в linux вместо md5 нужно писать md5sum)

[6]. Если есть открытый ssh-сеанс на удаленной машине, можно поднять туннель, прямо в этом же сеансе. Комбинация клавиш “~C” позволяет отредактировать командную строку. Например, если написать “-D 1080″, то будет поднят прокси на 1080-м порту.

[7]. При работе с лог-файлами в sh-скриптах может понадобиться преобразовать дату из human-readable формата в unixtime. Делается это так:
#date -j -f "%d/%m/%Y %H:%M:%S" "18/08/2006 16:43:02" "+%s"
Опция -j запрещает команде date делать попытки установить дату.
-f – формат даты в строке, которую следует разобрать
“+%s” – отобразить дату в формате unixtime. Если этот аргумент опустить, то дата будет выведена в стандартном UTC формате (пятница, 18 августа 2006 г. 16:43:02 (MSD))

[8]. Во FreeBSD есть утилита bdes, позволяющая (де)криптовать файлы из командной строки.
#cat file | bdes > file.cripted
Enter key:
Также есть утилита enigma, но криптостойкость ее алгоритмов очень низка (вернее, отсутствует)

Сегодня обнаружил, что текстовое поле в конце файла id_rsa.pub – просто комментарий. Это значит, что после копирования его на удаленный хост в authorized_keys можно заменить свой настоящий логин и имя хоста на строку “тут был Вася” и никто никогда не поймет, кто такой Вася и как он сюда попал.
И еще. Можно работать на удаленном хосте, не светясь ни в auth.log, ни в `who` ни в `last`, без возможности посмотреть, что творится в консоли через watch – для этого достаточно запускать ssh-сессию так: ssh user@host “bash”.

Мораль здесь одна: если у человека есть ssh аккаунт на машине, то контроллировать его действия практически невозможно.