Перші кроки по налаштуванню і використанню SSH

Перші кроки по налаштуванню і використанню SSH практичний посібник Що таке SSH? Короткий опис
Малюнок 1. Підключення з використанням протоколу telnet не зашифровані
Малюнок 2. Підключення з використанням протоколу SSH зашифровані
архітектура SSH
Малюнок 3. Логічні рівні протоколу SSH
Малюнок 4. SSH в 7-рівневої моделі OSI
Корисні поради по налаштуванню і використанню SSH
Відкриті та закриті ключі SSH
Малюнок 5. Діаграма взаємодій відкритих і закритих SSH-ключів згідно архітектурі SSH
Лістинг 1. Генерація пари SSH-ключів
Лістинг 2. Копіювання відкритого ключа з комп'ютера-джерела в файл authorized_keys на цільовому комп'ютері
Лістинг 3. Перевірка SSH-доступу за допомогою запуску команди на віддаленому комп'ютері
Конфігурація и использование утіліті ssh-agent
Лістинг 4. Приклад використання ssh-keyscan
Використання SSH в додатках і сценаріях UNIX
Лістинг 5. Приклад настройки обмежень з використанням файлу authorized_keys на віддаленому комп'ютері
Створення середовища довірених вузлів за допомогою SSH
Таблиця 1. Порівняння можливостей аутентифікації на основі SSH-ключів і на основі довірених вузлів
Висновок
Ресурси для скачування
Перші кроки по налаштуванню і використанню SSH
Що таке SSH? Короткий опис
Малюнок 1. Підключення з використанням протоколу telnet не зашифровані
Малюнок 2. Підключення з використанням протоколу SSH зашифровані
архітектура SSH
Малюнок 3. Логічні рівні протоколу SSH
Малюнок 4. SSH в 7-рівневої моделі OSI
Корисні поради по налаштуванню і використанню SSH
Відкриті і закриті ключі SSH
Малюнок 5. Діаграма взаємодій відкритих і закритих SSH-ключів згідно архітектурі SSH
Лістинг 1. Генерація пари SSH-ключів
Лістинг 2. Копіювання відкритого ключа з комп'ютера-джерела в файл authorized_keys на цільовому комп'ютері
Лістинг 3. Перевірка SSH-доступу за допомогою запуску команди на віддаленому комп'ютері
Перші кроки по налаштуванню і використанню SSH
Що таке SSH? Короткий опис
Малюнок 1. Підключення з використанням протоколу telnet не зашифровані
Малюнок 2. Підключення з використанням протоколу SSH зашифровані
архітектура SSH
Малюнок 3. Логічні рівні протоколу SSH
Малюнок 4. SSH в 7-рівневої моделі OSI
Корисні поради по налаштуванню і використанню SSH
Відкриті та закриті ключі SSH
Малюнок 5. Діаграма взаємодій відкритих і закритих SSH-ключів згідно архітектурі SSH
Лістинг 1. Генерація пари SSH-ключів
Лістинг 2. Копіювання відкритого ключа з комп'ютера-джерела в файл authorized_keys на цільовому комп'ютері
Лістинг 3. Перевірка SSH-доступу за допомогою запуску команди на віддаленому комп'ютері
Конфігурація и использование утіліті ssh-agent
Лістинг 4. Приклад використання ssh-keyscan
Використання SSH в додатках і сценаріях UNIX
Лістинг 5. Приклад настройки обмежень з використанням файлу authorized_keys на віддаленому комп'ютері
Створення середовища довірених вузлів за допомогою SSH
Таблиця 1. Порівняння можливостей аутентифікації на основі SSH-ключів і на основі довірених вузлів
Висновок
Ресурси для скачування
Перші кроки по налаштуванню і використанню SSH
Що таке SSH? Короткий опис
Малюнок 1. Підключення з використанням протоколу telnet не зашифровані
Малюнок 2. Підключення з використанням протоколу SSH зашифровані
архітектура SSH
Малюнок 3. Логічні рівні протоколу SSH
Малюнок 4. SSH в 7-рівневої моделі OSI
Корисні поради по налаштуванню і використанню SSH
Відкриті та закриті ключі SSH
Малюнок 5. Діаграма взаємодій відкритих і закритих SSH-ключів згідно архітектурі SSH
Лістинг 1. Генерація пари SSH-ключів
Лістинг 2. Копіювання відкритого ключа з комп'ютера-джерела в файл authorized_keys на цільовому комп'ютері
Лістинг 3. Перевірка SSH-доступу за допомогою запуску команди на віддаленому комп'ютері
Конфігурація і використання утиліти ssh-agent
Лістинг 4. Приклад використання ssh-keyscan
Використання SSH в додатках і сценаріях UNIX
Лістинг 5. Приклад настройки обмежень з використанням файлу authorized_keys на віддаленому комп'ютері
Створення середовища довірених вузлів за допомогою SSH
Таблиця 1. Порівняння можливостей аутентифікації на основі SSH-ключів і на основі довірених вузлів
висновок
Ресурси для скачування

Перші кроки по налаштуванню і використанню SSH
практичний посібник

Що таке SSH? Короткий опис

Протокол Secure Shell (SSH) був розроблений для максимального захисту мережевих взаємодій з віддаленими вузлами мережі. Цей протокол шифрує мережевий трафік за допомогою поліпшених можливостей аутентифікації, а також функцій, спрямованої на захист інших незахищених протоколів - таких як захищене копіювання (Secure Copy, SCP), захищений протокол передачі файлів (Secure File Transfer Protocol, SFTP), перенаправлення X-сеансів і перенаправлення портів. Підтримується кілька типів шифрування (починаючи від 512-бітного і закінчуючи 32768-бітовим) з використанням різних криптографічних алгоритмів - Blowfish, Triple DES, CAST-128, Advanced Encryption Scheme (AES) і ARCFOUR. Чим вище розрядність шифрування, тим більший обсяг трафіку генерується в мережі. з малюнка 1 видно, як будь-який користувач мережі може з легкістю переглянути трафік telnet-підключення за допомогою аналізатора мережевих пакетів (наприклад, Wireshark).

Малюнок 1. Підключення з використанням протоколу telnet не зашифровані

Часто використовувані скорочення

API: Application programming interface - інтерфейс прикладного програмування
FTP: File Transfer Protocol - протокол передачі файлів
IETF: Internet Engineering Task Force - інженерна група з розвитку Інтернету
POSIX: Portable Operating System Interface for UNIX - інтерфейс яку переносять операційної системи для UNIX
RFC: Request for Comments - документ RFC, запит на коментар
VPN: Virtual private network - віртуальна приватна мережа

Якщо ви використовуєте незахищений "відкритий" протокол (наприклад, telnet), то будь-який користувач мережі може підглянути ваші паролі та іншу секретну інформацію. на малюнку 1 зображена схема підключення користувача fsmythe до віддаленого вузла з використанням telnet. Користувач вводить своє ім'я fsmythe і пароль r @ m $ 20! 0, які може бачити будь-який користувач, що знаходиться в тій же мережі, що і наш нічого не підозрюючи користувач telnet.

Малюнок 2. Підключення з використанням протоколу SSH зашифровані

на малюнку 2 зображена типова схема SSH-підключення, і ми бачимо, що ніякої користувач мережі не може переглядати зашифрований трафік. Пакети SSH (як правило, це Open Source-пакет OpenSSH) за замовчуванням встановлені у всіх поширених дистрибутивах Linux® і UNIX®, тому вам навряд чи доведеться завантажувати і компілювати їх з вихідного коду. Якщо ви не працюєте в Linux або UNIX, то існує безліч підтримуваних безкоштовних SSH-інструментів, наприклад, WinSCP , Putty , FileZilla , TTSSH і Cygwin (Програмне забезпечення POSIX, яке встановлюється в операційній системі Windows®). Ці інструменти працюють під управлінням операційної системи Windows і мають інтерфейс командної оболонки UNIX або Linux.

Незалежно від операційної системи SSH надає безліч переваг при повсякденній роботі з комп'ютером. Цей протокол не тільки надійний, безпечний і гнучкий, але і простий в установці, налаштуванні і використанні, не кажучи вже про його численних можливостях.

архітектура SSH

У документах IETF RFC 4251-4256 дається таке визначення SSH: "Протокол SSH використовується для організації безпечного входу в віддалену систему і організації інших безпечних служб через мережі, які не забезпечують безпеки". Протокол включає три основних компоненти ( малюнок 3 ):

Протокол транспортного рівня: забезпечує аутентифікацію серверів, конфіденційність і цілісність. Цей протокол може також забезпечувати стиск інформації і працює в основному з використанням з'єднань TCP / IP, але може бути реалізований і на базі інших потоків даних з гарантованою доставкою.
Протокол аутентифікації користувачів: використовується на серверах для перевірки справжності клієнтів і працює на основі протоколу транспортного рівня.
Протокол з'єднань: забезпечує мультиплексування шифрованого тунелю в кілька логічних каналів і працює поверх протоколу аутентифікації користувачів.

Малюнок 3. Логічні рівні протоколу SSH

Транспортний рівень відповідає за обмін ключами і аутентифікацію серверів. На цьому рівні забезпечується підтримка шифрування, перевірки цілісності і стиснення даних (при необхідності), після чого на верхній рівень передається API-інтерфейс для відправки та отримання нешифрованих текстових пакетів. Рівень аутентифікації користувачів забезпечує перевірку автентичності клієнтів за допомогою різних методів. Найбільш поширені методи аутентифікації включають в себе використання паролів і відкритих ключів, введення даних з клавіатури, інтерфейс GSSAPI, технологію SecureID, а також різні модулі аутентифікації (PAM).

На рівні з'єднань визначаються канали, глобальні запити, а також запити на надання каналів, через які надаються служби SSH. Одне SSH-з'єднання може одночасно включати в себе кілька каналів, в кожному з яких відбувається двунаправленная передача даних. Запити на надання каналів використовують таку інформацію, як код завершення процесу на стороні сервера. SSH-клієнт ініціює запит для пересилки в порт на стороні сервера.

Ця відкрита архітектура має велику гнучкість. Транспортний рівень сумісний з протоколом Transport Layer Security (TLS), і ви можете реалізовувати власні методи перевірки автентичності, розширюючи рівень аутентифікації користувачів. Рівень з'єднань дозволяє об'єднувати в одному SSH-підключенні кілька сеансів ( малюнок 4 ).

Малюнок 4. SSH в 7-рівневої моделі OSI

Приклади типового використання SSH в операційних системах UNIX та Linux

Як правило, SSH використовується для того, щоб користувачі могли підключатися до віддалених комп'ютерів і виконувати на них різні команди. Однак SSH також підтримує тунелювання і X11-з'єднання і навіть дозволяє передавати файли за допомогою SFTP і SCP. SSH можна використовувати в безлічі додатків для різних платформ, включаючи Linux, UNIX, Windows і Apple® OS X (для запуску деяких програм можуть знадобитися додаткові можливості, доступні або сумісні тільки з певними SSH-клієнтами або SSH-серверами).

