|
SSH (Secure Shell) . сетевой протокол, позволяющий удалённое управление компьютером и передачу файлов. Сходен по функциональности с протоколом Telnet и rlogin, однако использует алгоритмы шифрования передаваемой информации.
Криптографическая защита протокола SSH не фиксирована, возможен выбор различных алгоритмов шифрования. Клиенты и сервера этого протокола доступны для различных платформ.
Поддержка SSH реализована во всех UNIX системах, и на большинстве из них присутствует в качестве стандартной утилиты. Существует множество реализаций SSH-клиентов для других ОС. Большую популярность протокол получил после широкого развития sniffer.ов, как альтернативное небезопасному телнету приложение для управления важными узлами.
На данный момент известно две ветки версий . 1 и 2. Однако ветка 1 остановлена, так как в конце 90-x в ней было найдено много уязвимостей, некоторые из которых до сих пор накладывают серьёзные ограничения на её использование, поэтому перспективной, развивающейся и наиболее безопасной является версия 2.
Принципы работы SSH
Используемые порты: 22/tcp.
Представляет собой протоколы транспортного уровня, аутентификации и соединения (предполагается стандартизация IETF) и программные средства безопасного доступа к компьютерам по небезопасным каналам связи (telnet, X11, rsh, ftp). Аутентификация производится с использованием ассиметричного шифрования с открытым ключом (SSH1 - RSA, SSH2 - RSA/DSA, благо патент на RSA уже истек). Обмен данными - симметричное шифрование (IDEA - патентованный, DES, triple DES, BLOWFISH - быстрый, CAST128, AES/Rijndael). Целостность переданных данных проверяется с помощью CRC32 в SSH1 (подделывается при атаке типа "man in the middle") или HMAC-SHA1/HMAC-MD5 в SSH2. Протокол транспортного уровня работает поверх TCP, обеспечивает аутентификацию сервера. В качестве ключа используется случайная строка, которую генерирует клиент, шифрует с помощью открытого ключа сервера - его надо откуда-то получить - и передаёт ему (сервер знает свой частный ключ и дешифрует строку, затем передаёт её клиенту, если строка дешифрована правильно, значит сервер настоящий). Протокол аутентификации работает поверх протокола транспортного уровня, обеспечивает аутентификацию клиента для сервера. Протокол соединения - поверх протокола аутентификации, мультиплексирует безопасный канал. Шифрование начинается после аутентификации сервера, но до аутентификации клиента, т.е. паролей в открытом виде не передаётся вовсе.
SSH1 и SSH2 - совершенно разные протоколы (использование SSH1 не рекомендуется):
- SSH1 подвержен атаке типа "man in the middle"
- SSH1 поддерживает аутентификацию по .rhosts/hosts.equiv (хотя пользоваться этим не надо)
- SSH1 имеет поддержку разнообразных методов аутентификации клиента (AFS, Kerberos, etc.)
Каждый хост должен иметь не менее одного ключа (м.б. общий для нескольких хостов). Предполагается возможность работы с несколькими алгоритмами с открытым ключом, но пока он один - DSS (Digital Signature Standard).
SSH1: каждый хост имеет RSA ключ хоста (обычно 1024 бит), при запуске sshd генерирует временный (1 час, на диск не записывается) RSA ключ сервера (обычно 768 бит). После соединения клиента, сервер передает ему публичный ключ хоста и публичный ключ сервера. Клиент сверяет публичный ключ хоста со своей базой ключей, затем генерирует случайное число (256 бит) и шифрует его публичными ключами хоста и сервера, после чего отсылает серверу. В дальнейшем это случайное число используется как ключ сессии - с его помощью шифруются все сообщения. Алгоритм шифрования предлагается сервером и выбирается клиентом - 3DES (по умолчанию) или Blowfish (быстрее). Клиент пытается аутентифицировать себя с помощью .rhosts или др. механизма (см. ниже).
SSH2: Каждый хост имеет DSA/RSA ключ хоста. Ключ сервера не генерируется. Аутентификация сервера и ключ сессии обеспечивается с помощью алгоритма Diffie-Hellman. Остаток сессии шифруется симметричым алгоритмом шифрования: Blowfish, 3DES, CAST128, Arcfour, AES (128, 192, 256 бит). Целостность сессии обеспечивается hmac-sha1 или hmac-md5. Аутентификация клиента происходит с помощью публичных ключей или "обычных" паролей или интерактивного обмена с помощью дополнительных средств.
Модели аутентификации сервера:
- клиент имеет локальный файл, определяющий соответствие имени сервера и его открытого ключа
- клиент знает открытый ключ сертификационного агента, который отвечает за проверку имени хоста по его открытому ключ
Методы аутентификации клиента:
- SSH1: /etc/hosts.equiv, /etc/shosts.equiv, ~/.rhosts, ~/.shosts
- SSH1: RSA (ssh-keygen создает public/private ключи; открытый (public) ключ (из ~/.ssh/identity.pub) хранится на сервере в ~/.ssh/authorized_keys)
- SSH1: RSA в сочетании с .rhosts (хост клиента аутентифицируется по /etc/ssh_known_hosts, ~/.ssh/known_hosts)
- SSH1: разовые пароли s/key
- SSH1: kerberos
- SSH1, SSH2: пароли (шифруются при пересылке)
- SSH2: DSA (ssh-keygen создает public/private ключи; открытый (public) ключ (из ~/.ssh/dsa_id.pub) хранится на сервере в ~/.ssh/authorized_keys)
- SSH2: RSA (ssh-keygen создает public/private ключи; открытый (public) ключ (из ~/.ssh/rsa_id.pub) хранится на сервере в ~/.ssh/authorized_keys)
- SSH2: интерактивный обмен с помощью дополнительных средств (чтение карточек и т.д.)
Особености реализации в WTPRO
WTPRO поддерживает следующие алгоритмы:
- AES 128
- AES 256
- 3DES
- SHA1
- SHA1 96
- MD5
- RSA
- DSS
Поддерживаются следующие виды аутентификации:
Имя терминала: TERM='linux-koi8'
Переключение раскладки: Caps Lock
При первом подключении к серверу задается вопрос - подключаться к серверу или нет, это необходимо во избежании подмены ssh сервера злоумышленником. Для того чтобы вопрос больше не появлялся необхоимо получить через web интерфейс файл known_hosts и сохранить его в каталог conf на TFTP сервере или компакт диске.
|
