Читаем без скачивания Защита от хакеров корпоративных сетей - Коллектив авторов

[email protected] ~

$ ssh-keygen

Generating public/private rsa1 key pair.

Enter file in which to save the key (/home/effugas/.ssh/

identity):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/effugas/.ssh/

identity.

Your public key has been saved in /home/effugas/.ssh/

identity.pub.

The key fingerprint is:

c7:d9:12:f8:b4:7b:f2:94:2c:87:43:14:5a:cf:11:1d

[email protected]

[email protected] ~

$ ssh-keygen -t dsa

Generating public/private dsa key pair.

Enter file in which to save the key (/home/effugas/.ssh/

id_dsa):

Enter passphrase (empty for no passphrase): <ENTER>

Enter same passphrase again: <ENTER>

Your identification has been saved in /home/effugas/.ssh/

id_dsa.

Your public key has been saved in /home/effugas/.ssh/

id_dsa.pub.

The key fingerprint is:

e0:e2:a7:1b:02:ad:5b:0a:7f:f8:9c:d1:f8:3b:97:bd

[email protected]

Затем наступает время второго шага: следует проинформировать сервер о необходимости проверить подключенных клиентов на предмет обладания ими личного ключа (.ssh/identity для SSH1, ssh/id_dsa для SSH2). Такая проверка заключается в посылке серверу его общедоступного элемента, который затем добавляется в файл домашней директории пользователя. Домашняя директория пользователя задается самим пользователем:.ssh/authorized_keys для SSH1 и. ssh/authorized_keys2 для SSH2. На самом деле не существует элегантного способа реализовать в протоколе SSH то, что было сказано. Это самая слабая сторона комплекса инструментальных средств, а вполне возможно, что и самого протокола непосредственно. Для преодоления данного недостатка Уильям Стеарнс (William Stearns) проделал в этом направлении очень большую работу. Его скрипт, посвященный этой проблеме, находится по адресу www.stearns.org/ssh-keyinstall/ssh-keyinstall-0.1.3.tar.gz. Реализованные в нем вещи аморальны, и он даже не пытается скрывать это. Приведенный ниже пример, используя недавно загруженные ключи пользователя, устраняет необходимость в идентификации пароля. Попутно появляется дополнительное преимущество, которое заключается в отсутствии необходимости использовать какие-либо дополнительные приложения (отметим, что от читателя потребуется ввести пароль):

[email protected] ~

$ ssh –1 [email protected]

[email protected]”s password:

Last login: Mon Jan 14 05:38:05 2002 from 10.0.1.56

[[email protected] effugas]$

А сейчас дышите глубже. Теперь читатель с помощью ssh-keygen должен прочитать сгенерированный ключ и передать его по каналу дальше, используя ssh с адресом 10.0.1.10 и имя пользователя effugas. После этого ему следует удостовериться в том, что он находится в домашней директории, и установить режимы работы с файлом таким образом, чтобы никто другой не смог прочитать то, что он собирается записать. При необходимости читатель может создать директорию (опция -p позволяет по желанию создавать директории), а затем он получит переданные по каналу данные и добавит их к файлу ~/.ssh/authorized_keys, которые демон будет использовать для аутентификации удаленного личного ключа. Почему сказанное не включено в число стандартных функциональных возможностей и является большой загадкой? Возможно, потому, что оно реализуется расширенной командой, состоящей из нескольких частей, которая, тем не менее, хорошо работает:

[email protected] ~

$ cat ~/.ssh/identity.pub | ssh -1 [email protected] “cd ~

&& umask 077 && mkdir -p .ssh && cat >> ~/.ssh/

authorized_keys”

[email protected]’s password:

Мама моя родная, никакого пароля не требуется:

[email protected] ~

$ ssh -1 [email protected]

Last login: Mon Jan 14 05:44:22 2002 from 10.0.1.56

[[email protected] effugas]$

Эквивалентным процессом для SSH2, который для пакета OpenSSH является протоколом по умолчанию, является следующий:

[email protected] ~

$ cat ~/.ssh/id_dsa.pub | ssh [email protected] “cd ~ &&

umask 077 && mkdir -p .ssh && cat >> ~/.ssh/

authorized_keys2”

