Новые книги

Рассмотрены вопросы, необходимые разработчику для создания клиент-серверных приложений с использованием СУБД Firebird, явившейся развитием СУБД Borland Interbase 6. Содержится обзор концепций и моделей архитектуры клиент/сервер, а также практические рекомендации по работе с клиентскими библиотеками Firebird. Детально описаны особенности типов данных SQL, язык манипулирования данными (Data Manipulation Language, DML), а также синтаксис и операторы языка определения данных ( Data Definition Language, DDL). Большое внимание уделено описанию транзакций и приведены советы по их использованию при разработке приложений. Описано программирование на стороне клиента и сервера написание триггеров и хранимых процедур, создание и использование событий базы данных, обработка ошибок в коде на сервере и многое другое. Материал сопровождается многочисленными примерами, советами и практическими рекомендациями.

Для разработчиков баз данных
Между отделами маркетинга и продаж нередки споры, из-за которых компания в целом теряет прибыль. Эта книга призвана помочь распознавать и вовремя тушить конфликты. Можно сразу прикинуть сколько будет стоить каждая из 25 предложенных мер, кому ее поручить и сколько времени займет исполнение.

В конечном счете от согласованных действий двух отделов зависит прибыль компании.

Для руководителей и персонала отделов маркетинга и продаж, коммерческих директоров, руководителей компании и собственников бизнеса.

Configuring Remote Loginand Execution

Настройка удаленного выполнения

Часто очень полезно выполнить команду на удаленном компьютере. Причем ввод и вывод команды осуществляются по сети.

Традиционные команды, используемые для выполнения задач на удаленных компьютерах rlogin, rsh и rcp. Пример команды rlogin приведен в главе 1. Я кратко показал проблемы защиты, связанные с этим, в разделе о защите системы в главе 1 и предложил в качестве замены пакет ssh. Он обеспечивает команды slogin, ssh и scp.

Каждая из этих команд порождает оболочку на удаленном компьютере и позволяет пользователю выполнять команды. Конечно, пользователь должен быть зарегистрирован на том удаленном компьютере, где должна быть выполнена команда. Таким образом, все эти команды используют процесс авторизации. Старые r-команды просто обменивались с удаленным компьютером именем пользователя и его паролем в открытом виде. Поэтому любая программа сетевого наблюдения легко перехватывала пароли. Пакет ssh обеспечивает более высокий уровень защиты: он использует методику Public Key Cryptography для авторизации и шифрования обменов между компьютерами, чтобы гарантировать, что ни пароли, ни другие данные сеанса не перехвачены. В принципе, их как и раньше можно перехватить, но они будут зашифрованы стойким криптоалгоритмом, так что никакой пользы перехватившему от них не будет.

Иногда желательно ослабить проверку доступа для некоторых пользователей. Например, если Вы часто должны регистрироваться на других машинах Вашей локальной сети, неплохо бы быть признанным без ввода пароля каждый раз. Это всегда было возможно с r-командами, но пакет ssh позволяет Вам сделать это немного легче. Но такой подход опасен тем, что если на одной машине логин пользователя вскрыт, это дает доступ без пароля на другие машины.

Для повышения безопасности нужно выключить r-команды и настроить ssh на работу вместо них.

Выключение r-команд

Самый простой способ запретить r-команды, это закомментировать или удалить записи для них в файле /etc/inetd.conf. Соответствующие им строки этого файла выглядят так:

# Shell, login, exec and talk are BSD protocols.
shell    stream  tcp     nowait  root  /usr/sbin/tcpd /usr/sbin/in.rshd
login    stream  tcp     nowait  root  /usr/sbin/tcpd /usr/sbin/in.rlogind
exec     stream  tcp     nowait  root  /usr/sbin/tcpd /usr/sbin/in.rexecd
Вы можете закомментировать их, помещая символ # в начале каждой строки. Не забудьте, что Вы должны перезапустить inetd daemon для вступления изменений в силу.

Установка и конфигурирование ssh

OpenSSH свободная версия набора программ ssh. Linux-версия есть на http://violet.ibs.com.au/openssh и во многих дистрибутивах Linux. Здесь я не буду рассматривать компиляцию: подробные указания есть в пакете с исходными текстами. Если Вы можете установить программу из откомпилированных модулей, лучше всего это сделать.

