Введення в SSH
Технічна інформація про протокол SSH
У своїй роботі SSH задіє такі типи шифрування. аутентифікація проводиться з використанням асиметричного шифрування з відкритим ключем (версія SSH1 - RSA, SSH2 - RSA / DSA). Обмін даними під час встановленого з'єднання - сімметрічноешіфрованіе (IDEA - патентований, DES, triple DES (3DES), ARCFOUR, BLOWFISH, CAST128, AES / Rijndael). Цілісність переданих даних перевіряється за допомогою CRC32 в версії SSH1 і HMAC-SHA1 / HMAC-MD5 - в SSH2. Для стиснення шифрованих даних може використовуватися алгоритм LempelZiv (LZ77), який забезпечує такий же рівень стиснення, що і архіватор ZIP. Специфікація протоколу SSH-2 описана в RFC 4251.
Раніше (в SSH1) установка з'єднання відбувалася так: при першому підключенні клієнта до сервера (сервер в даному прикладі мається на увазі - комп'ютер, на якому працює демон sshd), клієнт отримував від сервера публічний ключ і зберігав його у своїй основі. При наступних з'єднаннях клієнт перевіряв чи не змінився даний ключ. Делее, клієнт генерував довільний 256-бітний набір символів і зашифровував цей набір публічним ключем. Сервер розшифровував цю фразу і відправляв клієнту. Клієнт, переконавшись, що розшифрована фраза валидна - встановлював з'єднання і дана фраза використовувалася далі клієнтом і сервером як сесійний ключ для шифрування даних, що передаються.
У сучасній реалізації (SSH2) використовується набагато складніший алгоритм (алгоритм Diffie-Hellman'а. Описаний в rfc4419).
Архітектуру протоколу SSH можна розділити на кілька рівнів:
Транспортний рівень RFC 4253 - працює поверх протоколу TCP. забезпечує початковий обмін ключами, встановлює шифрування, стиснення і перевірку цілісності. Рівень аутентифікації RFC 4252 - працює поверх транспортного рівня. забезпечує аутентифікацію клієнта і сервера. Найбільш популярні методи аутентифікації ssh:
- Парольная - метод на основі простого введення пароля.
- Публічний ключ - метод на основі публічного RSA / DSA ключа
- Інтерактивний - метод, коли сервер посилає один або кілька запитів введення інформації клієнту, а клієнт відображає їх і відправляє назад сервера відповіді введені користувачем. Використовується при одноразових паролів аутентифікації.
- GSSAPI - методи аутентифікації, які забезпечують аутентифікацію з використанням зовнішніх механізмів, таких як Kerberos 5 або NTLM.
Протокол з'єднання RFC 4254 - працює поверх протоколу аутентифікації. дозволяє використовувати встановлений безпечний канал для передачі декількох потоків інформації в обох напрямках. Використовується для роботи в короби, тунелювання трафіку або копіювання файлів.
Установка OpenSSH в Debian
В Debian OpenSSH представлений декількома пакетами:
основні - це openssh-server і openssh-client. При цьому, останній найчастіше встановлюється разом з системою. Отже, щоб встановити ssh сервер в Debian Squeeze. досить виконати команду:
Під час виконання установки будуть автоматично згенеровані необхідні ключі шифрування (RSA і DSA). демон sshd буде додано до автозавантаження і запущений. На цьому за великим рахунком, можна вважати сервер SSH цілком працездатним. Але налаштування за замовчуванням, не зовсім коректні і безпечні.
OpenSSH в реалізації Debian містить наступні компоненти / команди:
Власне, клієнт ssh.
Клієнт для віддаленого копіювання файлів по протоколу SSH.
FTP-подібний SSH клієнт.
Демон, власне надає захищений доступ до ресурсів.
Окрема реалізація підсистеми SFTP (серверна частина). Володіє більшими можливостями, ніж вбудована в sshd.
Генератор пар ключів.
Утиліта для перевірки ключів хостів. Задіюється при використанні аутентифікації по хостам (аналогічно rsh) замість проведеної за замовчуванням аутентифікації по користувачам / паролів.
Допоміжна утиліта. Дозволяє за лічені секунди зібрати публічні ключі з інших хостів.
Допоміжна утиліта. Підтримує кеш закритих ключів. Кешування дозволяє уникати частого введення пароля для розшифровки ключів перед їх використанням.
Допоміжна утиліта. Додає ключі в кеш ssh-agent.
клієнти SSH
/.ssh/config. при цьому, останній має більший пріоритет. Опис даного файлу наведено в man (5) ssh_config. Найчастіше, настройки клієнта немає необхідності змінювати. Конфігураційний файл SSH клієнта ssh_config:
Для того, щоб вдало скористатися SSH клієнтом за призначенням, необхідно: мати сервер з що виконуються демоном sshd, мати обліковий запис на віддаленій системі. В Debian найбільш часто використовуваний клієнт, це утиліта ssh (пакет openssh-client). Формат використання команди наведено в man ssh. Коротко, формат команди ssh має вигляд:
Перша частина - це власне команда ssh. далі можливі опції (наприклад -p port задасть нестандартний порт), далі можлива вказівка імені користувача від імені якого необхідно залогінется на віддалену систему. Якщо ім'я користувача не вказано, то з'єднання буде встановлено від імені поточного користувача. Далі йде обов'язковий параметр - DNS ім'я або IP віддаленого хоста. Якщо віслюку імені хоста заданна якась команда, то ця команда буде виконана і з'єднання буде розірвано, якщо команда не задана, то буде запущений інтерпретатор.
При першому підключенні до сервера, ssh клієнт видає приблизно наступне повідомлення:
Дане повідомлення говорить нам, що ми підключаємося до невідомого раніше хосту з RSA ключем, що має такий-то відбиток і потрібне підтвердження нашого підключення. При позитивній відповіді (yes), клієнт додає публічний ключ сервера sshd (/etc/ssh/ssh_host_rsa_key.pub) в призначений для користувача файл
/.ssh/ known_hosts на локальному комп'ютері. Коли клієнт з'єднується з декількома серверами в зазначеному файлі може зібратися велика кількість таких ключів. Для відстеження приналежності кожного ключа до кожного сервера, клієнт додає до рядка ключа IP сервера і тип шифрування.
Крім зазначеного призначеного для користувача файлу для "відомих хостів серверів" існує так само глобальний файл / etc / ssh / ssh_known_hosts. До глобального файлу повинні мати доступ на читання всі користувачі і використовувати інформацію при підключенні до якого-небудь сервера, але на запис повинен мати право тільки користувач root. Як розмежувати права доступу до файлів. Давайте розглянемо вміст файлу known_hosts на прикладі:
У прикладі рядок навмисно розбита на кілька, але реально це один рядок. Крім команди ssh в OpenSSH існує команда scp. яка по синтаксисі дуже схожа на cp. за тим винятком, що до шляху копіюється додаються деякі параметри:
де src_host - хост джерело, / path / src / file - вихідний копіюється об'єкт, dst_host - хост призначення, / path / dst / file - файл призначення.
Аліаси для ssh клієнта (
За допомогою конфігураційного файлу користувача можна зробити використання ssh клієнта більш зручним. Припустимо, маємо ми деякий глобальний файл / etc / ssh / ssh_config. задає настройки для всіх хостів (host *). При цьому, маємо деякий віддалений ssh сервер, у якого довге ім'я (наприклад 678-ssh-server.superdomen.com.ua) і нестандартний порт (наприклад 65987), при цьому, ім'я користувача теж досить довге (наприклад, vasilii-ptrov) . Вводити кожен раз команду підключення до сервера:
дуже незручно і довго. Давайте спростимо собі життя. У файл
/.ssh/config додамо наступну інформацію:
Усе! тепер ввівши в консолі ssh server ми потрапляємо на потрібний сервер, потрібні порт під потрібним користувачем. Або навіть так ssh se
Інші клієнти SSH
Крім стандартного linux-ssh-клієнта існує і безліч інших, наприклад для Windows є відмінна софтіна PuTTy.
Сервер OpenSSH (sshd)
Ознайомившись з конфіг ми можемо сміливо налаштувати сервер під свої потрібні. Деякі рекомендації та приклади наведені нижче. Після редагування sshd_config необхідно перезапустити сервер sshd:
У OpenSSH тимчасово можна заборонити будь-які з'єднання з сервером, крім користувача root. Для цього, необхідно створити файл / etc / nologin. при існуванні даного файлу, сервер sshd виводить його
/.ssh/содержімое і не позволяє / strong / strongт зробити вхід для будь-якого користувача крім користувача root.
Типи аутентифікації OpenSSH
Аутентифікація користувача за паролем.
При даному типі аутентифікації, налаштувань сервера sshd і клієнта ssh за замовчуванням цілком достатньо. При аутентифікації спочатку проводиться обмін ключами між сервером і клієнтом і хеш пароля передається серверу в зашифрованому вигляді. Далі проводиться обмін даними.
Аутентифікація користувача по його публічному ключу.
Даний тип аутентифікації може позбавити від введення пароля при підключенні до сервера. Аутентифікація з публічного ключу заснована на перевірці відповідності публічного ключа клієнта. який розміщується на сервері і секретного ключа клієнта (користувача). який розташований у клієнта (у користувача в домашньому каталозі
/.ssh/id_rsa). Приблизно так само, як клієнт перевіряє валідність сервера з публічного ключу сервера. Генерація пари ключів здійснюється утилітою ssh-keygen. після чого в каталозі користувача утворюється 2 ключа
/.ssh/id_rsa - секретний і
/.ssh/id_rsa.pub - публічний. Публічний ключ поміщається на сервер під ім'ям
/.ssh/authorized_keys. Після цього при підключенні до сервера під користувачем, у каталогах якого лежать відповідні ключі (на клієнті -
/.ssh/id_rsa. на сервері -
/.ssh/authorized_keys) - немає необхідності вводити пароль. У файлі
/.ssh/authorized_keys може послідовно міститися кілька ключів для доступу до даного сервера під даним користувачем з декількох серверів. Давайте розглянемо практичний приклад налаштування аутентифікації по публічному ключу:
Для вказівки типу шифрування ключа заданий параметр -t. а так же параметр -b. задає розмір ключа в байтах. Ці опції використовувати рекомендується. Крім того, при створенні ключа запитується якась passphrase. Це пароль розшифровки секретного ключа. який (якщо його поставити) буде запитано при спробі підключення. Дана опція дозволяє зашифрувати секретний ключ на випадок компрометації, що підвищує безпеку, але зводить нанівець всю зручність входу без введення пароля.
Так само, обов'язково варто відзначити такий момент безпеки. У разі, якщо поламають вашу учетку (у якій є секретний ключ в домашньому каталозі) на поточному сервері, то зловмисник автоматично отримує доступ і до сервера, на якому лежить відповідний публічний ключ. Так що будьте вкрай пильні!
В даному розділі використовується метод шифрування RSA. але якщо у всіх командах замінити RSA на DSA. то відповідно буде використаний тип шифрування DSA.
Інші типи аутентифікації (hostbsed, GSSAPI.)
Деякі інші типи аутентифікації, можливо, незабаром будуть доповнені. Але деякі гарантовано не будуть розглянуті, тому що - застарілі. Наприклад, не буде розглянута hostbased-аутентифікація. яка працює тільки з протоколом SSH1.
Безпека SSH сервера
Нижче наведені деякі поради, що дозволяють по максимуму знизити можливість злому Вашого сервера:
Існує кілька місць, куди можна звернутися за дозволом проблем з ssh. Для початку, можна подивитися записи, які стосуються ssh в журналах /var/log/autch.log і / var / log / syslog. Ось невеликий приклад, коли сервер працював на стандартному порту, кожну хвилину з інтернету були спроби підібрати пароль:
Як видно, майже кожну секунду сервер намагаються зламати з "популярними" іменами користувачів (root, nobody і ін.)
Робота OpenSSH в режимі налагодження
Якщо інформації з системних журналів недостатньо, то можна запустити sshd в debug-режимі. вказавши в параметрах запуску демона (/ etc / defauts / ssh) ключ -d. Так само, для діагностики відмінно підійде запуск клієнта ssh з ключем -v (для бОльшей подробиці можна задати -vv).
Перевірка роботи sshd (чи запущений процес, чи слухає порт):
Перевірити чи запущений sshd можна командою:
Перевірити, слухається чи необхідний порт можна командою:
- RFC 4250 (англ.) - The Secure Shell (SSH) Protocol Assigned Numbers
- RFC 4251 (англ.) - The Secure Shell (SSH) Protocol Architecture
- RFC 4252 (англ.) - The Secure Shell (SSH) Authentication Protocol
- RFC 4253 (англ.) - The Secure Shell (SSH) Transport Layer Protocol
- RFC 4254 (англ.) - The Secure Shell (SSH) Connection Protocol
- RFC 4255 (англ.) - Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
- RFC 4256 (англ.) - Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
- RFC 4335 (англ.) - The Secure Shell (SSH) Session Channel Break Extension
- RFC 4344 (англ.) - The Secure Shell (SSH) Transport Layer Encryption Modes
- RFC 4345 (англ.) - Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol
- RFC 4419 (англ.) - Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
- RFC 4432 (англ.) - RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
- RFC 4716 (англ.) - The Secure Shell (SSH) Public Key File Format
З повагою, Mc.Sim!