Читать онлайн «TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)». Страница 75

13.11.1 Аутентификация в telnet

В telnet реализована аутентификация, позволяющая партнерам согласовать один из вариантов этого механизма. Последовательность действий следующая:

■ Сервер посылает DO AUTHENTICATION

■ Клиент отвечает WILL AUTHENTICATION

С этого момента вся информация будет пересылаться в сообщениях дополнительного согласования.

■ Сервер посылает сообщение, содержащее список пар аутентификации. Каждая пара включает тип аутентификации (который нужно использовать) и модификатор, обеспечивающий дополнительную информацию (например, сведения об аутентификации будут посылаться только клиентом или одновременно — клиентом и сервером).

■ Клиент отправляет простой идентификатор пользователя (userid) или идентификатор регистрации.

■ Клиент выбирает из списка одну из пар аутентификации и посылает сообщение, идентифицирующее тип аутентификации, включая аутентификационные данные. В зависимости от протокола может потребоваться более одного сообщения.

■ Сервер принимает аутентификацию.

■ Если выбрана взаимная аутентификация, клиент запрашивает от сервера его аутентификационные данные.

■ Сервер отвечает, сообщая свои аутентификационные данные.

Типы аутентификации зарегистрированы в IANA и имеют числовые коды. Текущее соответствие между кодами и типами таково:

В существующих реализациях все большую популярность приобретают взаимные проверки (challenge handshakes) и защитные идентификационные карты.

Telnet не обеспечивает хорошей производительности. При эмуляции терминала ASCII (например, VT100) telnet очень неэффективен. Посланные клиентом сегменты часто содержат только один или несколько символов. Каждый символ нужно вернуть назад для эхо-печати. Пересылка даже небольшого количества данных приводит к серьезной загрузке сети.

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

Сегодня многие новые приложения построены для доступа к информации через стандартного клиента, подобного браузеру WWW. Разработчик приложения должен создать интерфейс между новым приложением и сервером WWW. Только тогда пользователи смогут работать с единообразным и знакомым интерфейсом.

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

Протокол X Windows обеспечивает единообразный способ управления вводом и выводом из приложения. Поэтому приложения не зависят от аппаратных средств, операционной системы и типа сети. Современные реализации этого протокола работают поверх стека TCP/IP.

Протокол может выполняться на рабочих станциях или на многопользовательском компьютере, который управляет графическими дисплеями. Существует множество специализированных программ для X Windows. Протокол этой системы очень широко распространен, и для него имеются высокофункциональные прикладные инструменты разработки. Часто эти средства встроены в продукты TCP/IP.

При использовании X Windows проявляются отдельные недостатки, связанные с необходимостью пересылки большого объема информации для вывода на экран. Это приводит к большой нагрузке на сеть.

С X Windows связаны и отдельные проблемы безопасности — очень трудно защитить систему от программ для взлома, маскирующихся под обычные приложения.

RFC 854 определяет протокол telnet. Различные типы терминалов рассмотрены в: RFC 1205 для эмуляции 5250; RFC 1096 для размещения на дисплеях X-терминалов; RFC 1053 для параметров X.3 PAD; RFC 1043 для терминалов ввода данных; RFC 1041 для режимов терминала 3270. Выбор параметров терминала разъясняется в RFC 1091, а варианты размеров окна можно найти в RFC 1073. RFC 1184 описывает характеристики построчного режима telnet. Документы RFC с 855 по 861 рассматривают другие часто используемые параметры эмуляции.

RFC 1416 посвящен аутентификации в telnet. RFC 1510 представляет службу аутентификации Kerberos Network Authentication Service.

В сетевой среде естественным является желание копировать файлы между компьютерными системами. Почему же эту операцию не всегда легко реализовать? Разработчики компьютеров уже создали сотни различных файловых систем, значительно или не очень существенно отличающихся друг от друга. Однако проблема связана не только с продуктами различных компаний. Иногда трудно копировать файлы между различными типами компьютеров одного и того же разработчика.

Среди проблем, с которыми обычно приходится сталкиваться при работе в многосистемном сетевом окружении, можно отметить следующие:

■ Различные правила именования файлов

■ Различные правила перемещения по каталогам файловой системы

■ Ограничения на доступ к файлам

■ Различные способы представления текста и данных внутри файлов

Разработчики стека протоколов TCP/IP старались найти не слишком сложное решение этих проблем и создали достаточно общий, но очень элегантный протокол пересылки файлов (File Transfer Protocol — FTP), который легко обслуживается и прост в использовании.

Протокол FTP создан для взаимодействия с интерактивным конечным пользователем или прикладной программой. Мы ограничимся рассмотрением интерактивных служб этого протокола для конечного пользователя, всегда доступных во всех реализациях TCP/IP.

Пользовательский интерфейс разработан для клиента пересылки файлов операционной системы Berkeley Unix (BSD) и далее перенесен на различные типы многопользовательских компьютеров. В этой главе мы рассмотрим диалоги конечного пользователя с текстовым интерфейсом, а также несколько графических интерфейсов для настольных компьютеров.

Основные функции пересылки файлов разрешают пользователю копировать файлы между системами, просматривать списки каталогов и выполнять файловые операции, подобные переименованию или удалению. Все эти функции являются частью стандартного стека протоколов TCP/IP.

В конце главы мы проанализируем простейший протокол пересылки файлов (Trivial File Transfer Protocol — TFTP), использующийся в базовых операциях по переносу файлов в определенных ситуациях, например при загрузке программного обеспечения в маршрутизаторы, мосты или бездисковые рабочие станции.

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

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

■ Доступ к личным файлам, разрешенный только для пользователя с системным идентификатором регистрации и паролем

Представленный ниже диалог демонстрирует копирование из сайта AT&T InterNIC Data Services (общедоступного репозитария документов RFC).

Сегодня многие имеют на своих настольных системах графические пользовательские интерфейсы (GUI) для пересылки файлов. С одним из таких интерфейсов мы познакомимся ниже. Однако текстовый интерфейс позволяет лучше понять происходящие в процессе пересылки файлов события, поэтому сначала мы познакомимся с подключением к InterNIC через текстового клиента.

Архив файлов InterNIC доступен для всех, так что при регистрации мы будем вводить идентификатор ftp. Традиционно обращение к общедоступным системам происходило через идентификатор анонимного (anonymous) доступа. В настоящее время больше применяется ftp, который легче напечатать. Общедоступные серверы для пересылки файла предполагают ввод пользователем адреса электронной почты в качестве пароля.