Сезам, откройся: аутентификация

Сезам, откройся: аутентификация

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

Основной способ получения доступа: аутентификация при помощи пароля

«Вначале была командная строка». Основной сутью протокола SSH является то, что командная строка удаленной машины всегда была и будет. Ее синтаксис прост:

dan@OTHERSHOE ~

# ssh user@host

$ ssh dan@10.0.1.11

dan@10.0.1.11”s password:

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

13:44:59 GMT 2001

$

Если задать опцию – X, то при выполнении приложения X-Windows автоматически будет создан туннель. Представляет интерес интерфейс обработки паролей SSH. При необходимости задания пароля безразлично, где именно в цепочке команд SSH он будет задан. В любом случае SSH почти всегда сможет его запросить. Это не тривиально, но очень полезно.

Однако паролям присущи свои собственные проблемы. Если хосты A и B совместно используют пароли, то хост A может обмануть пользователя хоста B, и наоборот. В главе 12 были подробно описаны наиболее интересные подробности о слабых сторонах паролей. Таким образом, SSH поддерживает значительно больший механизм аутентификации (подтверждения подлинности) клиента серверу.

Прозрачный способ получения доступа: аутентификация при помощи личного ключа

Системы с асимметричным ключом предлагают мощный способ подтверждения одним хостом своей подлинности большому числу других хостов. Большинство людей может узнать человеческое лицо, но не «надеть» его на себя. Точно так же многие хосты могут распознать личный ключ по его общедоступной части, но самостоятельно воспроизвести его личную, секретную часть они не смогут. SSH генерирует две части личного ключа, которые другие хосты могут распознать: одну – для протокола SSH1, другую – для SSH2.

Аутентификация сервера клиенту Хотя для клиента использование ключевой пары, состоящей из общедоступного и личного ключа, необязательно, сервер все равно обязан предоставить такой ключ, чтобы клиент, однажды доверившись хосту, впоследствии всегда мог его идентифицировать. В этом проявляется отличие от протокола SSL, который предполагает, что клиент доверяет некоторому авторитетному источнику сертификатов, например VeriSign, веря его сертификатам при обмене данными с любым другим хостом. Напротив, протокол SSH допускает риск первого представления хосту, а затем, учитывая этот риск, пытается распространить его на все последующие сессии. При этом становится возможным значительно сократить накладные расходы за счет менее защищенной модели аутентификации сервера по умолчанию. (Это пример одного из многих компромиссов. Неуправляемые системы безопасности не устанавливают, а неразвернутые системы защиты, как правило, ужасно ненадежны.) Первые подключения к SSH-серверу в общем случае выглядят следующим образом:

effugas@OTHERSHOE ~

$ ssh effugas@10.0.1.11

The authenticity of host ’10.0.1.11 (10.0.1.11)’ can’t be

established.

RSA key fingerprint is

6b:77:c8:4f:e1:ce:ab:cd:30:b2:70:20:2e:64:11:db.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added ’10.0.1.11’ (RSA) to the list of

known hosts.

effugas@10.0.1.11’s password:

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

13:44:59 GMT 2001

$

Как известно, ключи Host Key генерируются автоматически после инсталляции SSH-сервера. Часто это сопровождается проблемами из-за чрезмерной молчаливости программ инсталляции. Иногда они перезаписывают или используют не по назначению существующие ключи. В результате при работе клиентов возникают жуткие ошибки, которые указывают на возможность существования кого-то или чего-то, фальсифицирующего сервер. Но обычно это означает всего лишь законную потерю ключа или его разрушение в результате последовательного продвижения пользователей к только им известной цели и получения ими доступа к новым, возможно, фальсифицированным ключам. Это не вполне понятно, но именно так все и происходит. Для систем, которым необходимо обеспечить повышенную безопасность, чрезвычайно важно задуматься над использованием достойных способов безопасного размещения файлов ~/.ssh/known_hosts и ~/.ssh/known_hosts2. Эти файлы содержат список ключей, которые клиенты могут распознать. Большая часть этой главы посвящена обсуждению вопросов размещения названных файлов в произвольных нетрассируемых сетях (disroutable networks). После обнаружения работоспособного в сети читателя способа размещения этих файлов следующая идея проектирования могла бы оказаться плодотворной: каждый клиент обращается к центральному хосту с запросом нового файла, который известен хосту и который пересылает его клиенту. Аутентификация клиента серверу Использование клиентом асимметричных ключей полезно, но необязательно. Двумя главными шагами в этом направлении являются генерация клиентом ключей и последующее информирование об этом сервера, для того чтобы он смог принять сгенерированные ключи. Первый шаг, то есть генерация ключей, инициализируется при использовании команды ssh-keygen для SSH1 и команды ssh-keygen -t dsa для SSH2:

effugas@OTHERSHOE ~

$ 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

effugas@OTHERSHOE

effugas@OTHERSHOE ~

$ 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

effugas@OTHERSHOE

Затем наступает время второго шага: следует проинформировать сервер о необходимости проверить подключенных клиентов на предмет обладания ими личного ключа (.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. Реализованные в нем вещи аморальны, и он даже не пытается скрывать это. Приведенный ниже пример, используя недавно загруженные ключи пользователя, устраняет необходимость в идентификации пароля. Попутно появляется дополнительное преимущество, которое заключается в отсутствии необходимости использовать какие-либо дополнительные приложения (отметим, что от читателя потребуется ввести пароль):

effugas@OTHERSHOE ~

$ ssh –1 effugas@10.0.1.10

effugas@10.0.1.10”s password:

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

[effugas@localhost effugas]$

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

effugas@OTHERSHOE ~

$ cat ~/.ssh/identity.pub | ssh -1 effugas@10.0.1.10 “cd ~

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

authorized_keys”

effugas@10.0.1.10’s password:

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

effugas@OTHERSHOE ~

$ ssh -1 effugas@10.0.1.10

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

[effugas@localhost effugas]$

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

effugas@OTHERSHOE ~

$ cat ~/.ssh/id_dsa.pub | ssh effugas@10.0.1.10 “cd ~ &&

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

authorized_keys2”

effugas@10.0.1.10’s password:

effugas@OTHERSHOE ~

$ ssh effugas@10.0.1.10

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

[effugas@localhost effugas]$

Данный текст является ознакомительным фрагментом.