Длинные руки

Писано для журнала "Хакер-Спец". Лексика оригинала сохранена.

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

Ой-ой-ой... Отмахиваюсь от твоих размахивающихся ручёнок. Да, да.. Ты знаешь про такой протокол как telnet и даже, возможно, что-то слыхивал про такую шнягу как ssh. Ну и что из этого? Да я твою голову даю на отсечение, что ты практически больше ничего про эти программы и не знаешь.

Начну, пожалуй с краткой исторической справки. Telnet относится к группе самых древних протоколов управления удалённой системой. Он был разработан несколько десятков лет назад на заре развития сети ARPANET, ставшей “мамой” современного Интернет. Именно в то время родилась идея, использовать программу, которая позволяла видеть экран удаленного компьютера, и посылать ему нажатия на клавиатуру так, как если бы ты сам сидел за клавой удалённой машины.

Для успешного использования данного протокола требуются две вещи. Сервер и клиент. Серверная часть (демон telnetd) выполняется на удалённом компьютере (хост-сервер), которым требуется управлять. Клиентская программа называется, угадай с трёх раз, правильно, telnet, и выполняется на твоём компьютере (хост-клиент). Она имеет и свой набор команд, которые управляют собственно этой программой и сеансом связи, его параметрами, открытием новых, закрытием и т.д.; эти команды подаются из командного режима telnet, в который можно перейти, нажав, так называемую, escape-последовательность клавиш, которая тебе сообщается в начале сеанса. Традиционно это Ctrl-]. Эту последовательность можно переопределить по своему усмотрению в командном режиме. Читай man telnet до полного просветления.

Telnet является протоколом прикладного уровня. То есть все сообщения для управления хост-сервером и удаленным терминалом передаются при помощи транспортного протокола TCP. Это только на первый взгляд кажется, что кроме установления соединения с удалённым сервером клиент telnet ничего не умеет. Если копнуть глубже, то тебе откроются совершенно неожиданные вещи. Подробности ты можешь посмотреть сам, прогулявшись на сайт http://www.omnifarious.org/~hopper/technical/telnet-rfc.html. Не удивлюсь, если ты вдруг обнаружишь, что сквозь этот протокол можно работать не только в текстовом режиме, но и запускать удалённые графичесские приложения. Возможности протокола telnet описывают десятки различных документов RFC (Request For Comment).

И серверная (вдруг тебе потребуется) и клиентская программы являются практически неотъемлемой частью любого дистрибутива Linux. В моём ALT Linux Master 2.2 поставляются два пакета: telnet и telnet-server. Не думаю, что у тебя возникнут пролемы с установкой.

Ок. Подключение (установление сессии) производится крайне просто, командой telnet адрес [порт], где адрес – IP-адрес удаленной ссистемы, а необязательный параметр “порт” указывает к какой сервисной службе подключаться. Подключившись к telnet-серверу ты сразу получаешь приглашение ввести имя пользователя и пароль. Короче, картинка таже самая, как если бы ты сам сидел за клавой далёкой машины. Единственное, что тебя будет отрезвлять, так это более длительное время ожидания отклика на нажатие клавиши. Ну это-то понятно, расстояние и дохлые каналы свою роль таки играют.

Также хочу сказать, что уже пару десятков лет telnet-серверы не используютcя. Причиной этого стала абсолютная незащищенность протокола перед атаками типа man-in-middle. Грубо говоря, если тебя сниферят, прослушивают твой трафик, то все передаваемые данные доступны злоумышленнику.

Тем не менее telnet можно использовать для имитации клиентской программы при подключении к удалённому сетевому сервису. На приведенном рисунке показано использование telnet-клиента для имитации работы почтового клиента.