Розглянемо кілька загальних прикладів синтаксису SSH:

Доступ до командної оболонки віддаленого комп'ютера (замість використання незахищених протоколів telnet і rlogin): # ssh [email protected] [[email protected]] ~
Виконання окремої команди на віддаленому комп'ютері (замість використання rsh) # ssh [email protected] reboot [email protected]'s password: ******
Копіювання файлів з локального сервера на віддалений комп'ютер за допомогою команди SCP: [email protected]'s password: ****** file1.txt 100% 0 0.0KB / s 00:00 file2.txt 100% 0 0.0KB / s 00:00
Захищена передача файлів за допомогою SFTP (замість використання FTP): sftp [email protected] Connecting to example.com ... [email protected]'s password: ******* sftp>
Ефективні та безпечні процедури резервного копіювання, синхронізації і віддзеркалення файлів на локальний або віддалений комп'ютер за допомогою rsync: # rsync -avul --rsh = ssh / opt / edbdata / [email protected]: / root / backup / [email protected]'s password: ****** building file list ... done ./ file1.txt file2.txt file3.txt file4.txt dir1 / file5.txt dir2 / file6.txt sent 982813 bytes received 2116 bytes 1374860.38 bytes / sec total size is 982138 speedup is 1.00
Перенаправлення або туннелирование порту (не плутайте з VPN): ssh -L 8000: mailserver: 110 example.com [email protected]'s password: ********
Перенаправлення X-сеансів з віддаленого комп'ютера (може здійснюватися через кілька проміжних вузлів): Edit / etc / ssh / sshd_config and change 2 keywords: AllowTcpForwarding yes X11Forwarding yes # service sshd restart $ export DISPLAY $ ssh -X [email protected]
Конфігурація з перенаправленням X11, яка використовується спільно з клієнтом X Windows, в якому налаштований SSH-тунелювання X11. Це дозволяє використовувати графічну підсистему UNIX або Linux через захищене SSH-з'єднання на локальному комп'ютері з Windows, підключеному через SSH до віддаленого вузла Linux або UNIX: ssh -ND 8000 [email protected] Browser Settings, goto 'Manual Proxy Configuration' set "SOCKS Host "to example.com, the 'Port to 8000', Enable SOCKS v5, and lastly set 'No Proxy for' field to 'localhost, 127.0.0.1'
Безпечне монтування директорії віддаленого сервера в якості файлової системи локального комп'ютера за допомогою sshfs: # yum install sshfs fuse-utils (Install sshfs and fuse-utils) $ sshfs example.com:/remote_dir / mnt / local_dir
Автоматизоване спостереження і керування віддаленими серверами за допомогою різних засобів: (Report number of apache processes running on the remote server example.com): $ ssh example.com ps -ef | grep httpd | wc -l [email protected]'s password: *****

Корисні поради по налаштуванню і використанню SSH

У деяких випадках, які були розглянуті вище, у багатьох досвідчених системних адміністраторів виникає занепокоєння щодо безпечної реалізації ряду функцій і методів використання SSH. Незважаючи на велику кількість матеріалів і статей, присвячених різним підходам до безпеки SSH і захисту віддалених комп'ютерів в цілому, ми наведемо тут кілька команд і конфігурацій, які можна використовувати для посилення захисту віддаленого доступу за допомогою SSH:

Забороніть віддалені підключення користувачам з привілеями root: # vi / etc / ssh / sshd_config PermitRootLogin no
Створюйте пари ключів (відкритий / закритий) з використанням стійких ідентифікаційних фраз і захищайте закритий ключ паролем (ніколи не генеруйте пари ключів або ідентифікаційні фрази без використання паролів): (Use a higher bit rate for the encryption for more security) ssh-keygen -t rsa -b 4096
Налаштуйте обробники TCP (TCP wrappers) таким чином, щоб дозволяти підключатися тільки певним віддалених комп'ютерів, а всім іншим - забороняти: # vi /etc/hosts.deny ALL: 192.168.200.09 # IP Address of badguy
Вимикайте функціональність SSH-сервера на робочих станціях і ноутбуках - для цього вимкніть службу SSH, а потім видаліть пакет SSH-сервера: # chkconfig sshd off # yum erase openssh-server
Керуйте дозволами на SSH-підключення за допомогою облікових записів: # vi / etc / ssh / sshd_config AllowUsers fsmythe bnice swilson DenyUsers jhacker joebadguy jripper
Використовуйте тільки протокол SSH версії 2: # vi / etc / ssh / sshd_config Protocol 2
Закривайте неактивні підключення, вказавши час простою: # vi / etc / ssh / sshd_config ClientAliveInterval 600 # (Set to 600 seconds = 10 minutes) ClientAliveCountMax 0
Забороняйте аутентифікацію на основі хоста: # vi / etc / ssh / sshd_config HostbasedAuthentication no
Вимикайте призначені для користувача файли .rhosts: # vi / etc / ssh / sshd_config IgnoreRhosts yes
Налаштуйте брандмауер таким чином, щоб дозволяти вхідні SSH-підключення тільки з довірених мереж: Update / etc / sysconfig / iptables (Redhat specific file) to accept connection only from 192.168.100.0/24 and 209.64.100.5/27, enter: -A RH -FW-1-INPUT -s 192.168.100.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT -A RH-FW-1-INPUT -s 209.64.100.5/27 -m state - -state NEW -p tcp --dport 22 -j ACCEPT
Явно вказуйте мережеві інтерфейси, які повинні приймати вхідні SSH-підключення: # vi / etc / ssh / sshd_config ListenAddress 192.168.100.17 ListenAddress 209.64.100.15
Налаштуйте політики користувачів на використання стійких паролів, що забезпечують захист від атак за допомогою повного перебору, соціальної інженерії і підбору за словниками: # </ dev / urandom tr -dc A-Za-z0-9_ | head -c8 oP0FNAUt [
Обмежуйте доступ SFTP-користувачів їх домашніми директоріями за допомогою параметра Chroot SSHD: # vi / etc / ssh / sshd_config ChrootDirectory / data01 / home /% u X11Forwarding no AllowTcpForwarding no
Забороняйте використання порожніх паролів: # vi / etc / ssh / sshd_config PermitEmptyPasswords no
Обмежуйте кількість вхідних з'єднань на порт 2022 в певний інтервал часу: Redhat iptables example (Update / etc / sysconfig / iptables): -A INPUT -i eth0 -p tcp --dport 2022 -m state --state NEW -m limit - limit 3 / min --limit-burst 3 -j ACCEPT -A INPUT -i eth0 -p tcp --dport 2022 -m state --state ESTABLISHED -j ACCEPT -A OUTPUT -o eth0 -p tcp --sport 2022 - m state --state ESTABLISHED -j ACCEPT
Налаштуйте iptables таким чином, щоб протягом 30 секунд дозволяти не більше трьох спроб підключення до порту 2022: Redhat iptables example (Update / etc / sysconfig / iptables): -I INPUT -p tcp --dport 2022 -i eth0 -m state - -state NEW -m recent --set -I INPUT -p tcp --dport 2022 -i eth0 -m state --state NEW -m recent --update --seconds 30 --hitcount 3 -j DR
Використовуйте аналізатор log-файлів (наприклад, logcheck, loggrep, splunk або logwatch) для більш ретельного аналізу і створення звітів. Налаштуйте також саме SSH-додаток на більш докладний журнал роботи подій: Installation of the logwatch package on Redhat Linux # yum install logwatch
Встановлюйте найбільш детальний рівень журналювання SSH: # vi / etc / ssh / sshd_config LogLevel DEBUG
Завжди оновлюйте пакети SSH і необхідні бібліотеки до останніх версій: # yum update openssh-server openssh openssh-clients -y
Приховуйте версію OpenSSH в вихідному коді, після чого компілюйте додаток заново. Після цього вносите такі зміни: # vi / etc / ssh / sshd_config VerifyReverseMapping yes # Turn on reverse name checking UsePrivilegeSeparation yes # Turn on privilege separation StrictModes yes # Prevent the use of insecure home directory # and key file permissions AllowTcpForwarding no # Turn off, if at all possible X11Forwarding no # Turn off, if at all possible PasswordAuthentication no # Specifies whether password authentication is # allowed. The default is yes. Users must have # another authentication method available.
Видаляйте виконувані файли rlogin і rsh з системи і заміняйте їх symlink -Посилання на SSH: # find / usr -name rsh / usr / bin / rsh # rm -f / usr / bin / rsh # ln -s / usr / bin / ssh / usr / bin / rsh

SSH підтримує безліч різноманітних методів і способів аутентифікації, які можна ввімкнути або вимкнути. Цим можна управляти в конфігураційному файлі / etc / ssh / sshd_config, вказуючи ключове слово, що відноситься до того чи іншого методу аутентифікації, з подальшою вказівкою параметра yes або no. У наступному прикладі показані найбільш поширені параметри:

# RSAAuthentication yes # PubkeyAuthentication yes # RhostsRSAAuthentication no # HostbasedAuthentication no # RhostsRSAAuthentication and HostbasedAuthentication PasswordAuthentication yes ChallengeResponseAuthentication no # KerberosAuthentication no GSSAPIAuthentication yes

Ключові слова AllowedAuthentications і RequiredAuthentications в файлі sshd_config визначають, які зміни і методи аутентифікації використовуються тільки з протоколом SSH версії 2. Синтаксис, що дозволяє аутентифікацію за допомогою паролів і відкритих ключів, виглядає наступним чином:

# Vi / etc / ssh / sshd_config AllowedAuthentications publickey, password RequiredAuthentications publickey, password

Відкриті та закриті ключі SSH

Допоміжними інструментами перевірки автентичності SSH є засоби управління ключами і пов'язані з ними агенти. Якщо налаштована аутентифікація з використанням відкритого ключа, то ваш ключ підтверджує вашу справжність віддаленого вузла SSH. Справжність на основі SSH визначається на основі двох компонентів: відкритого і закритого ключів. Закритий ключ SSH підтверджує справжність користувача при вихідному SSH-підключенні і повинен зберігатися в секреті. Коли користувач ініціює SSH- або SCP-підключення до віддаленого комп'ютера або сервера, він є SSH-клієнтом. За допомогою математичних алгоритмів ваш закритий ключ стає вашої персональної електронної картки доступу, а відкритий ключ - замком, до якого підходить ваша електронна карта. Ваш закритий ключ каже: "Це дійсно я, Фред Сміт"; відкритий ключ відповідає: "Так, ви дійсно Фред Сміт, ваша особистість встановлена, будь ласка, заходьте".

