13.9.3 Кодирование запросов выбора вариантов
Запросы выбора вариантов кодируются тремя байтами: байтом IAC, октетом запроса и кодом варианта. Например, десятичное представление последовательности для WILL TERMINAL TYPE выглядит так:
IAC WILL TERMINAL TYPE 255 251 24
Это один из вариантов для дополнительного согласования. Далее должны следовать:
СЕРВЕР:
IAC SB TERMINAL TYPE SEND IAC SE 255 250 24 1 255 240
КЛИЕНТ:
IAC SB TERMINAL TYPE IS DEC-VT220 IAC SE 255 250 24 0 DEC-VT220 255 240
В таблице 13.3 показаны десятичные значения для кодов обычных и дополнительных согласований. Приведены также коды для часто используемых вариантов. Параметры дополнительного согласования и коды добавочных вариантов определены во многих RFC, относящихся к параметрам telnet (эти RFC перечислены в документе Assigned Numbers).
Таблица 13.3 Коды согласования и выбора вариантов
Коды согласования Запрос Код WILL (будет) 251 WONT (не будет) 252 DO (выполнить) 253 DON'T (не выполнять) 254 SB (Start Subnegotiation, начало дополнительного согласования) 250 SE (End Subnegotiation, конец дополнительного согласования) 240 Примеры кодов вариантов Command Option (вариант команды) Код Transmit Binary (пересылка двоичных данных) 0 Echo (эхо-печать) 1 Suppress Go Ahead (подавление сообщения Go Ahead) 3 Status (состояние) 5 Timing Mark (метка времени) 6 Output Line Width (длина выходной строки) 8 Output Page Size (размер выводимой страницы) 9 Extended ASCII (расширенный набор ASCII) 17 Data Entry Terminal (терминал ввода данных) 20 Terminal Type (тип терминала) 24 End of Record (конец записи) 25 Window Size (размер окна) 31 Terminal Speed (скорость терминала) 32 Remote Flow Control (удаленное управление потоком) 33 Linemode (построчный режим) 34 Authentication (аутентификация) 37 Encryption (шифрование) 38 Extended Options List (расширенный список вариантов) 255
13.9.4 Дополнительные сведения о вариантах
Более тридцати RFC детально рассматривают различные варианты, предоставляющие специальные возможности для telnet. Среди них можно выделить:
■ Способность опрашивать партнера о текущем состоянии параметров. Запрос и ответ о состоянии партнера переносятся при дополнительном согласовании.
■ Согласование размера окна. Партнеры соглашаются, что клиент может дополнительно согласовать высоту и ширину окна, которое будет использоваться в сеансе telnet. Эта возможность особенно полезна для запуска сеанса telnet в системах с многооконным интерфейсом.
Реализациям не требуется поддерживать все или многие из определенных в стандартах вариантов. Два из них, используемые при эмуляции терминала 3270, имеют специальные возможности:
■ Transmit Binary (пересылка двоичных данных). Начало отправки 8-разрядных двоичных данных (сеансы с терминалом IBM 3270 проводятся в двоичном режиме).
■ End of Record (конец записи). После получения DO END-OF-RECORD партнер использует стандартные управляющие коды IAC 239 для маркировки конца записи в общем потоке данных.
Вспомним, что даже после перехода в двоичный режим партнеру можно послать команды telnet, удваивая esc-символы IAC.
13.10 Применение telnet
С точки зрения пользователей, желающих получить доступ к приложениям через эмуляцию терминалов ASCII или IBM, наиболее важным является способность telnet выполнять согласование и эмуляцию. Но разработчикам прикладного программного обеспечения основанный на NVT telnet предлагает достаточно бедный набор средств для реализации функций клиент/сервер, которые трудно и утомительно воспроизводить в программах. Мы уже знаем, что базовыми возможностями NVT являются:
■ Проверка активности равного приложения
■ Сигнализация прерывания
■ Запрос на прерывание удаленного текущего процесса
■ Использование сигнала синхронизации для указания равному приложению на отбрасывание всех данных, кроме команд telnet
■ Указание партнеру на отмену ожидаемой пересылки данных из буфера
13.11 Замечания о безопасности
Сегодня в локальных сетях повсеместно используются широковещательные рассылки. Многие организации используют их даже в магистральных сетях FDDI.
Пользователям PC или Macintosh очень легко найти программное обеспечение для превращения настольной системы в шпиона, который может подслушивать трафик локальной сети. Такие средства имеют многие станции Unix, владельцам которых нужно только разрешить их использование.
Традиционно пользователь доказывает свои права, посылая хосту секретный пароль. Но в локальной сети с широковещательной рассылкой передача идентификатора и пароля по сети не обеспечивает для них никакой защиты. Любой может подслушать эти сведения.
Не помогает и шифрование пароля. Взломщику даже не нужно будет расшифровывать пароль, а потребуется только переслать его в том же виде и таким путем получить доступ к чужим регистрационным данным. Все это свидетельствует о необходимости безопасного механизма аутентификации (установление подлинности).
13.11.1 Аутентификация в telnet
В telnet реализована аутентификация, позволяющая партнерам согласовать один из вариантов этого механизма. Последовательность действий следующая:
■ Сервер посылает DO AUTHENTICATION
■ Клиент отвечает WILL AUTHENTICATION
С этого момента вся информация будет пересылаться в сообщениях дополнительного согласования.
■ Сервер посылает сообщение, содержащее список пар аутентификации. Каждая пара включает тип аутентификации (который нужно использовать) и модификатор, обеспечивающий дополнительную информацию (например, сведения об аутентификации будут посылаться только клиентом или одновременно — клиентом и сервером).
■ Клиент отправляет простой идентификатор пользователя (userid) или идентификатор регистрации.
■ Клиент выбирает из списка одну из пар аутентификации и посылает сообщение, идентифицирующее тип аутентификации, включая аутентификационные данные. В зависимости от протокола может потребоваться более одного сообщения.
