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.

См. также[править | править код]

Литература[править | править код]

Источник — https://ru.wikipedia.org/w/index.php?title=Rlogin&oldid=132150228