Для работы ssh нужно два компонента: клиент ssh, которого Вы должны конфигурировать и выполнить на локальном компьютере, и ssh daemon, который должен работать на удаленном компьютер, к которому нужно подключиться.

Ssh daemon

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

Утилита ssh-keygen генерирует случайные ключи. Это обычно используется один раз при установке для генерации главного ключа, который администратор системы обычно хранит в файле /etc/ssh/ssh_host_key. Ключи могут иметь длину 512 бит или больше. По умолчанию ssh-keygen генерирует ключи длиной 1024 бита, и большинство людей использует значение по умолчанию. Чтобы генерировать ключ, вызовите команду ssh-keygen:

# ssh-keygen -f /etc/ssh/ssh_host_key

Вас спросят о фразе-пароле. Но ключи хостов такую фразу использовать не должны, так что оставьте ее пустой и нажмите Enter. Вывод программы будет выглядеть примерно так:

Generating RSA keys:  ......oooooO...............................oooooO
Key generation complete.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /etc/ssh/ssh_host_key
Your public key has been saved in /etc/ssh/ssh_host_key.pub
The key fingerprint is:
1024 3a:14:78:8e:5a:a3:6b:bc:b0:69:10:23:b7:d8:56:82 root@moria

В конце сказано, что два файла были созданы. Первый называется секретным ключом, и должен быть сохранен в тайне. Он попал в файл /etc/ssh/ssh_host_key. Второй называется публичным ключом и должен распространяться. Он хранится в файле /etc/ssh/ssh_host_key.pub.

Теперь нужно создать файл конфигурации. Пакет ssh очень мощный, и файл конфигурации может содержать много параметров. Следующий код показывает безопасный и минимальный файл конфигурации для sshd. Остальные опции детально описаны на man-странице sshd(8):

# /etc/ssh/sshd_config

# The IP adddresses to listen for connections on. 0.0.0.0 means all
# local addresses.
ListenAddress 0.0.0.0

# The TCP port to listen for connections on. The default is 22.
Port 22

# The name of the host key file.
HostKey /etc/ssh/ssh_host_key

# The length of the key in bits.
ServerKeyBits 1024

# Should we allow root logins via ssh?
PermitRootLogin no

# Should the ssh daemon check users' home directory and files permissions?
# are safe before allowing login?
StrictModes yes

# Should we allow old ~/.rhosts and /etc/hosts.equiv authentication method?
RhostsAuthentication no
# Should we allow pure RSA authentication?
RSAAuthentication yes
# Should we allow password authentication?
PasswordAuthentication yes

# Should we allow /etc/hosts.equiv combined with RSA host authentication?
RhostsRSAAuthentication no
# Should we ignore ~/.rhosts files?
IgnoreRhosts yes
# Should we allow logins to accounts with empty passwords?
PermitEmptyPasswords no

Очень важно правильно задать права доступа к файлу настроек. Используйте следующие команды для их задания:

# chown -R root:root /etc/ssh
# chmod 755 /etc/ssh
# chmod 600 /etc/ssh/ssh_host_key
# chmod 644 /etc/ssh/ssh_host_key.pub
# chmod 644 /etc/ssh/sshd_config

Заключительная стадия настройки sshd daemon это его запуск. Следует создать для него rc-файл или вписать вызов в уже существующий, чтобы сервис автоматически вызывался при начальной загрузке. Daemon выполняется автономно и не требует записи в файле /etc/inetd.conf. Он должен быть выполнен от имени пользователя root. Синтаксис очень прост:

/usr/sbin/sshd
sshd автоматически переходит в фоновый режим. Теперь он готов к приему соединений по протоколу ssh.

Клиент ssh

Имеется ряд клиентов ssh: slogin, scp и ssh. Они используют один файл конфигурации, обычно /etc/ssh/ssh_config, и файлы настроек из каталога .ssh в домашнем каталоге пользователя, который их вызвал. Наиболее важные из этих файлов: .ssh/config, который может содержать параметры, отменяющие заданные в /etc/ssh/ssh_config, .ssh/identity, который содержит собственный секретный ключ пользователя и .ssh/identity.pub, содержащий публичный ключ пользователя. Другие важные файлы: .ssh/known_hosts и .ssh/authorized_keys; они будут рассмотрены ниже. Сначала надо создать глобальный файл настроек и файл ключа пользователя.

