За допомогою захищеного протоколу SSH адміністратори підключаються до своїх серверів для безпечної роботи. Розглянемо особливості цього протоколу докладніше:
Що таке SSH-протокол
SSH-протокол (від англ. Secure Shell) - криптографічний мережевий протокол, призначений для віддаленого доступу до операційної системи та здійснення безпечного віддаленого управління в рамках незахищеної мережі (наприклад, через інтернет).
SSH забезпечує захищений канал зв'язку між клієнтом та сервером, через який можна передавати дані (поштові, відео, файли), працювати в командному рядку, віддалено запускати програми, у тому числі графічні. SSH-сервер має бути встановлений на віддаленій операційній системі. SSH-клієнт повинен бути запущений на машині, з якою буде здійснюватись віддалене підключення.
Основні функції, доступні при використанні SSH-протоколу:
- Передача будь-яких даних через захищене з'єднання SSH, включаючи стиснення даних для подальшого шифрування.
- X11 Forwarding - механізм, що дозволяє запускати програми UNIX/Linux-сервера як графічної оболонки, як у Windows (використовувати X Window System).
- Переадресація портів – передача шифрованого трафіку між портами різних машин.
Безпека SSH-з'єднання забезпечується:
- шифрування даних одним з існуючих алгоритмів
- автентифікацією сервера та клієнта одним із кількох доступних методів
- наявністю додаткових функцій протоколу, спрямованих на попередження різних атак хакерів
Аутентифікація сервера дає захист від:
- злому шляхом підміни IP-адрес (IP-spoofing), коли один віддалений хост посилає пакети від імені іншого віддаленого хоста
- підміни DNS-записів (DNS-spoofing), коли підмінюється запис на DNS-сервері, в результаті чого з'єднання встановлюється з хостом, який вказаний у підміненому записі замість необхідного
- перехоплення відкритих паролів та інших даних, що передаються у відкритому вигляді через встановлене з'єднання
На сьогоднішній день існують дві версії протоколу SSH (SSH-1 та SSH-2), причому друга версія вдосконалена та розширена порівняно з першою. Наприклад, друга версія стійка до атак виду MITM ("людина посередині", атака посередника). Також існують дві редакції цього протоколу: відкрита версія (безкоштовна) та комерційна (платна). Безкоштовна версія - OpenSSH - вбудована у всі UNIX-подібні операційні системи у вигляді стандартних утиліт SSH-клієнта та SSH-сервера.
Комерційна реалізація SSH-протоколу – SSH Communications Security – розроблена однойменною організацією. Має невеликі відмінності від безкоштовної версії, такі як доступність комерційної технічної підтримки, наявність інструментів веб-управління та ін. Основний набір команд та можливостей практично однаковий у обох продуктів.
Для ОС Windows випущені різні SSH-клієнти та оболонки, найпоширеніші з них – це безкоштовні PuTTY та WinSCP. Для інших операційних систем також є свої SSH-клієнти.
Що таке SFTP-протокол
SFTP-протокол (від англ. SSH File Transfer Protocol) – мережевий протокол прикладного рівня, призначений передачі файлів та інших дій із нею через наявне надійне з'єднання. Протокол був розроблений як розширення SSH-2, призначене для операцій із файлами захищеним каналом, проте може працювати і з іншими протоколами, що забезпечують безпечне з'єднання сервера з клієнтом. Іншими словами, для надійної роботи через SFTP-протокол необхідно мати встановлене захищене з'єднання (наприклад, SSH), яке проводить аутентифікацію клієнта та сервера та встановлює факт їхньої надійності, оскільки сам SFTP-протокол не проводить аутентифікацію та не забезпечує безпеку.
SFTP має ряд переваг перед своїми попередниками - FTP і SCP - таких, як переривання передачі файлу, видалення, відновлення передачі, зв'язок переданих файлів з основними атрибутами, наприклад, міткою дати/часу, а також більш висока платформонезалежність.
SFTP-протокол реалізується через SFTP-сервер та SFTP-клієнт, які є підсистемами OpenSSH.
Для чого використовуються SSH та SFTP протоколи
Найчастіше протоколи SSH та SFTP використовуються для віддаленої роботи з операційною системою або перенесення великої кількості файлів.
Наприклад, клієнт бере в оренду сервер або якусь частину серверного простору. Виникає необхідність переносити туди вже наявні дані клієнта, наприклад сайт чи поштові файли. Провайдер повинен забезпечити надійність та швидкість обміну даними з його сервером, особливо якщо йдеться про великі обсяги інформації та її високу конфіденційність. У цьому випадку на віддаленій машині (в даному випадку – віртуальному сервері) встановлюється SSH-сервер (з вбудованим SFTP-протоколом), а на клієнтському комп'ютері – SSH-клієнт. Створюється SSH-тунель, і обмін даними між клієнтом та віддаленим сервером здійснюється через надійне з'єднання з усіма перевагами протоколу, описаними вище.
Також SSH може використовуватися для віддаленої роботи із захищеного з'єднання з різними сервісами провайдера, такими як програмне забезпечення, операційні системи тощо.
Як працює SSH
По протоколу SSH працює набір програм, службовців до виконання різних дій на віддаленої операційній системі. Наприклад, програма sshd забезпечує серверну функціональність SSH, вона має бути запущена на SSH-сервері. Програма ssh запускається на SSH-клієнті та дозволяє встановлювати з'єднання з віддаленим хостом, реєструватися на ньому, працювати з віддаленою машиною через SSH-з'єднання.
Для запуску тих чи інших програм SSH-протоколу є спеціальні команди з набором різних опцій. Ці команди можуть відрізнятися залежно від клієнтської операційної системи та оболонки SSH-клієнта. Команди запускаються або з командного рядка, якщо йдеться про UNIX-подібні системи, або за допомогою графічного інтерфейсу у відповідних SSH-оболонках.
Як підключитися через SSH
Якщо на комп'ютері встановлена ОС Windows, а на віддаленій машині UNIX-подібна система (наприклад, Linux), то для встановлення SSH-з'єднання можна використовувати PuTTY . Ця безкоштовна програма під Windows складається з одного файлу, що запускається, і не вимагає інсталяції.
Щоб встановити з'єднання за допомогою PuTTY, необхідно виконати такі дії.
Запустити PuTTY (putty.exe).
За замовчуванням ніяких додаткових налаштувань проводити не потрібно, можна переконатися, що вказано 22 порт і тип з'єднання Connection type - SSH. У полі Host Name (or IP address) потрібно ввести ім'я віддаленого комп'ютера або його IP-адресу та натиснути кнопку Open .
Може з'явитися попередження системи безпеки PuTTY, проте якщо є впевненість у тому, що хост є достовірним, то потрібно натиснути Так і продовжити з'єднання.
У командному рядку потрібно ввести ім'я користувача, під яким буде виконуватися вхід на віддалений комп'ютер.
У наступному рядку потрібно ввести пароль для користувача. При введенні пароля жодних символів у командному рядку не відображається, тому необхідно просто набрати пароль і натиснути клавішу введення (Enter). Якщо введено неправильні ім'я користувача та пароль, то виведеться помилка «Access denied», у разі успішного підключення надається командний рядок віддаленого комп'ютера.
SSH (Secure Shell) — це мережевий протокол, призначений для віддаленого керування сервером та передачі даних зашифрованим TCP з'єднанням. Більшість хостингів, навіть віртуальних, сьогодні надає доступ як по FTP, так і SSH. На мій погляд, це здорово, SSH набагато зручніше та безпечніше у використанні.
Налаштування SSH
Налаштування відбуватимуться під виділений сервер, VDS, VPS на Debian, Ubuntu. Конфігураційний файл розміщується тут: /etc/ssh/sshd_config.
Якщо у вас звичайний хостинг, все і так має бути налаштовано як слід, переходьте до розділу .
За замовчуванням, демон SSHD (саме в нього ми вносимо зміни) не потребує будь-яких налаштувань і працює нормально. Ми внесемо лише кілька невеликих змін, щоб обмежити доступ небажаних осіб до сервера.
В результаті внесення неправильних змін до конфігураційного файлу ви можете втратити доступ до сервера по ssh, тому переконайтеся, що у вас є альтернативні варіанти для доступу до нього, наприклад, за допомогою панелі керування ISPManager.
Як обмежити доступ по SSH
Всі зміни вносяться до /etc/ssh/sshd_config
Щоб зміни набули чинності, необхідно
Змінити порт
Port 9724Тепер при авторизації вам потрібно замість стандартного порту 22 вказувати 9724 .
Спосіб дуже простий і дієвий проти більшості простих роботів хакерів, які стукають у стандартні порти. Тут головне не створити конфлікт з іншими службами і підібрати явно не використовується число.
Заборонити зв'язок по старому протоколу
Тут ми визначаємо, що зв'язок можливий лише за протоколом v2
Якщо ви авторизовані не під root, перед усіма консольними командами потрібно додавати sudo - розшифровується як Substitute User and DO- Заміни користувача і роби (під ним). Наприклад, дозволяє виконувати команди від імені суперкористувача root.
Зменшити кількість спроб авторизації
MaxAuthTries 2Кількість спроб введення пароля. 6. При невдалому переборі сеанс зв'язку обривається.
Зменшити час очікування на авторизацію
LoginGraceTime 30sЗа промовчанням 120 секунд може тривати сеанс авторизації. Після цього часу він обривається. 2 хвилини на авторизацію - це перебір, весь цей час сервер тримає зв'язок відкритим, що дуже нераціонально. Півхвилини за очі вистачить.
Закрити доступ до IP
Якщо доступ потрібен тільки вам, найпростішим і надійнішим буде закрити доступ звідусіль, крім вашого IP або, якщо він динамічний, то діапазону IP.
- Відкриваємо /etc/hosts.allow та додаємо туди SSHD: 192.168.1.1
де 192.168.1.1 - ваш IP. Якщо у вас динамічний IP, визначте IP з маскою підмережі та запишіть Вашу підсіть замість IP, наприклад:
SSHD: 192.168.0.0/16
- Відкриваємо /etc/hosts.deny та додаємо туди: SSHD: ALL
Ще один спосіб обмеження доступу по IP
Можна скористатися такою директивою:
AllowUsers = *@1.2.3.4
Тут ми дозволяємо доступ лише для IP 1.2.3.4
Авторизація SSH за ключами
Набагато безпечніше, зручніше та правильніше буде налаштувати ssh авторизацію без пароля. Для цього використовуватиметься авторизація за ключом.
Отже, ось інструкція:
Підключення настроєно. Якщо щось зробили не так, при авторизації з'явиться помилка Server refused our key , тобто Сервер не прийняв наш ключ. У цьому випадку пройдіться по всіх пунктах послідовно та пошукайте помилку
Дякую MadKox
Приклад конфігураційного файлу# Умовні позначення: #
# Під "за умовчанням" мається на увазі поведінка sshd при #
# Невказаною явно директивою. Варто зауважити, що в Ubuntu #
# файл sshd_config вже містить ряд налаштувань, які #
# є налаштуваннями за замовчуванням саме для Ubuntu. #
# Такі параметри вказані у цьому файлі. #
# #
################ Налаштування адрес/портів і т.д. ###########
############################################################
# #
## Port ############################################### #####
# #
# Використовуваний порт. Можна вказувати кілька, наприклад: #
# Port 22 #
# Port 23 #
# Port 24 #
Рекомендується використовувати нестандартний порт, т.к. #
стандартний часто сканується ботами на предмет #
# потенційних "дірок". Може бути опущений, якщо задано #
# через адресу. Див. також параметр ListenAddress. #
# #
Port 8022
# #
## ListenAddress ###########################################
# #
# Мережева адреса, на якій "слухає" сервер. Адреса можна #
# записувати так: #
# ListenAddress host | IPv4_addr | IPv6_addr #
# ListenAddress host | IPv4_addr: port #
# ListenAddress :port #
# Якщо порт не заданий, sshd буде слухати на цій адресі та #
# на порту, вказаному в опції Port. Якщо ви будете #
# використовувати ListenAddress не вказуючи порт, то опція #
# Port повинна передувати опції ListenAddress. Якщо не #
# вказувати, то за умовчанням слухає всіх локальних #
адресах. Можна вказати кілька адрес. #
# #
## AddressFamily ###########################################
# #
# Вказує, яке сімейство IP адрес має бути #
# використано sshd. Можливі варіанти: #
# "any" будь-які #
# "inet" (тільки IPv4) #
# "inet6" (тільки IPv6) #
# За замовчуванням any. #
AddressFamily inet
# #
## UseDNS ############################################### ###
# #
# Вказує, чи повинен sshd перевіряти ім'я хоста та #
# використовуючи це ім'я звіряти IP адресу передану клієнтом з #
отриманим від DNS. #
# #
############################################################
############# Налаштування доступу користувачів ##############
############################################################
# #
# Пустить/не пустити користувача визначається директивами #
# DenyUsers, AllowUsers, DenyGroups та AllowGroups. #
# при цьому перевірка проходить зверху вниз по ланцюжку: #
# ## DenyUsers ## #
# || #
# ## AllowUsers ## #
# || #
# ## DenyGroups ## #
# || #
# ## AllowGroups ## #
# Приймаються лише імена користувачів та груп, числові #
# Ідентифікатори (UserID) не розпізнаються. Коректна #
# запис кількох користувачів/груп по черзі, через #
# Пробіл. Якщо записано як користувач@хост то #
Користувач і хост перевіряються окремо, це дозволяє #
# розмежувати доступ певних користувачів з #
певних хостів. Варто пам'ятати, що директиви #
# DenyUsers і AllowUsers приймають як параметр #
# ім'я користувача, а DenyGroups та AllowGroups ім'я #
групи. PATTERNS в man ssh_config для додаткової #
# інформації про форми запису імен користувачів та груп. #
# #
## DenyUsers ###############################################
# #
# Список КОРИСТУВАЧІВ, яким НЕ МОЖНА користуватися sshd. #
# За замовчуванням не вказано = ніхто не заборонено. Тобто. якщо #
# тут вказаний користувач, йому буде відмовлено в доступі #
# до сервера ssh. #
# #
## AllowUsers ##############################################
# #
# Список КОРИСТУВАЧІВ, яким МОЖНА користуватися sshd, #
# вказано хоча б одного користувача, ssh доступ до сервера #
доступний тільки для нього. #
# #
## DenyGroups ##############################################
# #
# Список ГРУП, яким НЕ МОЖНА користуватися sshd. #
# За замовчуванням не вказано = жодна група не заборонена. #
# Тобто. якщо вказано хоча б одну групу, то користувачам, #
# входить до цієї групи буде відмовлено у доступі до ssh #
серверу. #
# #
## AllowGroups #############################################
# #
# Список ГРУП, яким МОЖНА користуватися sshd. #
# За замовчуванням не вказано = дозволено всім. Тобто. якщо #
# Вказана хоча б одна група, то тільки тим користувачам, #
# які входять до неї буде дозволено доступ до ssh серверу.
# #
############################################################
######### Опції визначення стану з'єднання ###########
############################################################
# #
## TCPKeepAlive ############################################
# #
# Вказує, що потрібно системі посилати TCP повідомлення клієнту #
# з метою підтримки з'єднання. Якщо надсилати ці пакети, #
можна визначити розрив з'єднання. Однак це також #
# означає, що з'єднання може бути розірвано у випадку #
# короткочасного перебою в роботі маршрутизації та #
# Деякі це сильно дратує. З іншого боку, якщо #
# таких повідомлень не надсилати сеанси на сервері можуть #
# Триватиме нескінченно, породжуючи користувачів "привидів", #
# та пожираючи ресурси сервера. Значення за промовчанням “yes”,#
# тобто. надсилати такі повідомлення. Для відключення надсилання #
# таких повідомлень потрібно вказати значення “no”. Раніше ця #
# Опція називалася KeepAlive. Варто зауважити, що #
# Існують більш захищені способи перевірки стану #
# з'єднання (див. нижче). #
# #
TCPKeepAlive yes
# #
## ClientAliveCountMax #####################################
# #
# Задає кількість повідомлень до клієнтів, які sshd #
# посилає поспіль, не отримуючи будь-якої відповіді від #
# Клієнта. Якщо граничне значення буде досягнуто, а #
клієнт так і не відповів sshd відключить клієнта, перервавши #
# ssh сесію. Варто зазначити, що використання таких #
# повідомлень докорінно відрізняється від директиви TCPKeepAlive. #
# Повідомлення до/від клієнтів надсилаються зашифрованим #
каналу і тому не схильні до спуфінгу. Повідомлення ж #
# TCPKeepAlive спуфінгу схильні. Механізм client alive #
особливо цінний у тих випадках, коли серверу і клієнту потрібно #
знати коли з'єднання стало неактивним. За замовчуванням #
# значення дорівнює 3. У випадку, якщо ClientAliveInterval #
# заданий рівним
5 і ClientAliveCountMax залишено за #
# замовчуванням, клієнти, що не відповідають, будуть відключені приблизно #
# Через 45 секунд. Ця директива працює тільки для #
протоколу ssh2. #
# #
## ClientAliveInterval #####################################
# #
# Задає часовий інтервал у секундах. Якщо протягом #
# цього інтервалу не було обміну даними з клієнтом, sshd #
# посилає повідомлення зашифрованим каналом, #
# запитує відповідь від клієнта. За умовчанням 0, тобто. #
# не надсилати таких повідомлень. Ця директива працює #
# лише протоколу ssh2. #
# #
############################################################
################ Загальні опції автентифікації #################
############################################################
# #
## AuthorizedKeysFile #######################################
# #
# Вказує файл, у якому містяться публічні ключі, #
# використовуються для автентифікації користувачів. Директива #
може містити маркери виду %М, які підставляються в #
процес встановлення з'єднання. #
# Визначено такі маркери: #
# Таким чином, файл із ключами може бути заданий як #
абсолютним шляхом (тобто один спільний файл з ключами), так і #
динамічно залежно від користувача (тобто по #
файлу на кожного користувача). #
# За замовчуванням “.ssh/authorized_keys”. #
# Приклад файлу ключа в домашній папці користувача: #
# AuthorizedKeysFile %h/.ssh/authorized_key #
# Приклад загального файла: #
# AuthorizedKeysFile /etc/ssh/authorized_keys #
# Див. опис файлу authorized_keys для більшої #
# інформації. #
# #
## ChallengeResponseAuthentication #########################
# #
# Вказує, чи дозволити аутентифікацію виду питання-відповідь #
# (challenge-response authentication). Підтримуються всі #
# види аутентифікації з login.conf Типово “yes”, #
# тобто. дозволити. #
# У Ubuntu вимкнена з міркувань безпеки. #
# #
ChallengeResponseAuthentication no
# #
## HostbasedUsesNameFromPacketOnly ##########################
# #
# Вказує, як сервер має отримувати ім'я хоста клієнта #
# При схемі аутентифікації, заснованої на перевірці хоста. #
# Якщо задати "yes" під час перевірки відповідності у файлах #
# ~/.shosts, ~/.rhosts або /etc/hosts.equiv sshd буде #
використовувати ім'я хоста, надане клієнтом. #
# (виконуючи реверсивне DNS розпізнавання) Якщо задати "no"#
# sshd буде передавати ім'я з самого TCP з'єднання. #
# За замовчуванням "no". #
# #
## IgnoreRhosts ############################################
# #
# Забороняє використання файлів.rhosts та.shosts #
# у процесі аутентифікації, що ґрунтується на перевірці хоста. #
# Файли /etc/hosts.equiv та /etc/ssh/shosts.equiv досі #
# використовуються. #
# За замовчуванням “yes”. #
# #
IgnoreRhosts yes
# #
## IgnoreUserKnownHosts #####################################
# #
# Вказує чи повинен sshd ігнорувати користувацькі #
# "відомі хости" файл ~/.ssh/known_hosts в процесі #
аутентифікації, заснованої на перевірці хоста #
# (RhostsRSAAuthentication або HostbasedAuthentication). #
# За замовчуванням “no”. #
# #
## PermitBlacklistedKeys ####################################
# #
# Вказує, чи варто sshd приймати ключі, занесені до #
# чорний список як скомпрометовані (known-compromised #
# keys (див. ssh-vulnkey)). Якщо встановлено значення “yes” #
# спроби аутентифікації з такими ключами будуть занесені до #
# журнал і прийнято, якщо значення “no” спроби #
аутентифікації будуть відкинуті. #
# За замовчуванням “no”. #
# #
## PermitEmptyPasswords #####################################
# #
# У разі дозволеної аутентифікації за допомогою пароля #
# Вказує, чи можливий вхід із порожнім паролем. #
# За замовчуванням “no”. #
# #
PermitEmptyPasswords no
# #
## PermitRootLogin #########################################
# #
# Вказує, чи можливий ssh-вхід під суперкористувачем #
# (Root). Може приймати значення: #
# “yes” суперкористувач може зайти. Застосовується #
поточна глобальна схема аутентифікації. #
# #
# "without-password" суперкористувач може зайти. #
# Парольна автентифікація для нього буде вимкнена. #
# #
# "forced-commands-only" суперкористувач зможе зайти, #
користуючись аутентифікацією на основі публічного ключа і #
тільки якщо передасть необхідну до виконання кімнату. #
# Це зручно для здійснення резервного копіювання, #
навіть у тому випадку, коли нормальний (тобто не через ssh) #
# Вхід суперкористувача заборонено. Всі інші методи #
аутентифікації для суперкористувача будуть заблоковані.
# #
# “no” суперкористувач не може використовувати ssh для #
входу в систему. #
# #
# За замовчуванням “yes”. #
# #
PermitRootLogin no
# #
## Protocol ############################################### #
# #
# Вказує протокол, який повинен використовувати sshd. #
# Можливі значення '1' та '2' ssh1 і ssh2 #
# відповідно. Можливий одночасний запис, при #
# якої значення слід розділяти комами. #
# За замовчуванням “2,1”. #
# Варто зазначити, що порядок проходження протоколів в #
запису не ставить пріоритет, т.к. клієнт вибирає який #
# із кількох запропонованих сервером протоколів йому #
# використовувати. Запис "2,1" абсолютно ідентичний #
# Записи "1,2". #
# #
Protocol 2
# #
## UsePAM ############################################### ###
# #
# Включає інтерфейс PAM (Pluggable Authentication Module #
# interface).Якщо встановлено значення "yes" для всіх типів #
аутентифікації крім обробки модуля сесії та акаунта #
# PAM використовуватиметься аутентифікація на основі #
# запиту-відповіді (ChallengeResponseAuthentication та #
# PasswordAuthentication) Т.к. автентифікація #
# запитів-відповідей у PAM зазвичай виконує ту ж роль, #
# що і парольна автентифікація, вам слід вимкнути #
# або PasswordAuthentication, або #
# ChallengeResponseAuthentication. Варто відмітити що #
# якщо директива UsePAM включена ви не зможете запустити #
# sshd від імені користувача, відмінного від root. #
# Значення за замовчуванням “no”. #
# #
UsePAM yes
# #
## PasswordAuthentication ###################################
# #
# Вказує, чи дозволено аутентифікацію з використанням #
пароля. #
# За замовчуванням “yes”. #
# #
PasswordAuthentication yes
#
## HostKey ################################################ ##
# #
# Вказує файл, що містить закритий хост-ключ, #
# використовуваний SSH. За промовчанням /etc/ssh/ssh_host_key #
# для протоколу ssh
і /etc/ssh/ssh_host_rsa_key та #
# /etc/ssh/ssh_host_dsa_key для протоколу ssh2. Стоїть #
# відзначити, що sshd не користуватиметься файлом, #
# який доступний комусь, крім користувача. Можна, можливо #
# використовувати кілька файлів із ключами, ключі “rsa1” #
# для протоколу ssh1 та “dsa”/“rsa” для протоколу ssh2. #
# #
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# #
############################################################
########## Опції протоколу SSH версії 1 (ssh1) #############
############################################################
# Настійно НЕ РЕКОМЕНДУЄТЬСЯ використовувати протокол ssh1.
# Протокол ssh2 набагато безпечніший, ніж ssh1 #
############################################################
# #
## KeyRegenerationInterval ##################################
# #
# Для протоколу ssh1 раз на певний час #
# автоматично генерується новий тимчасовий ключ сервера #
# (якщо він був використаний). Це зроблено для #
# запобігання розшифровці перехоплених сеансів, з метою #
пізніше зайти з параметрами цих сеансів на машину і #
# Вкрасти ключі. Такий ключ ніде не зберігається (зберігається в #
оперативної пам'яті). Ця директива вказує період #
# "життя" ключа в секундах, після якого він буде #
# згенерований заново. Якщо значення поставити рівним 0 #
ключ не буде генеруватися заново. #
# За замовчуванням значення 3600 (секунд). #
# #
KeyRegenerationInterval 3600
# #
## RhostsRSAAuthentication ##################################
# #
# Вказує, чи потрібна аутентифікація на основі файлів #
# rhosts або /etc/hosts.equiv спільно з успішною #
аутентифікацією хоста через RSA. #
# За замовчуванням “no”. #
# #
RhostsRSAAauthentication no
# #
## RSAAuthentication ########################################
# #
# Вказує, чи "чиста" RSA-автентифікація дозволена. #
# Актуально лише для протоколу ssh1. #
# За замовчуванням “yes”. #
# #
RSAAuthentication no
# #
## ServerKeyBits ############################################
# #
# Визначає число біт у тимчасовому ключі сервера для #
протоколу ssh1. Мінімальне значення 512.
# За замовчуванням 1024. #
ServerKeyBits 1024
# #
############################################################
########### Опції протоколу SSH версії 2 (ssh2) ############
############################################################
# #
## Ciphers ############################################### ##
# #
# Вказує алгоритми шифрування, дозволені для #
протоколу ssh2. Декілька алгоритмів повинні бути #
# розділені комами. Підтримувані алгоритми: #
# "3des-cbc", "aes128-cbc", "aes192-cbc", "aes256-cbc", #
# "aes128-ctr", "aes192-ctr", "aes256-ctr", "arcfour128", #
# "arcfour256", "arcfour", "blowfish-cbc", "cast128-cbc". #
# aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128, #
# arcfour256, arcfour, aes192-cbc, aes256-cbc, aes128-ctr, #
# aes192-ctr, aes256-ctr #
# #
## HostbasedAuthentication ##################################
# #
# Вказує, чи дозволено аутентифікацію, засновану на #
перевірці хоста. Перевіряється rhosts або /etc/hosts.equiv, #
# і у разі успіху, спільного з успішною перевіркою #
# публічного ключа, доступ дозволяється. Ця директива #
# однакова з директивою RhostsRSAAuthentication та #
# підходить лише протоколу ssh2. #
# За замовчуванням "no". #
# #
HostbasedAuthentication не
# #
## MACs ############################################### #####
# #
# Вказує допустимий алгоритм MAC (message #
# authentication code). Алгоритм MAC використовується #
протоколом ssh2 для захисту цілісності даних. Декілька #
алгоритмів повинні бути розділені комами. #
# За замовчуванням використовуються: #
# hmac-md5, hmac-sha1, [email protected], hmac-ripemd160, #
# hmac-sha1-96, hmac-md5-96 #
# #
## PubkeyAuthentication ####################################
# #
# Вказує, чи дозволено аутентифікацію на основі #
# громадського ключа. Актуально лише для протоколу ssh2. #
# За замовчуванням “yes”. #
# #
PubkeyAuthentication yes
############################################################
#################### Опції GSSAPI ##########################
############################################################
# #
############ Застосовується тільки для протоколу ssh2 ###########
# #
## GSSAPIAuthentication #####################################
# #
# Вказує, чи дозволено автентифікацію користувача на #
# основу GSSAPI. За умовчанням " no " , тобто. заборонено. #
# #
## GSSAPIKeyExchange ########################################
# #
# Вказує, чи дозволено обмін ключами на основі #
# GSSAPI. Обмін ключів за допомогою GSSAPI не покладається на #
# ssh ключі під час верифікації ідентичності хоста. #
# За умовчанням "no" тобто. обмін заборонено. #
# #
## GSSAPICleanupCredentials #################################
# #
# Вказує, чи потрібно автоматично знищувати #
# кеш автентифікаційних повноважень при #
# завершення сеансу. #
# За умовчанням "yes", тобто. потрібно знищувати. #
# #
## GSSAPIStrictAcceptorCheck ###############################
# #
# Вказує, наскільки строгою має бути перевірка #
ідентичності клієнта при аутентифікації через GSSAPI. #
# Значення "yes" змушує клієнта аутентифікуватися в #
приймаючої хост-службі на поточному хості. Значення "no" #
# дозволяє клієнту аутентифікуватися за допомогою будь-якого #
ключа служб. #
# Значення за промовчанням "yes". #
# Варто зауважити, що завдання значення "no" може #
# Спрацювати тільки з рідкісними бібліотеками Kerberos GSSAPI. #
# #
############################################################
################### Опції Kerberos #########################
############################################################
# #
## KerberosAuthentication ###################################
# #
# Вказує, чи вимагає пароль, наданий #
користувачем для аутентифікації
# (PasswordAuthentication) валідації в Kerberos KDC. #
# Для використання цієї опції серверу потрібно #
# Впевнитися в істинності KDC. (Те server needs a #
# Kerberos servtab which allows the verification of the #
# KDC's identity) #
# За замовчуванням “no”. #
# #
## KerberosGetAFSToken ######################################
# #
# Якщо активний AFS і користувач отримав Kerberos 5 TGT, #
# чи намагатися отримати AFS токен до того, як користувач #
# отримає доступ до своєї домашньої папки. #
# За замовчуванням “no”. #
# #
## KerberosOrLocalPasswd ####################################
# #
# Вказує, як робити у випадку, якщо аутентифікація #
# через Kerberos завершилася невдачею. Якщо #
# значення = "yes" пароль буде перевірено за допомогою #
# будь-якого додаткового локального механізму авторизації, #
# наприклад /etc/passwd. #
# За замовчуванням “yes”. #
# #
## KerberosTicketCleanup ####################################
# #
# Вказує, чи потрібно автоматично знищувати файл із #
# кешем тикету користувача після завершення сеансу. #
# За замовчуванням “yes”. #
# #
############################################################
################# Опції перенаправлення #####################
############################################################
# #
## AllowAgentForwarding ####################################
# #
# Вказує, дозволити або заборонити перенаправлення #
# ssh-agent"а. За замовчуванням "yes", тобто дозволити. #
# Варто зауважити, що відключення перенаправлення не #
# збільшить безпеки поки що користувачам також не буде #
# Заборонено shell доступ, т.к. вони завжди зможуть встановити #
свої власні аналоги агента. #
# #
AllowAgentForwarding не
# #
## AllowTcpForwarding ######################################
# #
# Вказує, дозволити або заборонити перенаправлення TCP. #
# За умовчанням “yes”, тобто. дозволити. Варто зауважити, #
# що як і у випадку з AllowAgentForwarding відключення #
# перенаправлення не збільшить безпеки, поки у #
користувачів буде консольний доступ, т.к. вони зможуть #
встановити свої аналоги. #
# #
# #
AllowTcpForwarding не
# #
## GatewayPorts #############################################
# #
# Вказує, чи дозволяти віддаленим хостам доступ до #
перенаправленим портам. За промовчанням sshd слухає #
# З'єднання до перенаправлених портів тільки на локальному #
інтерфейсі (loopback). Це не дає іншим віддаленим #
хостам приєднуватися до перенаправлених портів. Можна, можливо #
# використовувати GatewayPorts, щоб дозволити sshd це #
# робити. Директива може приймати 3 значення: #
# "No" тільки loopback. #
# "yes" - будь-які адреси. #
# "clientspecified" адреси, вказані клієнтом. #
# #
GatewayPorts no
# #
## PermitOpen ##############################################
# #
# Вказує, куди дозволено перенаправлення TCP портів. #
# Вказівка перенаправлення має приймати одну з #
наступних форм: #
# PermitOpen host:port #
# PermitOpen IPv4_addr:port #
# PermitOpen :port #
# Декілька записів можна задати, розділяючи їх пробілами. #
# Аргумент "any" можна використовувати для зняття всіх #
# заборон на перенаправлення портів. За замовчуванням #
# Перенаправлення дозволено. #
# #
## PermitTunnel #############################################
# #
# Вказує, чи дозволено перенаправлення tun-пристроїв. #
# Може приймати значення: #
# "yes" #
# "point-to-point" (3-й мережевий рівень) #
# "ethernet" (2-й мережевий рівень) #
# "no" #
# Значення "yes" дозволяє одночасно і "point-to-point" #
# та "ethernet". За промовчанням "no". #
# #
############################################################
################## Опції журналування #####################
############################################################
# #
## SyslogFacility ##########################################
# #
# Задає код об'єкта журналу для запису повідомлень у #
системний журнал від sshd. Можливі значення: #
# DAEMON #
#USER#
# AUTH #
# LOCAL0 #
# LOCAL1 #
# LOCAL2 #
# LOCAL3 #
# LOCAL4 #
# LOCAL5 #
# LOCAL6 #
# LOCAL7 #
# За замовчуванням використовується AUTH. #
# #
SyslogFacility AUTH
# #
## LogLevel ############################################### #
# #
# Задає рівень детальності журналу sshd. #
# Можливі варіанти: #
# SILENT #
# QUIET #
# FATAL #
#ERROR#
# INFO #
# VERBOSE #
# DEBUG #
# DEBUG1 #
# DEBUG2 #
# DEBUG3 #
# За замовчуванням INFO. #
# DEBUG та DEBUG
еквівалентні один одному. #
# DEBUG2 і DEBUG3 задають найвищі рівні налагоджувального #
# Виводу. Запис логів із рівнем DEBUG загрожує #
приватності користувачів і не рекомендована. #
# #
LogLevel INFO
# #
############################################################
################### Перенаправлення X
####################
############################################################
# #
## X11Forwarding ###########################################
# #
# Вказує, чи дозволено перенаправлення графічної #
# Підсистеми X11. Може набувати значення “yes” або “no”. #
# За замовчуванням “no”. #
# Увага включення простого перенаправлення Х11 #
великий ризик як сервера, так клієнтів, т.к. в #
# у разі такого перенаправлення проксі-дисплей sshd #
приймає з'єднання з будь-яких адрес. Використовуйте #
директиву X11UseLocalhost для обмеження доступу до #
серверу перенаправлення "іксів". Варто відмітити що #
# відключення перенаправлення не дасть гарантії, що #
Користувачі не зможуть перенаправляти Х11, т.к. маючи #
# консольний доступ вони завжди встановити свій #
# Перенаправник. Перенаправлення Х11 буде #
# автоматично вимкнено, якщо буде задіяно #
директива UseLogin. #
# #
X11Forwarding no
# #
## X11UseLocalhost ##########################################
# #
# Вказує, чи має sshd обмежити область #
# перенаправлення Х11 локальною loopback адресою, або #
# повинен дозволити будь-які адреси. Типово sshd #
# "Саджує" сервер перенаправлення Х11на локальну адресу #
# і задає частину змінної оточення DISPLAY, що відповідає #
# за ім'я хоста як "localhost". Варто зауважити, що #
деякі старі клієнти Х11 можуть не працювати з такими.
# Налаштуваннями. За умовчанням "yes", тобто. перенаправлення #
# обмежено локалхостом, значення "no" відключає #
обмеження. #
# #
## XAuthLocation ###########################################
# #
# Вказує повний шлях до програми xauth. #
# За замовчуванням /usr/bin/X11/xauth. #
# #
## X11DisplayOffset ########################################
# #
# Вказує номер першого дисплея, доступного sshd #
як перенаправлення X11. Це зроблено для того, #
щоб перенаправлені "ікси" не перетиналися з #
реальними. За замовчуванням 10.
# #
X11DisplayOffset10
# #
############################################################
################### Різні опції ########################
############################################################
# #
## LoginGraceTime ##########################################
# #
# Час, після якого сервер відключає #
# користувача, якщо той не зміг задовільно #
# Залогініться. Значення 0 дозволяє користувачеві #
логінітися нескінченно. Типово 120 (секунд). #
# #
LoginGraceTime 120
# #
## MaxAuthTries ############################################
# #
# Вказує максимальну кількість спроб автентифікації, #
дозволене для одного з'єднання. #
# Як тільки кількість невдалих спроб перевищить половину #
# заданого значення, всі наступні спроби будуть #
# Заносити в журнал. Значення за замовчуванням 6.
# #
MaxAuthTries 4
# #
## MaxSessions #############################################
# #
# Вказує максимальну кількість одночасних підключень #
# для кожного мережного з'єднання. За замовчуванням 10.
# #
MaxSessions1
# #
## MaxStartups #############################################
# #
# Вказує максимальну кількість одночасних #
# неавторизовані підключення до sshd. У разі якщо #
# Число підключень перевищить ліміт всі додаткові #
# підключення будуть скинуті до тих пір, поки поточні #
# Підключення не завершаться або успішною авторизацією, #
або закінченням періоду часу зазначеного в директиві #
# LoginGraceTime. Значення за замовчуванням 10.
# Додатково, можна задати раннє скидання з'єднань, #
# вказавши як параметр три значення, розділені #
# двокрапкою “start:rate:full” (наприклад: "10:30:60"). #
# sshd відхиляє спробу з'єднання з ймовірністю, що дорівнює #
# "rate/100" (тобто в нашому прикладі 30%), якщо вже #
# є “start” (10) неавторизованих з'єднань. #
# Імовірність збільшується лінійно та будь-які спроби #
# з'єднання будуть відхилені, якщо кількість неавторизованих #
# з'єднань досягне значення “full” (60). #
# #
## Compression ##############################################
# #
# Вказує, чи можна стиснути дані. Може бути #
# "yes" стиснення дозволено. #
# "delayed" стиснення відкладено до тих пір, поки #
Користувач успішно не аутентифікується. #
# "no" стиск заборонено. #
# За замовчуванням "delayed". #
# #
## UseLogin ################################################ #
# #
# Вказує, чи повинен використовуватися login для #
інтерактивного сеансу. Значення за промовчанням “no”. #
# Варто відзначити, що login ніколи не використовувався для #
# Виконання віддалених команд. Також зауважимо, що #
# використання login унеможливить використання #
# директиви X11Forwarding, тому що login не знає, що #
# йому робити з xauth. Якщо включено директиву #
# UsePrivilegeSeparation вона буде відключена після #
# Авторизації. #
# #
## UsePrivilegeSeparation ###################################
# #
# Вказує, чи має sshd розділяти привілеї. Якщо так #
# то спочатку буде створено непривілейований дочірній #
процес для вхідного мережевого трафіку. Після успішної #
# Авторизації буде створено інший процес з привілеями #
# користувача, що увійшов. Основна мета поділу #
# привілеїв запобігання перевищенню прав доступу. #
# За замовчуванням “yes”. #
# #
UsePrivilegeSeparation yes
# #
## StrictModes #############################################
# #
# Вказує чи повинен sshd перевірити режими доступу та #
# володіння користувацьких папок і файлів перед тим, як #
# дати користувачеві увійти. Зазвичай це пояснюється тим, що #
# новачки часто роблять свої файли доступними для запису #
# всім підряд.За замовчуванням "yes". #
# #
StrictModes yes
# #
## AcceptEnv ###############################################
# #
# Вказує, які змінні оточення, передані #
# Клієнтом будуть прийняті. Див. опцію SendEnv у клієнті. #
# Варто зауважити, що передача змінних можлива лише #
# для протоколу ssh2. Змінні вказуються на ім'я, #
# можна використовувати маски ('*' та '?'). Можна вказувати #
кілька змінних через пробіл, або розбити на #
# кілька рядків AcceptEnv. Будьте обережні деякі #
# Змінні оточення можуть бути використані для обходу #
# заборонених користувальницьких оточень. Користуйтеся цією #
директивою акуратно. За замовчуванням немає #
# Змінні оточення користувача не приймаються. #
# #
AcceptEnv LANG LC_*
# #
## PermitUserEnvironment ####################################
# #
# Вказує, чи має sshd сприймати #
# ~/.ssh/environment та опцію environment= в #
# ~/.ssh/authorized_keys. За промовчанням "no". Стоїть #
# Помітити, що дозвіл обробки оточення може дати #
# користувачам можливість обійти обмеження в деяких #
конфігураціях, що використовують такі механізми, як #
# LD_PRELOAD. #
# #
# #
## PidFile ############################################### ##
# #
# Вказує файл, який містить ідентифікатор процесу #
# (процес ID, PID) демона SSH. #
# За замовчуванням /var/run/sshd.pid #
# #
# #
## PrintLastLog ############################################
# #
# Вказує, чи має sshd виводити на екран дату і час #
# останнього сеансу при інтерактивному вході користувача. #
# За замовчуванням “yes”. #
# #
PrintLastLog yes
# #
## PrintMotd ###############################################
# #
# Вказує, чи повинен sshd виводити на екран /etc/motd #
# під час інтерактивного входу користувача. На деяких #
# системах (наприклад в Ubuntu) ця інформація так само #
# виводиться на екран оболонкою. #
# За замовчуванням “yes”. #
# #
PrintMotd no
# #
## Banner ############################################### ###
# #
# Вказує який файл містить текстовий банер, який #
# буде показано користувачеві ПЕРЕД процедурою #
аутентифікації. Опція доступна лише для протоколу ssh2.
# За замовчуванням нічого не показує. #
# У Ubuntu файл issue.net містить фразу Ubuntu (version), #
наприклад, для karmic це "Ubuntu 9.10". Можна, можливо #
використовувати для дезорієнтації можливих атакуючих;
# написавши туди наприклад "My D-Link Interet Router" =) #
# #
Banner /etc/issue.net
# #
## ChrootDirectory #########################################
# #
# Якщо зазначений надає шлях, яким буде #
# виконано chroot після аутентифікації. Шлях та всі його #
# вміст повинні відповідати належним #
# суперкористувачеві папкам і бути не доступними для #
# Записи іншими користувачами. #
# У дорозі можуть бути вказані мітки, що підставляються в #
# процесі аутентифікації: #
# %% замінюється літералом "%" #
# %h замінюється домашньою директорією #
# аутентифікується користувача #
# %u замінюється ім'ям користувача, що аутентифікується #
# chroot-папка повинна містити всі необхідні файли та #
# папки для сеансу користувача. Для інтерактивного #
# сеансу потрібні як мінімум: #
# Оболонка, зазвичай sh #
базові пристрої в /dev, такі як: #
# null, zero, stdin, stdout, stderr, арандом і tty #
# для сеансу передачі даних за допомогою sftp жодних #
# додаткових параметрів не потрібно, якщо використовується #
# Внутрішній процес sftp сервера. Див. Subsystem для #
більшої інформації. За замовчуванням chroot не виконується. #
# #
## ForceCommand ############################################
# #
# Примушує виконувати вказану команду. Ігнорує #
# будь-які команди передані клієнтом або записані в #
# ~/.ssh/rc. Команда викликається з користувача #
# Оболонки з опцією -с. Підходить для запуску оболонки #
команди або підсистеми. Найбільш корисна всередині блоку #
# Match. Команда, спочатку передана клієнтом, зберігається #
# у змінному оточенні SSH_ORIGINAL_COMMAND. Якщо #
# вказати команду "internal-sftp", буде запущено #
# Внутрішній sftp сервер, якому не потрібні додаткові #
# файли та папки, описані в директиві ChrootDirectory. #
# #
## Subsystem ###############################################
# #
# Визначає та налаштовує зовнішню підсистему (наприклад #
# демона передачі файлів (file transfer daemon). #
# Аргументами служать ім'я та команда (з можливими #
# аргументами), яка буде виконана під час запиту #
# на підсистеми. Команда sftp-server запускає "sftp" #
підсистему передачі файлів. Додатково можна вказати #
як підсистема “internal-sftp” що запустить #
# Внутрішній sftp сервер. Це може значно спростити #
# налаштування у разі використання директиви #
# ChrootDirectory За замовчуванням жодних підсистем #
# не викликається. Актуально лише для протоколу ssh2. #
# #
#Subsystem sftp /usr/lib/openssh/sftp-server #
# #
############################################################
##################### Блок Match ############################
############################################################
# #
# Спеціально виніс у кінець файлу, щоб було зручніше #
# писати Match правила. #
# MadKox. #
# #
# Директива Match є початок умовного #
блоку. Якщо виконані всі критерії, вказані у рядку #
Match, директиви в наступних рядках блоку виконуються,
# дозволяючи обійти значення глобальних директив файлу #
# sshd_config для випадку, що є критерієм директиви #
# Match. Блоком вважаються всі рядки, що йдуть після рядка #
# з критерієм (Match рядка) до наступного match-рядка #
або до кінця файлу. Аргумент директиви Match одна чи #
кілька пар записів критеріїв. Можливі види записів: #
# User #
# Group #
# Host #
# Address #
# Записи можуть містити як одиночні значення #
# (наприклад User=user), і кілька значень, #
# розділені комами (User=user1,user2). Так само можуть #
# бути використані регулярні вирази, описані в #
секції PATTERNS файлу ssh_config. Записи за критеріями #
# Address можуть містити адреси в нотації CIDR #
# (Адреса/Довжина маски, наприклад “192.0.2.0/24” або #
# "3ffe:ffff::/32"). Варто зауважити, що представлена #
# Довжина маски повинна відповідати адресі, і занадто #
# довгі/короткі для адреси не працюватимуть. #
# Як директив Match може використовувати лише #
певний набір директив: #
# AllowTcpForwarding #
# Banner #
# ChrootDirectory #
# ForceCommand #
# GatewayPorts #
# GSSAPIAuthentication #
# HostbasedAuthentication #
# KbdInteractiveAuthentication #
# KerberosAuthentication #
# MaxAuthTries #
# MaxSessions #
# PasswordAuthentication #
# PermitOpen #
# PermitRootLogin #
# RhostsRSAAuthentication #
# RSAAuthentication #
# X11DisplayOffset #
# X11Forwarding #
# X11UseLocalHost #
Відразу невелика ремарка до конфігу в ньому відключена можливість по ssh логінеться під користувачем root, тому якщо ви " любитель" виправте налаштування PermitRootLogin на yes
Для копіювання вище вказаного конфігу на вашу машину unix
Перейдіть в каталог, де зберігається конфігураційний файл sshd_config
Sudo cd /etc/ssh
Ми зробили резервну копію файлу sshd_config видалимо його
Sudo rm sshd_config
Все ще перебуваючи в директорії /etc/ssh, скопіюємо з сайту itautsors вище вказаний файл конфігурації ssh,
Sudo wget http://сайт/sshd_config
Перезапустимо демон
Sudo service ssh restart
Переконаємося, що демон SSH запущений
Ps-A | grep sshd
Побачимо щось подібне
<какой то номер>? 00:00:00 sshd
Якщо рядки немає, то SSH демон не запущений,
Перевіримо чи прослуховуються вхідні з'єднання:
Sudo ss-lnp | grep sshd
У відповідь отримаємо
0 128:::22:::* users:(("sshd",16893,4)) 0 128 *:22 *:* users:(("sshd",16893,3))
Якщо рядків більше ніж один, то демон SSH прослуховує більш ніж один порт, якщо не одному потрібно вказати хоча б один порт, в обох випадках необхідно повернуться і відредагувати конфігураційний файл
Спробуємо увійти з локального комп'ютера (тобто заходимо з того ж ПК, на якому налаштовуємо ssh server, так би мовити початкова перевірка), (пам'ятаємо, що у нас порт не стандартний 8022):
Ssh-v localhost-p 8022
Буде виведена інформація про налагодження, і пропозиція ввести пароль.
Після успішного з'єднання для виходу наберіть:
Налаштуємо доступ до OpenSSH Server із OpenSSH Client з авторизацією за ключом
Дано: Хост OpenSSH Server на який у майбутньому хочемо логінеться по ssh під користувачем NameUserOnOpenSSHServer з хоста OpenSSH Client Згенеруємо пару ключів на Хості, з якого ми хочемо підключитися (OpenSSH Client). Перевірте, може пара ключів вже згенерована.
Погодившись із місцем збереження ключа (/home/NameUserOnOpenSSHClient/.ssh/id_rsa), пароль можна залишити порожнім тоді при аутентифікації за сертифікатом не ніжно буде вводити пароль що менш надійно але набагато зручніше (у нашому прикладі вводити пароль не будемо):
Ssh-keygen -t rsa -b 4096
У домашній папці ~/.ssh користувача під яким запускали генерацію (у нашому прикладі NameUserOnOpenSSHClient) на хості OpenSSH Client з'являться файли:
~/.ssh/id_rsa.pubпублічний
~/.ssh/id_rsaприватний
Виставимо права на папку та файли
Без різниці під яким користувачем ми будемо запускати генерацію на OpenSSH Client, єдине логінеться на віддалену машину OpenSSH Server потрібно буде під цим користувачем так як права будуть виставлені наступні (такі права необхідно виставити щоб не був скомпроментований приватний ключ):
$ chmod 0700 ~/.ssh/ $ chmod 0600 ~/.ssh/id*
Передаємо публічний ключ із клієнта на сервер для користувача під яким знаходимося, командою ssh-copy-id у файл ~/.ssh/authorized_keys, якщо порт на якому слухає сервер не стандартний, необхідно його прописати використовуючи ключ -p і укласти в лапки. Ключ можна передати будь-яким способом, тому що він публічний.
Ssh-copy-id "-p 8022 NameUserONOpenSSHServer@ipAdressOpenSSHServer"
NameUserOnOpenSSHServer - це той користувач, під яким ми будемо в майбутньому логінеться на віддаленій машині.
Далі необхідно ввести пароль користувача NameUserONOpenSSHServer і після вдалої авторизації побачимо підказку:
Нова спроба підтримувати в машині, з "ssh "NameUserONOpenSSHServer@ipAdressOpenSSHServer"", і виконати: ~/.ssh/authorized_keys щоб зробити це не буде" added extra keys that you weren"t expecting.
Логін на Хост через ssh і перевіряє зміст файлу (в цьому файлі можуть бути прописані й інші ключі, шукаємо наш.) NameUserONOpenSSHServer/.ssh/authorized_keys:
Sudo ssh "NameUserONOpenSSHServer@ipAdressOpenSSHServer" sudo cat /home/NameUserONOpenSSHServer/.ssh/authorized_keys
Він повинен збігатися з вмістом файлу NameUserONOpenSSHClient/.ssh/id_rsa.pub
Sudo cat /home/NameUserONOpenSSHClient/.ssh/id_rsa.pub
Sudo mcedit /etc/ssh/sshd_config
Тиснемо F7, шукаємо PubkeyAuthentication, RSAAuthentication, AuthorizedKeysFile
мають бути розкоментовані рядки/виставлені параметри (перевіряємо):
# дозволяємо використання RSA ключів RSAAuthentication yes # якщо використовуєте SSH1 не бажано # дозволяємо авторизацію за допомогою ключів PubkeyAuthentication yes # Шлях, де будуть знаходитися ключі, з якими можна з'єднуватися для кожного користувача свій файл у його директорії. AuthorizedKeysFile %h/.ssh/authorized_keys
Перезапустимо сервер SSH
Sudo service ssh restart
Виставляємо права на файл /home/NameUserOnOpenSSHServer/.ssh/authorized_keys
Chmod 0600 ~/.ssh/authorized_keys
Виходимо з консолі OpenSSHServer, пробуємо залогінитися з клієнта на сервер, використовуючи сертифікат, вводимо рядок і повинні потрапити в консоль OpenSSHServer без введення пароля (якщо при генерації ключів ви не вводили пароль)
Ssh NameUser@ipAdressOpenSSHServer
Можливостей організувати віддалений доступ до вашого комп'ютера через інтернет-з'єднання існує у великій кількості. Деякі з них є дуже складними і використовуються лише фахівцями у професійному середовищі, у той час як інші – дуже прості та їх можуть освоїти навіть недосвідчені користувачі. Ми вже писали про кілька способів, зокрема, про програму TeamViewer та протокол VNC.
Нюанси роботи з протоколом SSH в Ubuntu.
У цій статті ми поговоримо про протокол безпечного підключення SSH, який останнім часом став практично стандартом серед користувачів Linux. Він дуже надійний, оскільки підтримує шифрування, а також його дуже легко налаштовувати. Ми розглянемо особливості протоколу SSH, а також навчимося виконувати налаштування сервера та клієнта. Все, що від вас буде потрібно - наявність комп'ютера із встановленою операційною системою Ubuntu та інтернет-підключення.
Протокол Secure Shell, відомий також як SSH – спеціальний протокол для безпечного віддаленого доступу до комп'ютера через підключення до мережі. Протокол має багато можливостей, у тому числі організацію захищеного підключення, запуск командного рядка терміналу на комп'ютері, до якого ви підключаєтеся віддалено, запуск програм з графічним інтерфейсом, передача файлів та розгортання приватних мереж.
Існує безліч утиліт, які відповідають за керуванням протоколом. На операційній системі Ubuntu найвідомішим є Open SSH. Це повністю вільний продукт з відкритою ліцензією та повним набором найнеобхідніших функцій. Клієнт для керування SSH-підключенням вже включений до дистрибутиву Ubuntu, вам потрібно буде лише встановити та налаштувати серверні компоненти. Управління здійснюється через команди у терміналі.
Установка SSH в Ubuntu
Оскільки протокол SSH клієнт для управління є загальноприйнятим стандартом, встановити його можна за допомогою короткої команди в терміналі Ubuntu. для цього запустіть сам термінал, натиснувши комбінацію кнопок на клавіатурі Ctrl+Alt+T, після чого застосуйте команду sudo apt-get install ssh. Після підготовки до завантаження утиліта запитає, чи хочете ви продовжити. переключіть клавіатуру на російську мову і натисніть кнопку Д. На вашому комп'ютері з Ubuntu установка ssh буде завершена вже через пару секунд. Якщо ви бажаєте активувати автоматичний запуск при включенні системи, використовуйте команду sudo systemctl enable sshd. відповідно, якщо потім ви захочете прибрати службу з автоматичного запуску, вам знадобиться команда sudo systemctl disable sshd.
Тепер можна перевірити, як усе працює. Цього достатньо спробувати підключитись до локального SSH server: ssh localhost. Утиліта обов'язково запросить пароль суперкористувача, а також запропонує додати введену адресу до списку дозволених. Якщо у вас все працює, як належить, ви побачите невелике повідомлення, яке закінчується повідомлення про дату останнього підключення до адреси.
Тепер можна підключатися до будь-якого комп'ютера в мережі, якщо ви знаєте його IP-адресу та ім'я користувача. для цього в терміналі вам потрібно запровадити команду наступного формату:
ssh имя_пользователя@ip_адреса
Наприклад, якщо ви хочете приєднатися до комп'ютера Васі Пупкіна з адресою 132.14.25.10, то команда виглядатиме так:
Налаштування SSH в Ubuntu
Для правильної та безпечної роботи з SSH-сервером його потрібно певним чином налаштувати. Для цього потрібно відредагувати файл параметрів sshd_config, розташований у каталозі /etc/ssh. Примітно, що його не можна змінити, просто відкривши файловий менеджер у звичайному текстовому редакторі. Система сповістить вас про недостатні права, і ви просто не зможете зберегти зміни. Тому вам знову знадобиться термінал та знання кількох команд, про які ми зараз розповімо. Давайте розглянемо необхідні кроки з налаштування ssh сервера в операційній системі Ubuntu.
Що можна змінити в налаштуваннях SSH
Мінімально необхідні команди
Або скорочено SSH, є однією з передових технологій захисту даних при передачі. Використання такого режиму на тому ж маршрутизаторі дозволяє забезпечити не тільки конфіденційність інформації, що передається, але і прискорити обмін пакетами. Щоправда, далеко не всі знають як SSH і навіщо все це потрібно. У разі доведеться дати конструктивне пояснення.
Порт SSH: що це та навіщо потрібно?
Оскільки йдеться про безпеку, у цьому випадку під портом SSH слід розуміти виділений канал зв'язку у вигляді тунелю, що забезпечує шифрування даних.
Найпримітивніша схема роботи такого тунелю полягає в тому, що відкритий SSH-порт за замовчуванням використовується для зашифрування інформації в джерелі та дешифруванні на кінцевій точці. Пояснити це можна так: хочете ви цього чи ні, трафік, що передається, на відміну від IPSec, шифрується в примусовому порядку і на виході одного мережевого терміналу, і на вході приймаючої сторони. Для розшифровки інформації, що передається цим каналом, приймаючий термінал використовує спеціальний ключ. Іншими словами, втрутитися в передачу або порушити цілісність даних, що передаються, на даний момент без ключа не може ніхто.
Саме відкриття SSH-порту на будь-якому маршрутизаторі або за допомогою відповідних налаштувань додаткового клієнта, що взаємодіє з SSH-сервером безпосередньо, дозволяє повною мірою використовувати всі можливості системи безпеки сучасних мереж. Йдеться тут про те, щоб використовувати порт, призначений за замовчуванням, або налаштування користувача. Ці параметри у застосуванні можуть виглядати досить складно, проте без розуміння організації такого підключення не обійтися.
Стандартний порт SSH
Якщо дійсно виходити з параметрів будь-якого маршрутизатора, спочатку слід визначитися з тим, яке саме програмне забезпечення буде використовуватися для залучення цього каналу зв'язку. Власне, порт SSH за замовчуванням може мати різні налаштування. Все залежить від того, яка методика застосовується в даний момент (пряме з'єднання з сервером, встановлення додаткового клієнта, прокидання портів і т. д.).
Так, наприклад, якщо як клієнт застосовується Jabber, для коректного з'єднання, шифрування та передачі даних повинен використовуватися порт 443, хоча в стандартному варіанті встановлюється порт 22.
Щоб переналаштувати маршрутизатор із виділенням для певної програми чи процесу необхідних умов, доведеться виконати прокидання портів SSH. є призначення певного доступу для окремої програми, яка використовує підключення до Інтернету, незалежно від того, які налаштування має поточний протокол обміну даними (IPv4 або IPv6).
Технічне обґрунтування
Як зрозуміло, стандартний порт SSH 22 використовується який завжди. Однак тут потрібно виділити деякі характеристики та параметри, які використовуються при налаштуванні.
Чому конфіденційність передачі зашифрованих даних передбачає використання протоколу SSH у вигляді виключно зовнішнього (гостевого) порту користувача? Та тільки тому, що тунелювання дозволяє використовувати так звану віддалену оболонку (SSH), отримати доступ до управління терміналом за допомогою віддаленого входу в систему (slogin), а також застосовувати процедури віддаленого копіювання (scp).
Крім того, SSH-порт може бути задіяний і в тому випадку, коли у користувача виникає необхідність виконання віддалених сценаріїв X Windows, що в найпростішому випадку являє собою передачу інформації з однієї машини на іншу, як говорилося, з примусовим шифруванням даних. У таких ситуаціях найнеобхіднішим буде використання алгоритмів на основі AES. Це алгоритм симетричного шифрування, яке спочатку передбачено в технології SSH. І використовувати його не лише можна, а й потрібно.
Історія реалізації
Сама технологія з'явилася досить давно. Залишимо поки що осторонь питання того, як зробити прокидання портів SSH, а зупинимося на тому, як все це працює.
Зазвичай все зводиться до використання проксі на основі Socks або застосувати тунелювання VPN. Якщо якийсь програмний додаток вміє працювати з VPN, краще віддати перевагу саме цьому варіанту. Справа в тому, що практично всі відомі на сьогодні програми, що використовують інтернет-трафік, з VPN працювати можуть, а налаштування маршрутизації особливих труднощів не становить. Це, як і у випадку з проксі-серверами, дозволяє залишити зовнішню адресу терміналу, з якого в даний момент виробляється вихід у мережу, невпізнаним. Тобто у випадку з проксі адреса змінюється постійно, а у варіанті VPN залишається незмінною з фіксацією певного регіону, відмінного від того, де діє заборона доступу.
Сама технологія, коли відкривається порт SSH, була розроблена ще в 1995 році в Технологічному університеті Фінляндії (SSH-1). У 1996 році було додано удосконалення у вигляді протоколу SSH-2, який набув досить великого поширення на пострадянському просторі, хоча для цього, так само як і в деяких країнах Західної Європи, іноді потрібне отримання дозволу на використання такого тунелю, причому від державних органів.
Основною перевагою відкриття SSH-порту, на відміну від telnet або rlogin, вважається застосування цифрового підпису RSA або DSA (використання пари у вигляді відкритого та заритого ключа). Крім того, в цій ситуації може використовувати так званий сеансовий ключ на основі алгоритму Діффі-Хеллмана, який передбачає застосування симетричного шифрування на виході, хоча і не виключає використання алгоритмів асиметричного шифрування в процесі передачі даних та їх прийому іншою машиною.
Сервери та оболонки
У Windows чи не так вже й важко. Питання тільки в тому, який інструментарій для цього буде використовуватися.
У цьому сенсі слід звернути увагу на питання передачі та аутентифікації. По-перше, сам протокол виявляється досить захищеним від так званого сніфінгу, що є звичайнісіньким «прослуховуванням» трафіку. SSH-1 виявився беззахисним перед атаками. Втручання у процес передачі у вигляді схеми «людина посередині» мало свої результати. Інформацію можна було просто перехопити та розшифрувати абсолютно елементарно. Натомість друга версія (SSH-2) була застрахована від такого втручання, званого session hijacking, завдяки чому і набула найбільшого поширення.
Заборони системи безпеки
Що ж до безпеки щодо переданих і прийнятих даних, організація підключення, створеного із застосуванням таких технологій, дозволяє уникнути появи таких проблем:
- визначення ключа до хоста на стадії передачі, коли використовується «зліпок» fingerprint;
- підтримка Windows та UNIX-подібних систем;
- підміна адрес IP і DNS (spoofing);
- перехоплення відкритих паролів при фізичному доступі до каналу передачі.
Власне, вся організація такої системи побудована за принципом «клієнт-сервер», тобто в першу чергу користувальницька машина за допомогою спеціальної програми або надбудови звертається до сервера, який і здійснює відповідне перенаправлення.
Тунелювання
Зрозуміло, що для здійснення підключення такого роду в системі повинен бути встановлений спеціальний драйвер.
Як правило, в Windows-системах це вбудований в програмну оболонку драйвер Microsoft Teredo, який є певним віртуальним засобом емулювання протоколу IPv6 в мережах з підтримкою тільки IPv4. за умовчанням перебуває у активному стані. У разі появи збоїв, з ним пов'язаних, можна просто перезапустити систему або виконати команди відключення і рестарту в командній консолі. Для деактивації використовуються такі рядки:
- netsh;
- interface teredo set state disabled;
- interface isatap set state disabled.
Після введення команд слід перезавантажити. Для повторного включення адаптера і перевірки його стану замість disabled прописується роздільна здатність enabled, після чого, знову ж таки, слідує рестарт всієї системи.
SSH-сервер
Тепер подивимося, який порт SSH використовується як основне, відштовхуючись від схеми «клієнт-сервер». Зазвичай за замовчуванням застосовується 22-й порт, але, як було зазначено вище, може використовувати і 443-й. Питання лише у перевагу самого сервера.
Найпоширенішими SSH-серверами прийнято вважати такі:
- для Windows: Tectia SSH Server, OpenSSH із Cygwin, MobaSSH, KpyM Telnet/SSH Server, WinSSHD, copssh, freeSSHd;
- для FreeBSD: OpenSSH;
- для Linux: Tectia SSH Server, ssh, openssh-server, lsh-server, dropbear.
Усі наведені сервери безкоштовні. Однак можна знайти і платні послуги, які відрізняються підвищеним рівнем системи безпеки, що конче необхідно для організації мережевого доступу та захисту інформації на підприємствах. Вартість таких послуг наразі не обговорюється. Але загалом можна сказати, що це відносно недорого, навіть у порівнянні з установкою спеціалізованого програмного або «залізного» файрвола.
SSH-клієнт
Зміна порту SSH зможе здійснюватися на основі клієнтської програми або відповідних налаштувань під час прокидання портів на маршрутизаторі.
Однак, якщо торкатися клієнтських оболонок, для різних систем можуть застосовуватись такі програмні продукти:
- Windows - SecureCRT, PuTTY\KiTTY, Axessh, ShellGuard, SSHWindows, ZOC, XShell, ProSSHD і т.д.;
- Mac OS X: iTerm2, vSSH, NiftyTelnet SSH;
- Linux і BSD: lsh-client, kdessh, openssh-client, Vinagre, putty.
Аутентифікація на основі відкритих ключів та зміна порту
Тепер кілька слів про те, як відбувається верифікація та налаштування сервера. У найпростішому випадку необхідно використовувати конфігураційний файл (sshd_config). Однак можна обійтися і без цього, наприклад, у разі використання програм на зразок PuTTY. Змінити порт SSH зі стандартного значення (22) на будь-яке інше можна абсолютно просто.
Головне - щоб номер порту, що відкривається, не перевищував значення 65535 (вище портів просто не буває в природі). До того ж, слід звернути увагу на деякі відкриті за замовчуванням порти, які можуть використовуватися клієнтами на кшталт MySQL або базами даних FTPD. Якщо вказати для SSH їх конфігурацію, ясна річ, ті просто перестануть працювати.
Варто врахувати, що той же клієнт Jabber має бути запущений в одному середовищі з використанням SSH-сервера, наприклад, на віртуальній машині. А самому серверу localhost необхідно буде надання значення 4430 (а не 443, як було зазначено вище). Така конфігурація може бути використана в тому випадку, коли доступ до основного файлу jabber.example.com блокується файрволом.
З іншого боку, перекинути порти можна і на маршрутизаторі, використовуючи для цього налаштування його інтерфейсу зі створенням правил виключення. На більшості моделей вхід здійснюється через введення адрес з 192.168 з додаванням 0.1 або 1.1, але на роутерах, що поєднують можливості ADSL-модемів на зразок Mikrotik, кінцева адреса передбачає використання 88.1.
У цьому випадку створюється нове правило, після цього встановлюються необхідні параметри, наприклад, для встановлення зовнішнього підключення dst-nat, а також вручну прописуються порти не в розділі загальних налаштувань, а в розділі переваг активних дій (Action). Нічого особливо складного тут нема. Головне – вказати необхідні значення налаштувань та встановити правильний порт. За замовчуванням можна використовувати порт 22, але, якщо використовується спеціалізований клієнт (якийсь із зазначених вище для різних систем), значення можна змінювати довільно, але тільки так, щоб цей параметр не перевищував заявлене значення, вище якого номери портів просто відсутні.
Під час налаштування підключення також варто звернути увагу на параметри клієнтської програми. Цілком можливо, що в її налаштуваннях доведеться вказати мінімальну довжину ключа (512), хоча за умовчанням зазвичай встановлено 768. Також бажано встановити тайм-аут входу в систему на рівні 600 секунд і дозвіл на віддалений доступ з використанням прав root. Після застосування таких налаштувань необхідно дати ще й дозвіл на використання всіх прав автентифікації, окрім тих, що ґрунтуються на використанні.rhost (але це потрібно лише системним адміністраторам).
Крім іншого, якщо ім'я користувача, зареєстрованого в системі, не збігається з введеним в даний момент, потрібно буде вказати його явно, використовуючи для цього команду user ssh master з введенням додаткових параметрів (для тих, хто розуміє, про що йдеться).
Для перетворення ключа і методу шифрування може застосовуватися команда ~/.ssh/id_dsa (або rsa). Для створення публічного ключа використовується перетворення за допомогою рядка ~/.ssh/identity.pub (але це не обов'язково). Але, як показує практика, найпростіше використовувати команди на зразок ssh-keygen. Тут суть питання зводиться лише до того, щоб додати ключ доступним інструментам авторизації (~/.ssh/authorized_keys).
Але ми зайшли надто далеко. Якщо повертатися до питання налаштування порту SSH, як зрозуміло, змінити порт SSH негаразд і складно. Щоправда, у деяких ситуаціях, як то кажуть, доведеться попітніти, оскільки потрібно буде врахувати всі значення основних параметрів. У іншому питання налаштування зводиться або до входу в серверну або клієнтську програму (якщо це передбачено спочатку), або до використання прокидання портів на маршрутизаторі. Але навіть у разі зміни порту 22, встановленого за замовчуванням, на той же 443-й, потрібно чітко розуміти, що така схема працює не завжди, а тільки у випадку встановлення тієї ж надбудови Jabber (інші аналоги можуть задіяти і відповідні їм порти, відрізняються від стандартних). Крім того, особливу увагу слід приділити виставленню параметрів SSH-клієнта, який безпосередньо взаємодіятиме з SSH-сервером, якщо таке дійсно передбачається у використанні поточного підключення.
В іншому ж, якщо не передбачено спочатку (хоча бажано виконати такі дії), налаштування та параметри для доступу за протоколом SSH можна і не змінювати. Тут особливих проблем при створенні з'єднання та його подальшому використанні, загалом, не передбачається (якщо, звичайно, не буде використовуватися ручне налаштування конфігурації на основі сервера та клієнта). Звичайне створення правила виключення на роутері дозволяє виправити всі проблеми або уникнути їх появи.
