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

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

Первым шагом для получения доступа к удаленной системе при работе в 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]$

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

9.4.3. Аутентификация

Из книги автора

9.4.3. Аутентификация Защита по IP-адресу не гарантирует от его подделки злоумышленником. К тому же, остается вероятность, что кто-то получит физический доступ к компьютеру, имеющему выход во всемирную сеть, и сделает нечто недозволенное.Мне довелось работать в фирме, где


Аутентификация при SSH-взаимодействии

Из книги автора

Аутентификация при SSH-взаимодействии В процессе обмена сервер и клиент SSH используют различные способы кодирования передаваемых данных. Упрощенно это выглядит так. Участники взаимодействия договариваются о временном использовании метода кодирования с помощью


7.3.2. PAP- и СНАР-аутентификация

Из книги автора

7.3.2. PAP- и СНАР-аутентификация Большинство провайдеров и корпоративных РРР-серверов используют протокол РАР. Если используется протокол РАР, то вместо того, чтобы регистрироваться на таком сервере, используя имя пользователя и пароль, когда их ввод запрошен сервером,


3.8.1 Аутентификация

Из книги автора

3.8.1 Аутентификация Важным аспектом компьютерной безопасности является выяснение "кто есть кто". Ранее это определяли идентификатор и пароль пользователя. Аналогичным образом в поле "From:" сообщения электронной почты идентифицируется отправитель. Однако пароль может быть


4.8.1 Аутентификация

Из книги автора

4.8.1 Аутентификация Протокол PPP часто используется для удаленных коммуникаций и связи мобильного пользователя по коммутируемым соединениям. Коммутируемые соединения (dialup connection) иногда применяются для связи локальных сетей подразделений компании с сетью главного


15.9 Аутентификация в RPC

Из книги автора

15.9 Аутентификация в RPC Некоторые службы не нуждаются в защите. Для вывода времени дня на сервере служба RPC может быть оставлена открытой для общего доступа. Однако клиент, обращающийся к личным данным, должен обеспечить некоторую опознавательную информацию (проходить


15.9.1 Нулевая аутентификация

Из книги автора

15.9.1 Нулевая аутентификация Нулевая аутентификация полностью соответствует своему названию. Не используется никакой аутентификационной информации — в полях мандата и verifier сообщений запросов и ответов содержатся одни


15.9.2 Аутентификация систем

Из книги автора

15.9.2 Аутентификация систем Аутентификация систем моделирует аналогичную информацию операционной системы Unix. Мандат системы содержит: stamp (штамп) Случайный идентификатор, сгенерированный вызывающим компьютером machinename (имя машины) Имя запрашивающей машины uid


15.9.3 Аутентификация DCS

Из книги автора

15.9.3 Аутентификация DCS Стандарт шифрования данных (Data Encryption Standard — DES) использует симметричный алгоритм шифрования. DES — это федеральный стандарт обработки информации (Federal Information Processing Standard — FIPS), который был определен Национальным бюро стандартов США, в настоящее время


15.9.4 Аутентификация в Kerberos

Из книги автора

15.9.4 Аутентификация в Kerberos При аутентификации в системе Kerberos (по имени трехглавого сторожевого пса Цербера из древнегреческой мифологии. — Прим. пер.) используется сервер безопасности Kerberos, хранящий ключи пользователей и серверов (основанные на паролях). Kerberos


16.4. Аутентификация

Из книги автора

16.4. Аутентификация По умолчанию в запросе RPC не содержится информации о клиенте. Сервер отвечает на запрос клиента, не беспокоясь о том, что это за клиент. Это называется нулевой аутентификацией, или AUTH_NONE.Следующий уровень проверки подлинности называется аутентификацией


10.5. Аутентификация пользователей

Из книги автора

10.5. Аутентификация пользователей Программы, у которых установлен бит SUID, не должны запускаться кем попало. Например, программа su, прежде чем менять идентификатор пользователя, заставляет его ввести пароль. Это называется аутентификацией — программа проверяет, получил


Аутентификация Kerberos

Из книги автора

Аутентификация Kerberos Роджер Нидхэм и Михаэль Шредер в 1978 году впервые предложили механизм аутентификации, который базировался на шифровании, но он, к сожалению, не обеспечивал одинаковых гарантий для участвующих в коммуникации сторон [93]. Для решения этой проблемы в


Нотариальная аутентификация

Из книги автора

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


Идентификация и аутентификация

Из книги автора

Идентификация и аутентификация Идентификацией субъекта называется процесс сопоставления введенной им своей характеристики с некоторым идентификатором, хранимым системой. В дальнейшем идентификатор субъекта используется для предоставления субъекту определенного