Відкритий ключ визначає, кому дозволено відкривати замок і отримувати право на вхід. Відкриті ключі не потрібно тримати в секреті, оскільки їх неможливо використовувати для компрометації системи або для несанкціонованого доступу. В операційних системах Linux і UNIX відкриті і закриті ключі зберігаються у вигляді текстових ASCII-файлів; в системах під управлінням Windows пари ключів можуть зберігатися як в текстових файлах, так і в реєстрі Windows.

Протокол SSH версії 2 дозволяє виконувати множинну ідентифікацію з використанням декількох закритих ключів. Давайте подивимося, як створити і налаштувати пару з відкритого і закритого SSH-ключів на звичайних комп'ютерах з Linux ( малюнок 5 ).

Малюнок 5. Діаграма взаємодій відкритих і закритих SSH-ключів згідно архітектурі SSH

Покрокова настройка закритого і відкритого ключів SSH

В лістингу 1 за допомогою утиліти ssh-keygen створюється пара SSH-ключів (відкритий і закритий) для користувача fsmythe; ці ключі мають тип dsa (значення атрибута type).

Лістинг 1. Генерація пари SSH-ключів

[[email protected] ~] $ / usr / bin / ssh-keygen -t dsa Generating public / private dsa key pair. Enter file in which to save the key (/home/fsmythe/.ssh/id_dsa): Enter passphrase (empty for no passphrase): ****** (Enter 'mypassword') Enter same passphrase again: **** ** (Enter 'mypassword') Your identification has been saved in /home/fsmythe/.ssh/id_dsa. Your public key has been saved in /home/fsmythe/.ssh/id_dsa.pub. The key fingerprint is: 33: af: 35: cd: 58: 9c: 11: 91: 0f: 4a: 0c: 3a: d8: 1f: 0E: e6 [email protected] [[email protected] ~] $

В лістингу 2 виконується копіювання відкритого ключа в файл authorized_keys, розташований в піддиректорії .ssh домашньої директорії потрібного користувача на цільовому комп'ютері.

Лістинг 2. Копіювання відкритого ключа з комп'ютера-джерела в файл authorized_keys на цільовому комп'ютері

[[email protected] ~] $ scp -p /home/fsmythe/.ssh/id_dsa.pub [email protected]: /home/fsmythe/.ssh/authorized_keys fsmythe @ thor01.com's password: id_dsa.pub 100% 624 0.6KB / s 00:00

В лістингу 3 виконується перша віддалене SSH-звернення (запуск команди ls -d / tmp) до сервера, внаслідок чого ключ кешируєтся на сервері у файлі .ssh / known_hosts. Користувач вводить парольний фразу, задану на етапі генерації SSH-ключів, а висновок команди, запущеної на віддаленому сервері, передається на екран локального комп'ютера.

Лістинг 3. Перевірка SSH-доступу за допомогою запуску команди на віддаленому комп'ютері

[[email protected] ~] $ ssh [email protected] ls -d / tmp The authenticity of host 'thor01.com (10.12.53.118)' can not be established. RSA key fingerprint is 84: 4f: e5: 99: 0b: 7d: 54: d0: 1b: 3e: 2b: 96: 02: 34: 41: 25. Are you sure you want to continue connecting (yes / no)? yes Warning: Permanently added 'thor01.com, 10.12.53.118' (RSA) to the list of known hosts. Enter passphrase for key '/root/.ssh/id_dsa': ****** (Enter 'mypassword') / tmp file1.txt file2.txt dir3_5432

Примітка. У всіх вищенаведених прикладах не було потрібно вводити пароль користувача fsmythe. Замість цього було потрібно вводити парольний фразу, задану на кроці 1. Якщо ви не хочете вводити парольний фразу при підключенні до віддаленого комп'ютера, то необхідно створити пусту фразу, натиснувши клавішу enter в момент появи відповідного запиту. Після цього при підключенні до віддаленого комп'ютера thor01.com від імені користувача fsmythe вам не доведеться нічого вводити.

Конфігурація и использование утіліті ssh-agent

Тім, хто категорично НЕ візнає использование беспарольному SSH-ключів, стані в нагоді утіліта ssh-agent. Говорячи в цілому, утиліта ssh-agent дозволяє тимчасово надати безпарольний SSH-доступ в рамках поточного сеансу користувача, навіть якщо пара SSH-ключів містить парольний фразу. Перед використанням утиліти ssh-agent введіть парольний фразу, як зазвичай:

[[email protected] ~] # ssh [email protected] Enter passphrase for key '/root/.ssh/id_dsa':****** (User must type password) Last login: Sat May 8 6:37 : 26 2010 from 10.12.53.118

Далі за допомогою ssh-agent згенеруйте на пристрій stdout команди інтерпретатора bash:

[[email protected] ~] # ssh-agent -s SSH_AUTH_SOCK = / tmp / ssh-vxZIxF1845 / agent.1845; export SSH_AUTH_SOCK; SSH_AGENT_PID = 1849; export SSH_AGENT_PID; echo Agent pid 1 849;

На третьому кроці задайте значення вищезазначених змінних середовища для поточного сеансу командної оболонки:

[Root @ example01 ~] # SSH_AUTH_SOCK = / tmp / ssh-vxZIxF1845 / agent.1845; export SSH_AUTH_SOCK SSH_AGENT_PID = 1849; export SSH_AGENT_PID; echo Agent pid 1849 Agent pid 1849

Переконайтеся, що утиліта ssh-agent запущена:

[Root@example01.com ~] # ps -fp $ SSH_AGENT_PID UID PID PPID C STIME TTY TIME CMD root 1849 1 0 6:14? 00:00:00 ssh-agent -s

Отримайте список поточних елементів, завантажених в межах ssh-agent:

[[email protected] ~] # ssh-add -l The agent has no identities.

На наступному кроці, додавайте потрібні SSH-елементи (виконавши їх попередню аутентифікацію з використанням парольної фрази SSH-ключів):

[[email protected] ~] # ssh-add Enter passphrase for /root/.ssh/id_dsa: Identity added: /root/.ssh/id_dsa (/root/.ssh/id_dsa) ****** (Entered 'mypassword')

Переконайтеся, що зазначені елементи були завантажені в запущену оболонку ssh-agent:

[[email protected] ~] # ssh-add -l 1024 33: af: 35: cd: 58: 9c: 11: 91: 0f: 4a: 0c: 3a: d8: 1f: 0E: e6 / root /. ssh / id_dsa (DSA)

Нарешті, можна перевірити роботу ssh-agent з використанням синтаксису SSH. Зверніть увагу на відсутність запиту на введення парольної фрази:

# Assuming target remote host has correct authorized key for private key from example01 [[email protected] ~] # ssh -A [email protected] Last login: Sat May 8 6:36:27 2010 from 10.12.53.118 [root @ example02 ~] # # Assuming target remote host has correct authorized key for private key from example03 [[email protected] ~] # ssh -A [email protected] Last login: Sat May 8 7:04:05 2010 from 10.12. 53.119 [root @ example03 ~] #

Коли ви вводите парольний фразу за допомогою команди ssh-add, ви насправді ви дешіфруете закритий ключ і ставите його через агента в пам'ять, після чого він може використовуватися в наступних SSH-підключених за допомогою цієї парольний фразу. Зверніть увагу на те, що за допомогою ssh-add можна виконувати попередню аутентифікацію декількох закритих ключів.

Інший інструмент, SSH-утиліта ssh-keyscan з лістингу 4 , Дозволяє збирати відкриті SSH-ключі хостів з віддалених комп'ютерів. Ця надзвичайно швидка і ефективна утиліта корисна при наповненні файлів / etc / ssh_known_hosts. В першу чергу вона призначена для використання в командних сценаріях, які допомагають автоматизувати процеси.

Лістинг 4. Приклад використання ssh-keyscan

[Root @ example01 ~] # / usr / bin / ssh-keyscan -t rsa, dsa example02.com # example02.comSSH-2.0-OpenSSH_4.3 example02.comssh-dss AAAAB3NzaC1kc3MAAACBALd5 / TGn7jCL1DWWzYMw96jw3QOZGBXJgP4m9LACViyM0QHs ewHGo841JdInfE825mVe0nB / UT15iylLOsI / jFCac + ljQRlO + h2q7WOwGveOUN7TxyKlejM + G1pg5DndGt05iYn + 2 dDfn5CmEsI + K0F2vk / + mpoSOk9HKq9VgwNzAAAAFQDPeLAth62TRUcN / nTYoqENBmW3SwAAAIEAryoKa + VaG5LQNj wBujAuA7hGl + DIWVb1aZ8xAHkcyL5XgrOWEKNnK9mDmEN66oMLfTMO3w8 / OvbJUmcXcU3jnL3zguz2E2OIv6t6vAa F6niL7A / VhxGGxy4CJZnceufStrzZ3UKXRzjwlm0Bwu / LruVF2m3XLvR5XVwUgyWvw + AAAACAaK12k3uC / OOokBgi eu / SuD5wCSBsf9rqG9ZFa32ujZwRZmA / AwPrZd6q3ASxmjtMp6zGQSzxPczUvLH9D9WIJo713bw8wCPo / 7pqiQNRs OZXqlQyaXyrDout6CI683b1 / rxsZKPrJpFNehrZwjWrwpYhK7VaTuzxvWtrDyDxWec = # example03.comSSH-2.0-OpenSSH_4.3 example03 .comssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq5So5VBeH4gPX1A1VEeQkGsb / miiWsWnNTW8ZWYj 2IvU7rKpk / dBIp64WecYYYgDqTK5u0Q + yTijF8wEEI9rRyoh9p5QraM8qy9NxcHzyGqU4vSzfVrblIQrDI8iv7iwz 7PxQAY76NmweaUyGEDfIErty4gCn / ksy85IgffATa9nt36a4iUhiDNifnE8dm1ZrKkvz3lIg0w + C u0T9MY77AqLWj Moo0WoQArIvYa0soS3VhzgD / Biwu / sh3eHJtFUxTVxnATdkWkHKUI1wxma3j7jF0saTRKEQSvG6492W + U1FhEjFGN r7KeZXH99uFpuUWFA7xO7uaG / MLWSjPJMxw == # example04.comSSH-2.0-OpenSSH_4.3 example04.comssh-dss AAAAB3NzaC1kc3MAAACBALd5 / TGn7jCL1DWWzYMw96jw3QOZGBXJgP4m9LACViyM0QHs ewHGo841JdInfE825mVe0nB / UT15iylLOsI / jFCac + ljQRlO + h2q7WOwGveOUN7TxyKlejM + G1pg5DndGt05iYn + 2 dDfn5CmEsI + K0F2vk / + mpoSOk9HKq9VgwNzAAAAFQDPeLAth62TRUcN / nTYoqENBmW3SwAAAIEAryoKa + VaG5LQNj wBujAuA7hGl + DIWVb1aZ8xAHkcyL5XgrOWEKNnK9mDmEN66oMLfTMO3w8 / OvbJUmcXcU3jnL3zguz2E2OIv6t6vAa F6niL7A / VhxGGxy4CJZnceufStrzZ3UKXRzjwlm0Bwu / LruVF2m3XLvR5XVwUgyWvw + AAAACAaK12k3uC / OOokBgi eu / SuD5wCSBsf9rqG9ZFa32ujZwRZmA / AwPrZd6q3ASxmjtMp6zGQSzxPczUvLH9D9WIJo713bw8wCPo / 7pqiQNRs OZXqlQyaXyrDout6CI683b1 / rxsZKPrJpFNehrZwjWrwpYhK7VaTuzxvWtrDyDxWec = # example05.comSSH-2.0-OpenSSH_4.3 example05.comssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq5So5VBeH4gPX1A1VEeQkGsb / miiWsWnNTW8ZWYj 2IvU7rKpk / dBIp64WecYYYgDqTK5u0Q + yTijF8wEEI9rRyoh9p5QraM8qy9NxcHzyGqU4vSzfVrblIQrDI8iv7iwz 7PxQAY76NmweaUyGEDfIErty4gCn / ksy85IgffATa9nt36a4iUhiDNifnE8dm1ZrKkvz3lIg0w + Cu0T9MY77AqLWj Moo0WoQArIvYa0soS3VhzgD / Biwu / sh3eHJtFUxTVxnATdkWkHKUI1wxma3j7jF0saTRKEQSvG6492W + U1FhEjFGN r7KeZXH99uFpuUWFA7xO7uaG / MLWSjPJMxw ==

