Rlogin

Перейти к навигацииПерейти к поиску

Протокол RLOGIN (англ. Remote LOGIN — удалённый вход в систему) — протокол прикладного уровня (7-й уровень модели OSI), часть стека TCP/IP. Позволяет пользователям UNIX подключаться к системам UNIX на других машинах и работать так же, как при прямом подключении терминала к машине.

Принцип работы протокола Rlogin

Установка связи

После установки соединения клиент посылает серверу 4 множества символов, заканчивающиеся нулями (представление строки в С-подобных языках):

  1. пустая строка (состоит из одного нулевого байта),
  2. имя пользователя клиента,
  3. имя пользователя сервера,
  4. тип терминала и скорость.

Например: 

<null>
bostic<null>
kbostic<null>
vt100/9600<null>

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

От клиента серверу (и управление потоком)

Сначала клиент начинает операцию в режиме «cooked» (противоположном режиму «raw»). В этом режиме символы НАЧАЛО и КОНЕЦ (обычно ASCII DC1, DC3) принимаются клиентом и интерпретируются как начало и конец вывода с сервера на локальный терминал, в то время как остальные символы передаются на удалённый хост в том виде, в котором они были получены (см. ниже обработку локальных Escape-символов).

В режиме «raw», символы НАЧАЛО и КОНЕЦ не обрабатываются локально, а посылаются удаленному серверу как любой другой символ. Таким образом в режиме «raw» сервер определяет семантику символов НАЧАЛО и КОНЕЦ; они могут быть использованы для потокового управления или иметь совсем другие значения, никак не зависящие от их первоначального использования на клиенте.

Размер экрана (окна)

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

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

Управляющая последовательность изменения размера окна имеет длину в 12 байт, состоит из:

  1. magic cookie (2х последовательных байтов 0xFF),
  2. после которых следует 2 байта, содержащие символ «s» (ASCII, нижний регистр),
  3. затем 8 байтов, содержащие 16-битовые значения количества символьных строк, количество символов на строку, количество пикселей в горизонтальной развертке и количество пикселей вертикальной развертки.
FF FF s s rr cc xp yp

Кроме флагов «ss» ничего не используется. В будущем могут появиться и другие для сообщений в целях управления.

От сервера клиенту

Данные с сервера посылаются клиенту как поток символов. Обычные данные просто выводятся на клиентский дисплей, но могут быть обработаны перед этим (например, отступы).

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

  • 0x02 — клиент должен отменить все буферизированные данные, которые ещё не были выведены на экран
  • 0x10 — клиент должен переключиться в режим «raw»
  • 0х20 — клиент должен возобновить перехват символов и обработку символов НАЧАЛО и КОНЕЦ.
  • 0х80 — клиент должен ответить серверу, послав данные о размере окна (см. выше↑)

Все остальные значения управляющего байта игнорируются. Во всех случаях управляющий байт НЕ выводится на экран пользователя.

Завершение соединения

Когда TCP-соединение закрывается в любом из направлений, другой конец должен заметить это и провести закрытие со своей стороны, восстановив режимы терминалов и уведомив пользователя или процессы об обрыве соединения.

Безопасность

rlogin имеет несколько значительных недостатков в системе безопасности:

  • Вся информация, включая пароли, передаются без шифрования (перехват данных дал бы полный контроль над жертвой)
  • Легко воспользоваться файлом .rlogin (или .rhosts) в корыстных целях (открывается доступ к аккаунту anyone, у которого нет пароля) — по этой причине множество корпоративных системных администраторов запрещает .rlogin файлы и активно ищет правонарушителей в своих сетях
  • Протокол частично доверяет клиенту rlogin удалённой машины, предоставляя ему информацию честно (включая порт и имя хоста). Таким образом, злоумышленник может воспользоваться этим и получить доступ, в силу того, что этот протокол никак не подразделяет удалённые хосты на зоны доверия
  • Общая практика монтирования домашних каталогов пользователей через NFS (Network File System) подвергает rlogin атаке путём подделывания файлов .rhosts — это означает, что единственной защитой в этом случае является безопасность самой NFS.

Замены

Оригинальный Berkley-пакет, который предоставляет rlogin возможности rcp (remote-copy (удалённое копирование), которые позволяют копировать файлы по сети) и rsh (remote-shell, позволяющие выполнять команды на удалённых машинах без входа в систему пользователя).

Пакет ssh заменяет вышеописанные возможности и сам rlogin: scp заменяет rcp, сама ssh заменяет rlogin и rsh.

См. также

Литература