Файл /etc/ssh/ssh_config очень похож на файл настройки сервера. Есть большое количество свойств, которые Вы можете конфигурировать, но минимальная конфигурация приведена в примере 12-5. Остальная часть параметров рассмотрена на man-странице sshd(8). Вы можете добавлять секции для конкретных компьютеров или их групп. Параметром команды Host может быть любое полное имя компьютера или набор символов подстановки. В данном примере задано соответствие всем хостам. Можно, например, создать запись Host *.vbrew.com, соответствующую всем хостам в домене vbrew.com.

Пример 12-5. Клиентский файл настроек ssh

# /etc/ssh/ssh_config

# Default options to use when connecting to a remote host
Host *
  # Compress the session data?
  Compression yes
  # .. using which compression level? (1 - fast/poor, 9 - slow/good)
  CompressionLevel 6

  # Fall back to rsh if the secure connection fails?
  FallBackToRsh no

  # Should we send keep-alive messages? Useful if you use IP masquerade
  KeepAlive yes

  # Try RSA authentication?
  RSAAuthentication yes
  # Try RSA authentication in combination with .rhosts authentication?
  RhostsRSAAuthentication yes

Я упомянул в разделе конфигурации сервера, что каждый компьютер и пользователь имеет ключ. Ключ пользователя сохранен в его файле ~/.ssh/indentity. Чтобы генерировать ключ, используйте команду ssh-keygen, но Вы не должны определять имя файла, в котором сохраняете ключ. По умолчанию ssh-keygen использует правильное расположение, но попросит Вас ввести имя файла в случае, если Вы хотите сохранить ключ в другом месте. Иногда полезно иметь много авторизационных файлов. Как и прежде ssh-keygen запросит у Вас пароль, что добавляет другой уровень защиты, и его стоит использовать. Пароль не будет отображен на экране, когда Вы его напечатаете.

ПРЕДУПРЕЖДЕНИЕ

Пароль нельзя восстановить, если он забыт. Требования к паролю такие же, как и ко всем прочим паролям. Он должен быть длиной от 10 до 30 символов. Если пароль забыт, придется сгенерировать новый ключ.