Використання SSH в додатках і сценаріях UNIX

SSH-доступ з віддалених командних сценаріїв і віддалених інструментів адміністрування (обслуговування системи, віддалену копію і архівація) надзвичайно зручний, але це питання завжди є предметом гарячих дебатів з точки зору безпеки серверів. Багато командні сценарії, які можуть бути запущені користувачами, наприклад:

$ Ssh [email protected] /usr/local/bin/dangerous_script.pl

не можуть обробляти вводяться користувачами парольні фрази SSH і припиняють роботу, якщо заздалегідь не була налаштована беспарольному конфігурація SSH-ключів, конфігурація з використанням ssh-agent або механізм довіреної мережі - т. е. один з методів, що не вимагає введення SSH-паролів. Це відбувається тому, що SSH очікує введення парольної фрази з терміналу, пов'язаного з поточним сеансом командної оболонки. Цю проблему можна обійти, використовуючи сценарії, написаних за допомогою expect, або за допомогою Perl-сценаріїв (розгляньте можливості CPAN-модуля Net :: SSH :: Perl); до них можна також звертатися з вашого власного сценарію:

#! / Usr / local / bin / expect spawn sftp $ argv expect "password:" send "mysshpassowrd \ r"

Деякі системні адміністратори вважають надання звичайним користувачам беспарольного SSH-доступу до віддалених хостів достатньою причиною для лінчування. Однак існують альтернативні заходи безпеки, що виправдовують беспарольному механізми SSH-доступу до віддалених хостів, наприклад, коли користувач використовує на віддаленому комп'ютері обмежену командну оболонку korn (rksh - restricted korn shell) або shell (rssh - restricted shell) замість повнофункціональної Bash. Також за допомогою авторизованих ключів можна обмежити список команд, які дозволено запускати користувачам на віддаленому комп'ютері, в результаті чого користувачі не зможуть випадково запустити команду, здатну завдати шкоди системі. Приклад такого обмеження представлений в лістінгу 5 .

Лістинг 5. Приклад настройки обмежень з використанням файлу authorized_keys на віддаленому комп'ютері

[Fsmythe @ example02 .ssh] $ more authorized_keys command = "/ usr / local / bin / secureScript.sh", no-port-forwarding, no-X11-forwarding, no-agent-fo rwarding, no-pty ssh-dss AAAAB3NzaC1kc3MAAACBAOFsC6C7cJUGOZG4Ur9W0J6mxTTk5 + MYTu5XfRESPLVwQ A7HlUxhsXsxgmb1L1RgvR / g0JZnipDS + fGOrN2 / IerSpgyzegTVxYLPrOovvuyCn5TA0 + rmyrkV27so6yRDkdqTJc YzWNJOyDndnTrDc / LNmqLFKoGMQ33aur6RNv4VAAAAFQD4leC5Fc1VJqjvXCNsvazBhi84vQAAAIAWbshT80cTESg dX / srxX4KVNAzY1uhBz5V0UYR4FGP + aoe6laxRj + gQvFIvAKIrpikvBjgyW6cdT8 + k0t8HGIQp20MzSBdY9sH8xdj 05AG97Nb / L8xzkceB78qfXhV6txaM1CzssUtiOtaAygrywNPBDEN9MbEbwpVVVyd6iqZNgAAAIAmV0SUZoUr8dHdC tagRye4bGOQjoztpb4C0RbXQw + w7Jpzr6cZISdZsK4DTBjODvv2 + / OWPm7NEzzWyLzHPBNul8hAHOUCOpp + mYWbXX F78BTk2Ess0SZu8dwpOtasTNEp + xPcsOvQx2Kdr17gTp + 28SfpREuLudOr6R3KeTb + hw == fsmythe @ example01

У цьому прикладі користувачеві fsmythe дозволено виконувати на комп'ютері example01 єдину команду: /usr/local/bin/secureScript.sh.

Створення середовища довірених вузлів за допомогою SSH