[email protected]’s password:

[email protected] ~

$ ssh [email protected]

Last login: Mon Jan 14 05:47:30 2002 from 10.0.1.56

[[email protected] effugas]$...

Инструментарий и ловушки

Много пользователей, одна учетная запись: предотвращение утечки сведений о пароле

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

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

Необходимо сделать следующее пояснение: постепенно от файлов known_hosts2 и authorized_keys2 отказываются, преобразуя их в файлы known_hosts и authorized_keys. Сервера, которым не нужны специфические файлы протокола SSH2, обращаются к новым файлам, отбрасывая 2 в конце имени файла.

Из-за недоверия к серверам остерегаются использовать пароли, но кто говорит, что клиент намного лучше? Хорошая криптография – это прекрасно, но по существу берется нечто, что запоминается в памяти пользователя и помещается на жесткий диск клиента. А ведь это нечто может быть перехвачено. Помните, что нет безопасного способа запомнить пароль клиента без использования другого пароля, защищающего запомненный пароль. Решений этой проблемы не так много. В одной из реализаций протокола SSH для ее решения используются идентификационные фразы (passwords). Они позволяют расшифровать личный ключ, с помощью которого удаленный сервер проверяет знание клиентом секрета. Идентификационная фраза состоит из анализируемых клиентом паролей. Читатель может добавить идентификационные фразы к обоим ключам протокола SSH2:

# add passphrase to SSH1 key

[email protected] ~

$ ssh-keygen.exe -p

Enter file in which the key is (/home/effugas/.ssh/

identity):

Key has comment “[email protected]”

Enter new passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved with the new passphrase.

# add passphrase to SSH2 key

[email protected] ~

$ ssh-keygen.exe -t dsa -p

Enter file in which the key is (/home/effugas/.ssh/id_dsa):

Key has comment “/home/effugas/.ssh/id_dsa”

Enter new passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved with the new passphrase.

# Note the new request for passphrases

[email protected] ~

$ ssh [email protected]

Enter passphrase for key “/home/effugas/.ssh/id_dsa”:

FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3

13:44:59 GMT 2001

$

Конечно, это возврат туда, откуда все начиналось. Читатель должен будет вводить пароль каждый раз, когда он захочет подключиться к удаленному хосту! Что теперь?

Умалчиваемая правда заключается в том, что большинство людей продолжает доверять своим клиентам и полностью отказываются от идентификационных фраз. Это сильно раздражает администраторов информационных технологий, которые, отключая возможность использования паролей, думают, что тем самым они подталкивают людей к действительно хорошим криптографическим решениям, у которых нет огромных, настежь раскрытых дыр в системе защиты. На самом деле идентификационные фразы ничуть не лучше паролей. В протоколе SSH предусмотрены улучшенные варианты использования идентификационных фраз, которые позволяют распространить один-единственный ввод идентификационной фразы на сравнительно большое число попыток идентификации. Осуществляется это при помощи агента, который может быть размещен где угодно и который занят вычислением личного ключа для выполняющихся под его управлением клиентов SSH. (Это означает, и это важно, что только SSH-клиенты, выполняющиеся под управлением агента, получают доступ к его ключу.) Идентификационная фраза передается агенту, который расшифровывает личный ключ и позволяет клиентам получить доступ без фактического знания пароля. Ниже приведен пример простой реализации сказанного, в котором предполагается, что ключ создается так же, как и в предыдущем примере. Сгенерированный ключ действителен как при обращении к адресу 10.0.1.11, так и к адресу 10.0.1.10.

Прежде всего запустим агента. Обратите внимание на поименованную дочернюю оболочку. Если читатель не укажет ее имя, то будет получено сообщение об ошибке: «Нельзя открыть соединение к вашему агенту аутентификации (Could not open a connection to your authentication agent)».

[email protected] ~ $ ssh-agent bash

После запуска агента добавляем ключи. В случае отсутствия аргумента будет добавлен ключ SSH1:

[email protected] ~

$ ssh-add

Enter passphrase for [email protected]:

Identity added: /home/effugas/.ssh/identity

([email protected])

При наличии аргумента добавляется ключ SSH2:

[email protected] ~

$ ssh-add ~/.ssh/id_dsa