Вы должны попросить каждого из Ваших пользователей, чтобы они выполнили ssh-keygen для правильного создания ключа. Команда ssh-keygen создаст их каталоги ~/.ssh/ с соответствующими правами доступа, а также их секретный и публичный ключи в .ssh/identity и .ssh/identity.pub, соответственно. Типовой сеанс:
$ ssh-keygen
Generating RSA keys:  .......oooooO..............................
Key generation complete.
Enter file in which to save the key (/home/maggie/.ssh/identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/maggie/.ssh/identity.
Your public key has been saved in /home/maggie/.ssh/identity.pub.
The key fingerprint is:
1024 85:49:53:f4:8a:d6:d9:05:d0:1f:23:c4:d7:2a:11:67 maggie@moria
$

Теперь ssh готов к работе.

Использование ssh

Теперь пакет ssh и связанные с ним команды установлены и готовы к выполнению.

Сначала опробуем удаленный вход в систему. Можно использовать программу slogin точно так же, как использовалась программа rlogin в примере в первой главе. Первый раз, когда Вы делаете попытку подключения к компьютеру, ssh получит публичный ключ хоста и запросит подтверждение с помощью электронной подписи fingerprint.

Администратор удаленного компьютера должен предоставить электронную подпись, которую Вы должны добавить к Вашему файлу .ssh/known_hosts. Если он этого не сделал, Вы можете соединиться с удаленным компьютером, но ssh предупредит Вас о возникшей ситуации. Допустим, что Вы уверены в том, что работаете с тем компьютером, с которым хотели связаться (никто не перехватил DNS). Тогда ответьте на запрос положительно. Соответствующий ключ будет автоматически сохранен в Вашем файле .ssh/known_hosts без повторных запросов. Если при следующей попытке подключения, публичный ключ с этого компьютера не соответствует тому, который сохранен, Вы будете предупреждены, потому что это представляет потенциальную опасность.

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

$ slogin vchianti.vbrew.com
The authenticity of host 'vchianti.vbrew.com' can't be established.
Key fingerprint is 1024 7b:d4:a8:28:c5:19:52:53:3a:fe:8d:95:dd:14:93:f5.
Are you sure you want to continue connecting (yes/no)?
yes
Warning: Permanently added 'vchianti.vbrew.com,172.16.2.3' to the list of/
    known hosts.
[email protected]'s password:
Last login: Tue Feb  1 23:28:58 2000 from vstout.vbrew.com
$

На запрос о пароле нужно указать свой пароль на удаленной системе. Этот пароль не будет отображен на экране, когда Вы напечатаете его.

Без специальных параметров slogin будет пытаться войти с тем же идентификатором пользователя, который был применен на локальной машине. Вы можете отменить это, указанием параметра -l с именем для регистрации на удаленном компьютере.

Можно копировать файлы по сети командой scp. Синтаксис подобен стандартной cp за исключением того, что Вы можете определять имя машины перед именем файла, указывая, что файл находится на определенном компьютере. Следующий пример иллюстрирует синтаксис scp, копируя локальный файл /tmp/fred в каталог /home/maggie/ на удаленный компьютер chianti.vbrew.com:

$ scp /tmp/fred vchianti.vbrew.com:/home/maggie

[email protected]'s password:
fred                 100% |*****************************| 50165   00:01 ETA

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

Вы можете выполнять команды на удаленных компьютерах, использующих ssh. Синтаксис очень прост. Допустим, пользователь maggie просматривает оглавление корневого каталога на машине vchianti.vbrew.com. Команда:

$ ssh vchianti.vbrew.com ls -CF /
[email protected]'s password:
bin/    console@  dos/     home/    lost+found/  pub@   tmp/  vmlinuz@
boot/   dev/      etc/     initrd/  mnt/         root/  usr/  vmlinuz.old@
cdrom/  disk/     floppy/  lib/     proc/        sbin/  var/

Можно помещать ssh в поток команд с перенаправлением ввода-вывода ("трубопровод"). Все будет работать как и в любой другой команде Linux с той лишь разницей, что ввод-вывод ssh пойдет по сети через защищенное соединение. Вот пример того, как Вы могли бы использовать эту возможность в комбинации с командой tar, чтобы скопировать целый каталог с подкаталогами и файлами с удаленного компьютера на локальный компьютер:

$ ssh vchianti.vbrew.com "tar cf - /etc/" | tar xvf -

[email protected]'s password:
etc/GNUstep
etc/Muttrc
etc/Net
etc/X11
etc/adduser.conf
..
..

Здесь выполняемая команда взята в кавычки, чтобы она вся была воспринята как параметр ssh, а не обрабатывалась локальной оболочкой. Эта команда выполняет tar на удаленном компьютере, чтобы архивировать каталог /etc, и пишет результат на стандартный вывод. Мы имеем перенаправление на команду tar на локальном компьютере в режиме извлечения, причем чтение архива идет из стандартного ввода.

Конечно, везде и всегда запрашивается пароль. Теперь становится понятно, почему ssh часто настраивают так, что он не запрашивает Вас относительно паролей все время! Теперь настроим локальный клиент ssh, чтобы он не спрашивал пароль для связи с vchianti.vbrew.com. Я ранее упомянул файл .ssh/authorized_keys, здесь-то он и нужен. Файл .ssh/authorized_keys хранит публичные (public) ключи любых удаленных записей пользователя, к которым нужен автоматический вход. Можно устанавливать автоматические входы в систему, копируя содержание .ssh/identity.pub из удаленной (remote) системы в локальный файл .ssh/authorized_keys. Установите права доступа к файлу .ssh/authorized_keys так, чтобы только Вы могли его читать и писать. Это делается командой:

$ chmod 600 ~/.ssh/authorized_keys

Публичный ключ представляет собой длинную одиночную строку текста. Если Вы используете копирование и вставку, чтобы копировать ключ в локальный файл, убедитесь, что удалили символы конца строки. Файл .ssh/authorized_keys может содержать много таких ключей по одному на строке.

Набор инструментальных средств ssh очень мощен и имеет многие другие полезные свойства и параметры. Для дальнейшего его изучения обратитесь к man-страницам и другой документации, которая поставляется вместе с пакетом.