Нарешті, слід згадати про середовище довірених вузлів, що є заміною використанню відкритих і закритих ключів SSH. У середовищах з використанням командних сценаріїв (або якщо стоїть завдання автоматизувати певні процедури), в яких необхідно використовувати ці типи звернень, середа довірених вузлів має певні переваги в порівнянні з використанням SSH-ключів (хоча при цьому залишаються ризики, пов'язані з порушенням безпеки). Середа довірених вузлів (або аутентифікація на основі довірених вузлів) здебільшого реалізується за допомогою заздалегідь сконфігурованих файлів, що містять списки користувачів і хостів, яким дозволений доступ. Існує два типи аутентифікації на основі довірених вузлів. У першому, більш старому і менш захищеному методі (наприклад, OpenSSH і SSH1) використовуються команди відкритого протоколу (rsh, rcp і rlogin), перевіряється два файли і встановлюється одне ключове слово в файлі sshd_config:

/etc/hosts.equiv ~ / .rhosts

Протокол SSH версії 2 не підтримує цей метод. Замість цього для кращого захисту мережі змініть файл / etc / ssh / sshd_config (можна вказувати як імена хостів, так і IP-адреси), а також налаштуйте файли shosts.equiv і / або .shosts наступним чином:

/etc/shosts.equiv ~ / .shosts

Щоб активувати середовища довірених вузлів, задайте в файлі the / etc / ssh / sshd_config наступні параметри для протоколу SSH версії 2:

PermitEmptyPasswords yes AllowSHosts remoteclient.com DenySHosts

Наприклад, якщо файл /etc/shosts.equiv налаштований на сервері example.com наступним чином:

+ Remoteclient.com fsmythe + secureserver.net sallyh +192.168.100.12 fsmythe -hackers.org james

то користувачеві fsmythe дозволено виконувати аутентифікацію на основі довірених вузлів, якщо він працює за віддаленими комп'ютерами remoteclient.com, 192.168.100.12 і secureserver.net, користувачеві sallyh дозволений доступ з комп'ютера secureserver.net, а користувачеві james заборонений доступ з віддаленого комп'ютера hackers.org .

Методи аутентифікації на основі довірених хостів і на основі SSH-ключів схожі і, в кінцевому рахунку, забезпечують один і той же результат. В таблиці 1 наводиться порівняння цих двох методів.

Таблиця 1. Порівняння можливостей аутентифікації на основі SSH-ключів і на основі довірених вузлів

Можливості SSH Довірені вузли Публічний і відкритий ключі Аутентификация по IP-адресою Так Так Аутентификация по імені хоста Так Так Більше можливостей відкритого ключа Ні Так Аутентификация на ім'я віддаленого користувача Так Ні Використання групових символів в іменах хостів і IP-адреси Ні Так Необхідність використання пральний фрази для отримання доступу Ні Ні Збої в разі зміни IP-адресу або назву в деяких випадках так Необхідність виконання налаштувань як на сервері, так і на клієнті Ні так Можливість ис користування для автоматизації завдань, а також в командних сценаріях Так Так

Якщо ви є одним з тих системних адміністраторів, у яких думка про надання беспарольного віддаленого SSH-доступу в середовищі довірених вузлів викликає посмішку, то зверніть увагу на такі недоліки використання ключів SSH в видалено виконуваних сценаріях:

При зміні імені або IP-адреси хоста пара SSH-ключів перестане працювати, оскільки інформація про відомих хостах знаходиться в кеші. В цьому випадку необхідно видалити з файлу .ssh / known_hosts стару запис про хості і заново помістити оновлену інформацію в кеш. При виникненні такої ситуації всі сценарії, які використовують SSH-ключі, перестануть працювати.
Аутентифікація з використанням SSH-ключів вимагає настройки як на стороні клієнта, так і на стороні сервера. Кожен раз при зміні відкритого ключа або генерації нової пари ключів необхідно передавати новий відкритий ключ на всі віддалені комп'ютери і оновлювати файл authorized_keys.
При зміні прав доступу до папки .ssh / (а також до файлів відкритого або закритого ключа) безпарольний SSH-доступ може перестати працювати. Для відключення суворої перевірки прав доступу до файлів і тек відредагуйте файл / etc / ssh / sshd_config, задавши для параметра StrictModes значення no.
Не існує централізованого способу відкликати ключ після того, як пара ключів була згенерована; також неможливо точно дізнатися, кому був переданий ключ.

Висновок

SSH - це потужний і захищений мережевий інструмент, який використовується по всьому світу для самих різних завдань. SSH є безпечною, захищеною заміною таким відкритих протоколах, як telnet, і командам групи r *, крім того, існує ряд безкоштовних клієнтських і серверних SSH-додатків, що робить протокол SSH неперевершеним помічником. SSH широко використовується в самих різних мережах для віддаленого моніторингу, обслуговування та аудиту систем, створення звітів і автоматизації завдань за допомогою сценаріїв, з чого можна зробити висновок, що він залишиться з нами надовго, продовжуючи розвиватися.

Ресурси для скачування

Схожі тими

Оригінал статті: Getting started with SSH security and configuration (EN).
Ознайомтеся з інформацією про протокол SSH, прочитавши статтю про SSH на сторінках Вікіпедії.
завантажте OpenSSH (EN) - безкоштовний пакет інструментів, який заслужив довіру технічних фахівців, що працюють в Інтернеті.
Дізнайтеся про архітектуру протоколу SSH з документа RFC 4251 .
Дізнайтеся про всі подробиці OpenSSH, прочитавши статтю Гиріш Венкатачалама (Girish Venkatachalam) The OpenSSH Protocol under the Hood (EN) (Linux Journal, квітень 2007 року)
Додаткову інформацію про те, як захистити ваші сервери за допомогою SSH, ви можете дізнатися зі статті Камерона Лейрда (Cameron Laird) Server clinic: Connect securely with ssh (EN) (developerWorks, липень 2003 року).
прочитайте статтю SSH and ssh-agent (EN), що містить інформацію та посилання на завантаження інструментарію компанії Symantec.
Для отримання додаткової інформації про ризики, пов'язані з використанням відкритих ключів, ознайомтеся з темою SSH public keys (EN) на Web-сайті serverfault.com.
У керівництві SSH tutorial for Linux (EN) Web-сайту suso.com описані початкові кроки по роботі з SSH в Linux-оточенні.
у статті Five SSH tricks (EN) описані п'ять прийомів роботи з SSH, про які повинен знати кожен.
у статті Top 20 OpenSSH Server Best Security Practices (EN) описані 20 кращих прийомів для захисту сервера.
розділ AIX і UNIX порталу developerWorks містить велику кількість матеріалів, присвячених адміністрування AIX, які допоможуть поліпшити ваші навички роботи з UNIX.

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів

Перші кроки по налаштуванню і використанню SSH

практичний посібник

Що таке SSH? Короткий опис

Протокол Secure Shell (SSH) був розроблений для максимального захисту мережевих взаємодій з віддаленими вузлами мережі. Цей протокол шифрує мережевий трафік за допомогою поліпшених можливостей аутентифікації, а також функцій, спрямованої на захист інших незахищених протоколів - таких як захищене копіювання (Secure Copy, SCP), захищений протокол передачі файлів (Secure File Transfer Protocol, SFTP), перенаправлення X-сеансів і перенаправлення портів. Підтримується кілька типів шифрування (починаючи від 512-бітного і закінчуючи 32768-бітовим) з використанням різних криптографічних алгоритмів - Blowfish, Triple DES, CAST-128, Advanced Encryption Scheme (AES) і ARCFOUR. Чим вище розрядність шифрування, тим більший обсяг трафіку генерується в мережі. з малюнка 1 видно, як будь який користувач мережі може з легкістю переглянути трафік telnet-підключення за допомогою аналізатора мережевих пакетів (наприклад, Wireshark).

Малюнок 1. Підключення з використанням протоколу telnet не зашифровані

Часто використовувані скорочення

API: Application programming interface - інтерфейс прикладного програмування
FTP: File Transfer Protocol - протокол передачі файлів
IETF: Internet Engineering Task Force - інженерна група з розвитку Інтернету
POSIX: Portable Operating System Interface for UNIX - інтерфейс яку переносять операційної системи для UNIX
RFC: Request for Comments - документ RFC, запит на коментар
VPN: Virtual private network - віртуальна приватна мережа

Якщо ви використовуєте незахищений "відкритий" протокол (наприклад, telnet), то будь-який користувач мережі може підглянути ваші паролі та іншу секретну інформацію. на малюнку 1 зображена схема підключення користувача fsmythe до віддаленого вузла з використанням telnet. Користувач вводить своє ім'я fsmythe і пароль r @ m $ 20! 0, які може бачити будь-який користувач, що знаходиться в тій же мережі, як і наш нічого не підозрюючи користувач telnet.

Малюнок 2. Підключення з використанням протоколу SSH зашифровані

на малюнку 2 зображена типова схема SSH-підключення, і ми бачимо, що ніякої користувач мережі не може переглядати зашифрований трафік. Пакети SSH (як правило, це Open Source-пакет OpenSSH) за замовчуванням встановлені у всіх поширених дистрибутивах Linux® і UNIX®, тому вам навряд чи доведеться завантажувати і компілювати їх з вихідного коду. Якщо ви не працюєте в Linux або UNIX, то існує безліч підтримуваних безкоштовних SSH-інструментів, наприклад, WinSCP , Putty , FileZilla , TTSSH і Cygwin (Програмне забезпечення POSIX, яке встановлюється в операційній системі Windows®). Ці інструменти працюють під управлінням операційної системи Windows і мають інтерфейс командної оболонки UNIX або Linux.

Незалежно від операційної системи SSH надає безліч переваг при повсякденній роботі з комп'ютером. Цей протокол не тільки надійний, безпечний і гнучкий, але і простий в установці, налаштуванні і використанні, не кажучи вже про його численних можливостях.

архітектура SSH

У документах IETF RFC 4251-4256 дається наступне визначення SSH: "Протокол SSH використовується для організації безпечного входу в віддалену систему і організації інших безпечних служб через мережі, які не забезпечують безпеки". Протокол включає три основних компоненти ( малюнок 3 ):

Протокол транспортного рівня: забезпечує аутентифікацію серверів, конфіденційність і цілісність. Цей протокол може також забезпечувати стиск інформації і працює в основному з використанням з'єднань TCP / IP, але може бути реалізований і на базі інших потоків даних з гарантованою доставкою.
Протокол аутентифікації користувачів: використовується на сервери для перевірки справжності клієнтів і працює на основі протоколу транспортного рівня.
Протокол з'єднань: забезпечує мультиплексування шифрованого тунелю в декілька логічних каналів і працює поверх протоколу аутентифікації користувачів.

Малюнок 3. Логічні рівні протоколу SSH

Транспортний рівень відповідає за обмін ключами і аутентифікацію серверів. На цьому рівні забезпечується підтримка шифрування, перевірки цілісності і стиснення даних (при необхідності), після чого на верхній рівень передається API-інтерфейс для відправки та отримання нешифрованих текстових пакетів. Рівень автентифікації користувачів забезпечує перевірку автентичності клієнтів за допомогою різних методів. Найбільш поширені методи аутентифікації включають в себе функцію захисту паролем і відкритих ключів, введення даних з клавіатури, інтерфейс GSSAPI, технологію SecureID, а також різні модулі аутентифікації (PAM).

На рівні з'єднань визначаються канали, глобальні запити, а також запити на надання каналів, через які надаються служби SSH. Одна SSH-з'єднання може одночасно включати в себе кілька каналів, в кожному з яких відбувається двунаправленная передача даних. Запити на надання каналів використовують таку інформацію, як код завершення процесу на стороні сервера. SSH-клієнт ініціює запит для пересилки в порт на стороні сервера.

Ця відкрита архітектура має велику гнучкість. Транспортний рівень сумісний з протоколом Transport Layer Security (TLS), і ви можете реалізовувати власні методи перевірки автентичності, розширюючи рівень аутентифікації користувачів. Рівень з'єднань дозволяє об'єднувати в одному SSH-підключенні кілька сеансів ( малюнок 4 ).

Малюнок 4. SSH в 7-рівневої моделі OSI

Приклади типового використання SSH в операційних системах UNIX та Linux

Як правило, SSH використовується для того, щоб користувачі могли підключатися до віддалених комп'ютерів і виконувати на них різні команди. Однак SSH також підтримує тунелювання і X11-з'єднання і навіть дозволяє передавати файли за допомогою SFTP і SCP. SSH можна використовувати в безлічі додатків для різних платформ, включаючи Linux, UNIX, Windows і Apple® OS X (для запуску деяких програм можуть знадобитися додаткові можливості, доступні або сумісні тільки з певними SSH-клієнтами або SSH-серверами).

Розглянемо кілька загальних прикладів синтаксису SSH:

Доступ до командної оболонки віддаленого комп'ютера (замість використання незахищених протоколів telnet і rlogin): # ssh [email protected] [[email protected]] ~
Виконання окремої команди на віддаленому комп'ютері (замість використання rsh) # ssh [email protected] reboot [email protected]'s password: ******
Копіювання файлів із локального сервера на віддалений комп'ютер за допомогою команди SCP: [email protected]'s password: ****** file1.txt 100% 0 0.0KB / s 00:00 file2.txt 100% 0 0.0KB / s 00:00
Захищена передача файлів за допомогою SFTP (замість використання FTP): sftp [email protected] Connecting to example.com ... [email protected]'s password: ******* sftp>
Ефективні та безпечні процедури резервного копіювання, синхронізації і віддзеркалення файлів на локальний або віддалений комп'ютер за допомогою rsync: # rsync -avul --rsh = ssh / opt / edbdata / [email protected]: / root / backup / [email protected]'s password: ****** building file list ... done ./ file1.txt file2.txt file3.txt file4.txt dir1 / file5.txt dir2 / file6.txt sent 982813 bytes received 2116 bytes 1374860.38 bytes / sec total size is 982138 speedup is 1.00
Перенаправлення або туннелирование порту (не плутайте з VPN): ssh -L 8000: mailserver: 110 example.com [email protected]'s password: ********
Перенаправлення X-сеансів з віддаленого комп'ютера (може здійснюватися через кілька проміжних вузлів): Edit / etc / ssh / sshd_config and change 2 keywords: AllowTcpForwarding yes X11Forwarding yes # service sshd restart $ export DISPLAY $ ssh -X [email protected]
Конфігурація з перенаправленням X11, яка використовується спільно з клієнтом X Windows, в якому налаштований SSH-тунелювання X11. Це дозволяє використовувати графічну підсистему UNIX або Linux через захищене SSH-з'єднання на локальному комп'ютері з Windows, підключеному через SSH до віддаленого вузла Linux або UNIX: ssh -ND 8000 [email protected] Browser Settings, goto 'Manual Proxy Configuration' set "SOCKS Host "to example.com, the 'Port to 8000', Enable SOCKS v5, and lastly set 'No Proxy for' field to 'localhost, 127.0.0.1'
Безпечне монтування директорії віддаленого сервера в якості файлової системи локального комп'ютера за допомогою sshfs: # yum install sshfs fuse-utils (Install sshfs and fuse-utils) $ sshfs example.com:/remote_dir / mnt / local_dir
Автоматизоване спостереження і керування віддаленими серверами за допомогою різних засобів: (Report number of apache processes running on the remote server example.com): $ ssh example.com ps -ef | grep httpd | wc -l [email protected]'s password: *****

Корисні поради по налаштуванню і використанню SSH

У деяких випадках, які були розглянуті вище, у багатьох досвідчених системних адміністраторів виникає занепокоєння щодо безпечної реалізації ряду функцій і методів використання SSH. Незважаючи на велику кількість матеріалів і статей, присвячених різним підходам до безпеки SSH і захисту віддалених комп'ютерів в цілому, ми наведемо тут кілька команд і конфігурацій, які можна використовувати для посилення захисту віддаленого доступу за допомогою SSH:

Забороніть віддалені підключення користувачам з привілеями root: # vi / etc / ssh / sshd_config PermitRootLogin no
Створюйте пари ключів (відкритий / закритий) з використанням стійких ідентифікаційних фраз і захищайте закритий ключ паролем (ніколи не генеруйте пари ключів або ідентифікаційні фрази без використання паролів): (Use a higher bit rate for the encryption for more security) ssh-keygen -t rsa -b 4096
Налаштуйте обробники TCP (TCP wrappers) таким чином, щоб дозволяти підключатися тільки певним віддалених комп'ютерів, а всім іншим - забороняти: # vi /etc/hosts.deny ALL: 192.168.200.09 # IP Address of badguy
Вимикайте функціональність SSH-сервера на робочих станціях і ноутбуках - для цього вимкніть службу SSH, а потім видаліть пакет SSH-сервера: # chkconfig sshd off # yum erase openssh-server
Керуйте дозволами SSH-підключення за допомогою облікових записів: # vi / etc / ssh / sshd_config AllowUsers fsmythe bnice swilson DenyUsers jhacker joebadguy jripper
Використовуйте тільки протокол SSH версії 2: # vi / etc / ssh / sshd_config Protocol 2
Закривайте неактивні підключення, вказавши час простою: # vi / etc / ssh / sshd_config ClientAliveInterval 600 # (Set to 600 seconds = 10 minutes) ClientAliveCountMax 0
Забороняйте аутентифікацію на основі хоста: # vi / etc / ssh / sshd_config HostbasedAuthentication no
Вимикайте призначені для користувача файли .rhosts: # vi / etc / ssh / sshd_config IgnoreRhosts yes
Налаштуйте брандмауер таким чином, щоб дозволяти вхідні SSH-підключення тільки з довірених мереж: Update / etc / sysconfig / iptables (Redhat specific file) to accept connection only from 192.168.100.0/24 and 209.64.100.5/27, enter: -A RH -FW-1-INPUT -s 192.168.100.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT -A RH-FW-1-INPUT -s 209.64.100.5/27 -m state - -state NEW -p tcp --dport 22 -j ACCEPT
Явно вказуйте мережеві інтерфейси, які повинні приймати вхідні SSH-підключення: # vi / etc / ssh / sshd_config ListenAddress 192.168.100.17 ListenAddress 209.64.100.15
Налаштуйте політики користувачів на використання стійких паролів, що забезпечують захист від атак за допомогою повного перебору, соціальної інженерії і підбору за словниками: # </ dev / urandom tr -dc A-Za-z0-9_ | head -c8 oP0FNAUt [
Обмежуйте доступ SFTP-користувачів їх домашніми директоріями за допомогою параметра Chroot SSHD: # vi / etc / ssh / sshd_config ChrootDirectory / data01 / home /% u X11Forwarding no AllowTcpForwarding no
Забороняйте використання порожніх паролів: # vi / etc / ssh / sshd_config PermitEmptyPasswords no
Обмежуйте кількість вхідних з'єднань на порт 2022 в певний інтервал часу: Redhat iptables example (Update / etc / sysconfig / iptables): -A INPUT -i eth0 -p tcp --dport 2022 -m state --state NEW -m limit - limit 3 / min --limit-burst 3 -j ACCEPT -A INPUT -i eth0 -p tcp --dport 2022 -m state --state ESTABLISHED -j ACCEPT -A OUTPUT -o eth0 -p tcp --sport 2022 - m state --state ESTABLISHED -j ACCEPT
Налаштуйте iptables таким чином, щоб протягом 30 секунд дозволяти не більше трьох спроб підключення до порту 2022: Redhat iptables example (Update / etc / sysconfig / iptables): -I INPUT -p tcp --dport 2022 -i eth0 -m state - -state NEW -m recent --set -I INPUT -p tcp --dport 2022 -i eth0 -m state --state NEW -m recent --update --seconds 30 --hitcount 3 -j DR
Використовуйте аналізатор log-файлів (наприклад, logcheck, loggrep, splunk або logwatch) для більш ретельного аналізу і створення звітів. Налаштуйте також саме SSH-додаток на більш докладний журналирование подій: Installation of the logwatch package on Redhat Linux # yum install logwatch
Встановлюйте найбільш детальний рівень журналювання SSH: # vi / etc / ssh / sshd_config LogLevel DEBUG
Завжди оновлюйте пакети SSH і необхідні бібліотеки до останніх версій: # yum update openssh-server openssh openssh-clients -y
Приховуйте версію OpenSSH в вихідному коді, після чого компілюйте додаток заново. Після цього вносите такі зміни: # vi / etc / ssh / sshd_config VerifyReverseMapping yes # Turn on reverse name checking UsePrivilegeSeparation yes # Turn on privilege separation StrictModes yes # Prevent the use of insecure home directory # and key file permissions AllowTcpForwarding no # Turn off, if at all possible X11Forwarding no # Turn off, if at all possible PasswordAuthentication no # Specifies whether password authentication is # allowed. The default is yes. Users must have # another authentication method available.
Видаляйте виконувані файли rlogin і rsh із системи і заміняйте їх symlink -Посилання на SSH: # find / usr -name rsh / usr / bin / rsh # rm -f / usr / bin / rsh # ln -s / usr / bin / ssh / usr / bin / rsh

SSH підтримує безліч різноманітних методів і способів аутентифікації, які можна ввімкнути або вимкнути. Цим можна управляти в конфігураційному файлі / etc / ssh / sshd_config, вказуючи ключове слово, що відноситься до того чи іншого методу аутентифікації, з подальшою вказівкою параметра yes або no. У наступному прикладі показані найбільш поширені параметри:

# RSAAuthentication yes # PubkeyAuthentication yes # RhostsRSAAuthentication no # HostbasedAuthentication no # RhostsRSAAuthentication and HostbasedAuthentication PasswordAuthentication yes ChallengeResponseAuthentication no # KerberosAuthentication no GSSAPIAuthentication yes

Ключові слова AllowedAuthentications і RequiredAuthentications в файлі sshd_config визначають, які зміни і методи аутентифікації використовуються тільки з протоколом SSH версії 2. Синтаксис, що дозволяє аутентифікацію за допомогою паролів і відкритих ключів, виглядає наступним чином:

# Vi / etc / ssh / sshd_config AllowedAuthentications publickey, password RequiredAuthentications publickey, password

Відкриті і закриті ключі SSH

Допоміжними інструментами перевірки автентичності SSH є засоби управління ключами і пов'язані з ними агенти. Якщо налаштована аутентифікація з використанням відкритого ключа, то ваш ключ підтверджує вашу справжність віддаленого вузла SSH. Справжність на основі SSH визначається на основі двох компонентів: відкритого і закритого ключів. Закритий ключ SSH підтверджує справжність користувача при вихідному SSH-підключенні і повинен зберігатися в секреті. Коли користувач ініціює SSH- або SCP-підключення до віддаленого комп'ютера або сервера, він є SSH-клієнтом. За допомогою математичних алгоритмів ваш закритий ключ стає вашої персональної електронної картки доступу, а відкритий ключ - замком, до якого підходить ваша електронна карта. Ваш закритий ключ каже: "Це дійсно я, Фред Сміт"; відкритий ключ відповідає: "Так, ви дійсно Фред Сміт, ваша особистість встановлена, будь ласка, заходьте".

Відкритий ключ визначає, кому дозволено відкривати замок і отримувати право на вхід. Відкриті ключі не потрібно розголошувати, оскільки їх неможливо використовувати для компрометації системи або для несанкціонованого доступу. В операційних системах Linux і UNIX відкриті і закриті ключі зберігаються у вигляді текстових ASCII-файлів; в системах під управлінням Windows пари ключів можуть зберігатися як в текстових файлах, так і в реєстрі Windows.

Протокол SSH версії 2 дозволяє виконувати множинну ідентифікацію з використанням декількох закритих ключів. Давайте подивимося, як створити і налаштувати пару з відкритого і закритого SSH-ключів на звичайних комп'ютерах з Linux ( малюнок 5 ).

Малюнок 5. Діаграма взаємодій відкритих і закритих SSH-ключів згідно архітектурі SSH

Покрокова настройка закритого і відкритого ключів SSH

В лістингу 1 за допомогою утиліти ssh-keygen створюється пара SSH-ключів (відкритий і закритий) для користувача fsmythe; ці ключі мають тип dsa (значення атрибута type).

Лістинг 1. Генерація пари SSH-ключів

[[email protected] ~] $ / usr / bin / ssh-keygen -t dsa Generating public / private dsa key pair. Enter file in which to save the key (/home/fsmythe/.ssh/id_dsa): Enter passphrase (empty for no passphrase): ****** (Enter 'mypassword') Enter same passphrase again: **** ** (Enter 'mypassword') Your identification has been saved in /home/fsmythe/.ssh/id_dsa. Your public key has been saved in /home/fsmythe/.ssh/id_dsa.pub. The key fingerprint is: 33: af: 35: cd: 58: 9c: 11: 91: 0f: 4a: 0c: 3a: d8: 1f: 0E: e6 [email protected] [[email protected] ~] $

В лістингу 2 виконується копіювання відкритого ключа в файл authorized_keys, розташований в піддиректорії .ssh домашньої директорії потрібного користувача на цільовому комп'ютері.

Лістинг 2. Копіювання відкритого ключа з комп'ютера-джерела в файл authorized_keys на цільовому комп'ютері

[[email protected] ~] $ scp -p /home/fsmythe/.ssh/id_dsa.pub [email protected]: /home/fsmythe/.ssh/authorized_keys fsmythe @ thor01.com's password: id_dsa.pub 100% 624 0.6KB / s 00:00

В лістингу 3 виконується перша віддалене SSH-звернення (запуск команди ls -d / tmp) до сервера, внаслідок чого ключ кешируєтся на сервері у файлі .ssh / known_hosts. Користувач вводить парольний фразу, задану на етапі генерації SSH-ключів, а висновок команди, запущеної на віддаленому сервері, передається на екран локального комп'ютера.

Лістинг 3. Перевірка SSH-доступу за допомогою запуску команди на віддаленому комп'ютері

[[email protected] ~] $ ssh [email protected] ls -d / tmp The authenticity of host 'thor01.com (10.12.53.118)' can not be established. RSA key fingerprint is 84: 4f: e5: 99: 0b: 7d: 54: d0: 1b: 3e: 2b: 96: 02: 34: 41: 25. Are you sure you want to continue connecting (yes / no)? yes Warning: Permanently added 'thor01.com, 10.12.53.118' (RSA) to the list of known hosts. Enter passphrase for key '/root/.ssh/id_dsa': ****** (Enter 'mypassword') / tmp file1.txt file2.txt dir3_5432

Примітка. У всіх вищенаведених прикладах не було потрібно вводити пароль користувача fsmythe. Замість цього було потрібно вводити парольний фразу, задану на кроці 1. Якщо ви не хочете вводити парольний фразу при підключенні до віддаленого комп'ютера, то необхідно створити пусту фразу, натиснувши клавішу enter в момент появи відповідного запиту. Після цього при підключенні до віддаленого комп'ютера thor01.com від імені користувача fsmythe вам не доведеться нічого вводити.

Перші кроки по налаштуванню і використанню SSH

практичний посібник

Що таке SSH? Короткий опис

Протокол Secure Shell (SSH) був розроблений для максимального захисту мережевих взаємодій з віддаленими вузлами мережі. Цей протокол шифрує мережевий трафік за допомогою поліпшених можливостей аутентифікації, а також функцій, спрямованої на захист інших незахищених протоколів - таких як захищене копіювання (Secure Copy, SCP), захищений протокол передачі файлів (Secure File Transfer Protocol, SFTP), перенаправлення X-сеансів і перенаправлення портів. Підтримується кілька типів шифрування (починаючи від 512-бітного і закінчуючи 32768-бітовим) з використанням різних криптографічних алгоритмів - Blowfish, Triple DES, CAST-128, Advanced Encryption Scheme (AES) і ARCFOUR. Чим вище розрядність шифрування, тим більший обсяг трафіку генерується в мережі. з малюнка 1 видно, як будь-який користувач мережі може з легкістю переглянути трафік telnet-підключення за допомогою аналізатора мережевих пакетів (наприклад, Wireshark).

Малюнок 1. Підключення з використанням протоколу telnet не зашифровані

Часто використовувані скорочення

API: Application programming interface - інтерфейс прикладного програмування
FTP: File Transfer Protocol - протокол передачі файлів
IETF: Internet Engineering Task Force - інженерна група з розвитку Інтернету
POSIX: Portable Operating System Interface for UNIX - інтерфейс яку переносять операційної системи для UNIX
RFC: Request for Comments - документ RFC, запит на коментар
VPN: Virtual private network - віртуальна приватна мережа

Якщо ви використовуєте незахищений "відкритий" протокол (наприклад, telnet), то будь-який користувач мережі може підглянути ваші паролі та іншу секретну інформацію. на малюнку 1 зображена схема підключення користувача fsmythe до віддаленого вузла з використанням telnet. Користувач вводить своє ім'я fsmythe і пароль r @ m $ 20! 0, які може бачити будь-який користувач, що знаходиться в тій же мережі, що і наш нічого не підозрюючи користувач telnet.

Малюнок 2. Підключення з використанням протоколу SSH зашифровані

на малюнку 2 зображена типова схема SSH-підключення, і ми бачимо, що ніякої користувач мережі не може переглядати зашифрований трафік. Пакети SSH (як правило, це Open Source-пакет OpenSSH) за замовчуванням встановлені у всіх поширених дистрибутивах Linux® і UNIX®, тому вам навряд чи доведеться завантажувати і компілювати їх з вихідного коду. Якщо ви не працюєте в Linux або UNIX, то існує безліч підтримуваних безкоштовних SSH-інструментів, наприклад, WinSCP , Putty , FileZilla , TTSSH і Cygwin (Програмне забезпечення POSIX, яке встановлюється в операційній системі Windows®). Ці інструменти працюють під управлінням операційної системи Windows і мають інтерфейс командної оболонки UNIX або Linux.

Незалежно від операційної системи SSH надає безліч переваг при повсякденній роботі з комп'ютером. Цей протокол не тільки надійний, безпечний і гнучкий, але і простий в установці, налаштуванні і використанні, не кажучи вже про його численних можливостях.

архітектура SSH

У документах IETF RFC 4251-4256 дається таке визначення SSH: "Протокол SSH використовується для організації безпечного входу в віддалену систему і організації інших безпечних служб через мережі, які не забезпечують безпеки". Протокол включає три основних компоненти ( малюнок 3 ):

Протокол транспортного рівня: забезпечує аутентифікацію серверів, конфіденційність і цілісність. Цей протокол може також забезпечувати стиск інформації і працює в основному з використанням з'єднань TCP / IP, але може бути реалізований і на базі інших потоків даних з гарантованою доставкою.
Протокол аутентифікації користувачів: використовується на серверах для перевірки справжності клієнтів і працює на основі протоколу транспортного рівня.
Протокол з'єднань: забезпечує мультиплексування шифрованого тунелю в кілька логічних каналів і працює поверх протоколу аутентифікації користувачів.

Малюнок 3. Логічні рівні протоколу SSH

Транспортний рівень відповідає за обмін ключами і аутентифікацію серверів. На цьому рівні забезпечується підтримка шифрування, перевірки цілісності і стиснення даних (при необхідності), після чого на верхній рівень передається API-інтерфейс для відправки та отримання нешифрованих текстових пакетів. Рівень аутентифікації користувачів забезпечує перевірку автентичності клієнтів за допомогою різних методів. Найбільш поширені методи аутентифікації включають в себе використання паролів і відкритих ключів, введення даних з клавіатури, інтерфейс GSSAPI, технологію SecureID, а також різні модулі аутентифікації (PAM).

На рівні з'єднань визначаються канали, глобальні запити, а також запити на надання каналів, через які надаються служби SSH. Одне SSH-з'єднання може одночасно включати в себе кілька каналів, в кожному з яких відбувається двунаправленная передача даних. Запити на надання каналів використовують таку інформацію, як код завершення процесу на стороні сервера. SSH-клієнт ініціює запит для пересилки в порт на стороні сервера.

Ця відкрита архітектура має велику гнучкість. Транспортний рівень сумісний з протоколом Transport Layer Security (TLS), і ви можете реалізовувати власні методи перевірки автентичності, розширюючи рівень аутентифікації користувачів. Рівень з'єднань дозволяє об'єднувати в одному SSH-підключенні кілька сеансів ( малюнок 4 ).

Малюнок 4. SSH в 7-рівневої моделі OSI

Приклади типового використання SSH в операційних системах UNIX та Linux

Як правило, SSH використовується для того, щоб користувачі могли підключатися до віддалених комп'ютерів і виконувати на них різні команди. Однак SSH також підтримує тунелювання і X11-з'єднання і навіть дозволяє передавати файли за допомогою SFTP і SCP. SSH можна використовувати в безлічі додатків для різних платформ, включаючи Linux, UNIX, Windows і Apple® OS X (для запуску деяких програм можуть знадобитися додаткові можливості, доступні або сумісні тільки з певними SSH-клієнтами або SSH-серверами).

Розглянемо кілька загальних прикладів синтаксису SSH:

Доступ до командної оболонки віддаленого комп'ютера (замість використання незахищених протоколів telnet і rlogin): # ssh [email protected] [[email protected]] ~
Виконання окремої команди на віддаленому комп'ютері (замість використання rsh) # ssh [email protected] reboot [email protected]'s password: ******
Копіювання файлів з локального сервера на віддалений комп'ютер за допомогою команди SCP: [email protected]'s password: ****** file1.txt 100% 0 0.0KB / s 00:00 file2.txt 100% 0 0.0KB / s 00:00
Захищена передача файлів за допомогою SFTP (замість використання FTP): sftp [email protected] Connecting to example.com ... [email protected]'s password: ******* sftp>
Ефективні та безпечні процедури резервного копіювання, синхронізації і віддзеркалення файлів на локальний або віддалений комп'ютер за допомогою rsync: # rsync -avul --rsh = ssh / opt / edbdata / [email protected]: / root / backup / [email protected]'s password: ****** building file list ... done ./ file1.txt file2.txt file3.txt file4.txt dir1 / file5.txt dir2 / file6.txt sent 982813 bytes received 2116 bytes 1374860.38 bytes / sec total size is 982138 speedup is 1.00
Перенаправлення або туннелирование порту (не плутайте з VPN): ssh -L 8000: mailserver: 110 example.com [email protected]'s password: ********
Перенаправлення X-сеансів з віддаленого комп'ютера (може здійснюватися через кілька проміжних вузлів): Edit / etc / ssh / sshd_config and change 2 keywords: AllowTcpForwarding yes X11Forwarding yes # service sshd restart $ export DISPLAY $ ssh -X [email protected]
Конфігурація з перенаправленням X11, яка використовується спільно з клієнтом X Windows, в якому налаштований SSH-тунелювання X11. Це дозволяє використовувати графічну підсистему UNIX або Linux через захищене SSH-з'єднання на локальному комп'ютері з Windows, підключеному через SSH до віддаленого вузла Linux або UNIX: ssh -ND 8000 [email protected] Browser Settings, goto 'Manual Proxy Configuration' set "SOCKS Host "to example.com, the 'Port to 8000', Enable SOCKS v5, and lastly set 'No Proxy for' field to 'localhost, 127.0.0.1'
Безпечне монтування директорії віддаленого сервера в якості файлової системи локального комп'ютера за допомогою sshfs: # yum install sshfs fuse-utils (Install sshfs and fuse-utils) $ sshfs example.com:/remote_dir / mnt / local_dir
Автоматизоване спостереження і керування віддаленими серверами за допомогою різних засобів: (Report number of apache processes running on the remote server example.com): $ ssh example.com ps -ef | grep httpd | wc -l [email protected]'s password: *****

Корисні поради по налаштуванню і використанню SSH

У деяких випадках, які були розглянуті вище, у багатьох досвідчених системних адміністраторів виникає занепокоєння щодо безпечної реалізації ряду функцій і методів використання SSH. Незважаючи на велику кількість матеріалів і статей, присвячених різним підходам до безпеки SSH і захисту віддалених комп'ютерів в цілому, ми наведемо тут кілька команд і конфігурацій, які можна використовувати для посилення захисту віддаленого доступу за допомогою SSH:

Забороніть віддалені підключення користувачам з привілеями root: # vi / etc / ssh / sshd_config PermitRootLogin no
Створюйте пари ключів (відкритий / закритий) з використанням стійких ідентифікаційних фраз і захищайте закритий ключ паролем (ніколи не генеруйте пари ключів або ідентифікаційні фрази без використання паролів): (Use a higher bit rate for the encryption for more security) ssh-keygen -t rsa -b 4096
Налаштуйте обробники TCP (TCP wrappers) таким чином, щоб дозволяти підключатися тільки певним віддалених комп'ютерів, а всім іншим - забороняти: # vi /etc/hosts.deny ALL: 192.168.200.09 # IP Address of badguy
Вимикайте функціональність SSH-сервера на робочих станціях і ноутбуках - для цього вимкніть службу SSH, а потім видаліть пакет SSH-сервера: # chkconfig sshd off # yum erase openssh-server
Керуйте дозволами на SSH-підключення за допомогою облікових записів: # vi / etc / ssh / sshd_config AllowUsers fsmythe bnice swilson DenyUsers jhacker joebadguy jripper
Використовуйте тільки протокол SSH версії 2: # vi / etc / ssh / sshd_config Protocol 2
Закривайте неактивні підключення, вказавши час простою: # vi / etc / ssh / sshd_config ClientAliveInterval 600 # (Set to 600 seconds = 10 minutes) ClientAliveCountMax 0
Забороняйте аутентифікацію на основі хоста: # vi / etc / ssh / sshd_config HostbasedAuthentication no
Вимикайте призначені для користувача файли .rhosts: # vi / etc / ssh / sshd_config IgnoreRhosts yes
Налаштуйте брандмауер таким чином, щоб дозволяти вхідні SSH-підключення тільки з довірених мереж: Update / etc / sysconfig / iptables (Redhat specific file) to accept connection only from 192.168.100.0/24 and 209.64.100.5/27, enter: -A RH -FW-1-INPUT -s 192.168.100.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT -A RH-FW-1-INPUT -s 209.64.100.5/27 -m state - -state NEW -p tcp --dport 22 -j ACCEPT
Явно вказуйте мережеві інтерфейси, які повинні приймати вхідні SSH-підключення: # vi / etc / ssh / sshd_config ListenAddress 192.168.100.17 ListenAddress 209.64.100.15
Налаштуйте політики користувачів на використання стійких паролів, що забезпечують захист від атак за допомогою повного перебору, соціальної інженерії і підбору за словниками: # </ dev / urandom tr -dc A-Za-z0-9_ | head -c8 oP0FNAUt [
Обмежуйте доступ SFTP-користувачів їх домашніми директоріями за допомогою параметра Chroot SSHD: # vi / etc / ssh / sshd_config ChrootDirectory / data01 / home /% u X11Forwarding no AllowTcpForwarding no
Забороняйте використання порожніх паролів: # vi / etc / ssh / sshd_config PermitEmptyPasswords no
Обмежуйте кількість вхідних з'єднань на порт 2022 в певний інтервал часу: Redhat iptables example (Update / etc / sysconfig / iptables): -A INPUT -i eth0 -p tcp --dport 2022 -m state --state NEW -m limit - limit 3 / min --limit-burst 3 -j ACCEPT -A INPUT -i eth0 -p tcp --dport 2022 -m state --state ESTABLISHED -j ACCEPT -A OUTPUT -o eth0 -p tcp --sport 2022 - m state --state ESTABLISHED -j ACCEPT
Налаштуйте iptables таким чином, щоб протягом 30 секунд дозволяти не більше трьох спроб підключення до порту 2022: Redhat iptables example (Update / etc / sysconfig / iptables): -I INPUT -p tcp --dport 2022 -i eth0 -m state - -state NEW -m recent --set -I INPUT -p tcp --dport 2022 -i eth0 -m state --state NEW -m recent --update --seconds 30 --hitcount 3 -j DR
Використовуйте аналізатор log-файлів (наприклад, logcheck, loggrep, splunk або logwatch) для більш ретельного аналізу і створення звітів. Налаштуйте також саме SSH-додаток на більш докладний журнал роботи подій: Installation of the logwatch package on Redhat Linux # yum install logwatch
Встановлюйте найбільш детальний рівень журналювання SSH: # vi / etc / ssh / sshd_config LogLevel DEBUG
Завжди оновлюйте пакети SSH і необхідні бібліотеки до останніх версій: # yum update openssh-server openssh openssh-clients -y
Приховуйте версію OpenSSH в вихідному коді, після чого компілюйте додаток заново. Після цього вносите такі зміни: # vi / etc / ssh / sshd_config VerifyReverseMapping yes # Turn on reverse name checking UsePrivilegeSeparation yes # Turn on privilege separation StrictModes yes # Prevent the use of insecure home directory # and key file permissions AllowTcpForwarding no # Turn off, if at all possible X11Forwarding no # Turn off, if at all possible PasswordAuthentication no # Specifies whether password authentication is # allowed. The default is yes. Users must have # another authentication method available.
Видаляйте виконувані файли rlogin і rsh з системи і заміняйте їх symlink -Посилання на SSH: # find / usr -name rsh / usr / bin / rsh # rm -f / usr / bin / rsh # ln -s / usr / bin / ssh / usr / bin / rsh

SSH підтримує безліч різноманітних методів і способів аутентифікації, які можна ввімкнути або вимкнути. Цим можна управляти в конфігураційному файлі / etc / ssh / sshd_config, вказуючи ключове слово, що відноситься до того чи іншого методу аутентифікації, з подальшою вказівкою параметра yes або no. У наступному прикладі показані найбільш поширені параметри:

# RSAAuthentication yes # PubkeyAuthentication yes # RhostsRSAAuthentication no # HostbasedAuthentication no # RhostsRSAAuthentication and HostbasedAuthentication PasswordAuthentication yes ChallengeResponseAuthentication no # KerberosAuthentication no GSSAPIAuthentication yes

Ключові слова AllowedAuthentications і RequiredAuthentications в файлі sshd_config визначають, які зміни і методи аутентифікації використовуються тільки з протоколом SSH версії 2. Синтаксис, що дозволяє аутентифікацію за допомогою паролів і відкритих ключів, виглядає наступним чином:

# Vi / etc / ssh / sshd_config AllowedAuthentications publickey, password RequiredAuthentications publickey, password

Відкриті та закриті ключі SSH

Допоміжними інструментами перевірки автентичності SSH є засоби управління ключами і пов'язані з ними агенти. Якщо налаштована аутентифікація з використанням відкритого ключа, то ваш ключ підтверджує вашу справжність віддаленого вузла SSH. Справжність на основі SSH визначається на основі двох компонентів: відкритого і закритого ключів. Закритий ключ SSH підтверджує справжність користувача при вихідному SSH-підключенні і повинен зберігатися в секреті. Коли користувач ініціює SSH- або SCP-підключення до віддаленого комп'ютера або сервера, він є SSH-клієнтом. За допомогою математичних алгоритмів ваш закритий ключ стає вашої персональної електронної картки доступу, а відкритий ключ - замком, до якого підходить ваша електронна карта. Ваш закритий ключ каже: "Це дійсно я, Фред Сміт"; відкритий ключ відповідає: "Так, ви дійсно Фред Сміт, ваша особистість встановлена, будь ласка, заходьте".

Відкритий ключ визначає, кому дозволено відкривати замок і отримувати право на вхід. Відкриті ключі не потрібно тримати в секреті, оскільки їх неможливо використовувати для компрометації системи або для несанкціонованого доступу. В операційних системах Linux і UNIX відкриті і закриті ключі зберігаються у вигляді текстових ASCII-файлів; в системах під управлінням Windows пари ключів можуть зберігатися як в текстових файлах, так і в реєстрі Windows.

Протокол SSH версії 2 дозволяє виконувати множинну ідентифікацію з використанням декількох закритих ключів. Давайте подивимося, як створити і налаштувати пару з відкритого і закритого SSH-ключів на звичайних комп'ютерах з Linux ( малюнок 5 ).

Малюнок 5. Діаграма взаємодій відкритих і закритих SSH-ключів згідно архітектурі SSH

Покрокова настройка закритого і відкритого ключів SSH

В лістингу 1 за допомогою утиліти ssh-keygen створюється пара SSH-ключів (відкритий і закритий) для користувача fsmythe; ці ключі мають тип dsa (значення атрибута type).

Лістинг 1. Генерація пари SSH-ключів

[[email protected] ~] $ / usr / bin / ssh-keygen -t dsa Generating public / private dsa key pair. Enter file in which to save the key (/home/fsmythe/.ssh/id_dsa): Enter passphrase (empty for no passphrase): ****** (Enter 'mypassword') Enter same passphrase again: **** ** (Enter 'mypassword') Your identification has been saved in /home/fsmythe/.ssh/id_dsa. Your public key has been saved in /home/fsmythe/.ssh/id_dsa.pub. The key fingerprint is: 33: af: 35: cd: 58: 9c: 11: 91: 0f: 4a: 0c: 3a: d8: 1f: 0E: e6 [email protected] [[email protected] ~] $

В лістингу 2 виконується копіювання відкритого ключа в файл authorized_keys, розташований в піддиректорії .ssh домашньої директорії потрібного користувача на цільовому комп'ютері.

Лістинг 2. Копіювання відкритого ключа з комп'ютера-джерела в файл authorized_keys на цільовому комп'ютері

[[email protected] ~] $ scp -p /home/fsmythe/.ssh/id_dsa.pub [email protected]: /home/fsmythe/.ssh/authorized_keys fsmythe @ thor01.com's password: id_dsa.pub 100% 624 0.6KB / s 00:00

В лістингу 3 виконується перша віддалене SSH-звернення (запуск команди ls -d / tmp) до сервера, внаслідок чого ключ кешируєтся на сервері у файлі .ssh / known_hosts. Користувач вводить парольний фразу, задану на етапі генерації SSH-ключів, а висновок команди, запущеної на віддаленому сервері, передається на екран локального комп'ютера.

Лістинг 3. Перевірка SSH-доступу за допомогою запуску команди на віддаленому комп'ютері

[[email protected] ~] $ ssh [email protected] ls -d / tmp The authenticity of host 'thor01.com (10.12.53.118)' can not be established. RSA key fingerprint is 84: 4f: e5: 99: 0b: 7d: 54: d0: 1b: 3e: 2b: 96: 02: 34: 41: 25. Are you sure you want to continue connecting (yes / no)? yes Warning: Permanently added 'thor01.com, 10.12.53.118' (RSA) to the list of known hosts. Enter passphrase for key '/root/.ssh/id_dsa': ****** (Enter 'mypassword') / tmp file1.txt file2.txt dir3_5432

Примітка. У всіх вищенаведених прикладах не було потрібно вводити пароль користувача fsmythe. Замість цього було потрібно вводити парольний фразу, задану на кроці 1. Якщо ви не хочете вводити парольний фразу при підключенні до віддаленого комп'ютера, то необхідно створити пусту фразу, натиснувши клавішу enter в момент появи відповідного запиту. Після цього при підключенні до віддаленого комп'ютера thor01.com від імені користувача fsmythe вам не доведеться нічого вводити.

Конфігурація и использование утіліті ssh-agent

Тім, хто категорично НЕ візнає использование беспарольному SSH-ключів, стані в нагоді утіліта ssh-agent. Говорячі в цілому, утіліта ssh-agent дозволяє тимчасово надаті безпарольного SSH-доступ в рамках поточного сеансу користувача, даже если пара SSH-ключів містіть парольний фразу. Перед використанням утиліти ssh-agent введіть парольний фразу, як зазвичай:

[[email protected] ~] # ssh [email protected] Enter passphrase for key '/root/.ssh/id_dsa':****** (User must type password) Last login: Sat May 8 6:37 : 26 2010 from 10.12.53.118

Далі за допомогою ssh-agent згенеруйте на пристрій stdout команди інтерпретатора bash:

[[email protected] ~] # ssh-agent -s SSH_AUTH_SOCK = / tmp / ssh-vxZIxF1845 / agent.1845; export SSH_AUTH_SOCK; SSH_AGENT_PID = тисяча вісімсот сорок дев'ять; export SSH_AGENT_PID; echo Agent pid 1849;