Недостатки в безопасности можно обойти, если шифровать трафик между сервером и клиентом. Не мы одни такие умные, и спецификации безопасного шелла (secure shell) под названием ssh были опубликованы в соответствующем документе rfc (http://www.free.lp.se/fish/rfc.txt).

В настоящий момент широко известны две реализации протокола. Одна из них делается коммерческим предприятием SSH Inc. ( http://www.ssh.com) и закрыта, хотя программа бесплатна для некоммерческого использования. Вторая реализация поддерживается проектом OpenSSH (http://www.openssh.org), исходные тексты которого открыты и лицензионно свободны. Обе реализации совместимы друг с другом. Клиент из пакета проекта OpenSSH вполне прекрасно работает с сервером из поставки компании SSH Inc.

Протокол существует в двух версиях, несовместимых друг с другом. Это означает, что клиент версии ssh1 не будет работать с сервером ssh2 и наоборот. Это связано с использованием разных алгоритмов шифрования трафика и изменениями в процедуре установления сессии. В версии ssh1 были обнаружены недостатки как в алгоритмах шифрования, так и в программах. Знаменитый эксплоит SSHNuke против ssh1 был использован Тринити в фильме Матрица-2. Так как ssh1 практически нигде не применяется, дальнейшее моё повествование будет касаться программ версии ssh2.

Свободная и коммерческая реализации ssh2 содержат приктический одинаковый набор программ. Приведу некоторый список:

sshd – Серверная часть (демон), запускаемая на сервере. Прослушивает соединения от клиентских машин и при установлении связи производит аутентикацию и начинает обслуживание клиента.

ssh - Программа клиент, используемая для входа на удаленную машину или выполнения команд на другой машине.

scp - Секретное копирование файлов с одной машины на другую.

ssh-keygen - Используется для создания RSA ключей машины и пользователя (host keys and user authentication keys).

ssh-agent - Программа автоматизации аутентикации. Она может быть использована для хранения в памяти ключей для аутентикации.

ssh-add - Используется для регистрации новых ключей с агентом.

sftp – Защищённый клиент ftp. Серверная часть обеспечивается демоном sshd.

Установка коммерческой версии ssh2 особых проблем не доставляет. Ты скачиваешь архив удобном для тебя формате, устанавливаешь его, и приступаешь к настройке. Процедуру установки свободного openssh тоже расписывать нет особой нужды. Если у тебя есть опыт самостоятельной сборки и установки приложений Linux, openssh тебя не испугает. Опять же, большинство дистрибутивов Linux включают openssh в комплект, тебе останется лишь установить его.

Как бы то ни было, при работе с ssh у тебя 100% возникнет ряд вопросов. Отвечаю сразу на несколько. В отличие от telnet при работе ssh соединение зашифровывается сразу после подключения клиента к серверу. Алгоритм шифрования RSA не требует секретности ключа для шифрования. Секретным должен быть ключ для расшифрования, а он всегда остается на стороне сервера и перехватить его невозможно.

Для увеличения безопасности соединения можно настроить аутентификацию пользователя на сервере не по системному паролю, а по ключевой фразе. Для этого тебе нужно будет сгенерировать пару ключей: открытый (публичный) и секретный (man ssh-keygen). Открытый ключ можно растпространить на те клиентские рабочие места с которых ты будешь заходить на сервер. И для openssh и для ssh процедура генерирования и использования ключей практически одинакова. Различия лишь в именованиях файлов и каталогов. Подробнее ты прочесть можешь в моём переводе руководства по ssh по адресу http://www.linux.ru.net/index.php?module=library&action=show&docid=196&part=1849.

Также очень много расписано тут http://www.opennet.ru/base/sec/lavr-ssh.1.txt.html и тут http://www.opennet.ru/docs/RUS/ssh_faq/ssh-faqr.html#toc. Оба этих документа расскажут тебе о принципах работы ssh и дадут практический материал.

Успешно установленный и настроенный пакет на сервере дадут тебе возможность работать точно также, как если бы ты использовал telnet. Ощущение того, что ты за клавой просто потрясающие. На рисунке показан процесс соединения с удалённой машиной на которой работает ssh-сервер. Так как мой клиент с ним ни разу до этого с этой машиной не соединялся, сервер предложил мне свой открытый ключ и спросил, продолжать ли мне соединение. Ответив ДА я сохранил этот ключ, с этого момента КАЖДЫЙ передаваемый мной пакет байтов будет шифроваться этим ключом. Причем клиентская программа это делает сама. Так как у меня нет заранее сгенерированной пары ключей, то мне пришлось не сервере вводить свой системный пароль. Кроме того, на сервере работает коммерчесский ssh, а на клиенте openssh. Такие вот дела.

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

---

---