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.

1. Відкриваємо /etc/hosts.allow та додаємо туди SSHD: 192.168.1.1

   де 192.168.1.1 - ваш IP. Якщо у вас динамічний IP, визначте IP з маскою підмережі та запишіть Вашу підсіть замість IP, наприклад:

   SSHD: 192.168.0.0/16

2. Відкриваємо /etc/hosts.deny та додаємо туди: SSHD: ALL

Ще один спосіб обмеження доступу по IP

Можна скористатися такою директивою:

AllowUsers = *@1.2.3.4

Тут ми дозволяємо доступ лише для IP 1.2.3.4

Авторизація SSH за ключами

Набагато безпечніше, зручніше та правильніше буде налаштувати ssh авторизацію без пароля. Для цього використовуватиметься авторизація за ключом.

Отже, ось інструкція:

Підключення настроєно. Якщо щось зробили не так, при авторизації з'явиться помилка Server refused our key , тобто Сервер не прийняв наш ключ. У цьому випадку пройдіться по всіх пунктах послідовно та пошукайте помилку

Або скорочено 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 можна і не змінювати. Тут особливих проблем при створенні з'єднання та його подальшому використанні, загалом, не передбачається (якщо, звичайно, не буде використовуватися ручне налаштування конфігурації на основі сервера та клієнта). Звичайне створення правила виключення на роутері дозволяє виправити всі проблеми або уникнути їх появи.

За допомогою захищеного протоколу 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», у разі успішного підключення надається командний рядок віддаленого комп'ютера.

Ця стаття позначена як незакінчена. Див. нотатку в кінці статті.

Ця стаття присвячена клієнту та серверу захищеного терміналу (secure shell) в Ubuntu, їх налаштуванню та використанню. SSH - це спеціальний мережевий протокол, що дозволяє отримувати віддалений доступ до комп'ютера з великим ступенем безпеки з'єднання. Докладніше про протокол ssh можна прочитати.

Опис принципів роботи та використовуваних додатків

В основному, SSH реалізований у вигляді двох додатків - SSH-сервера та SSH-клієнта У Ubuntu використовується вільна реалізація клієнта та сервера SSH-OpenSSH. При підключенні клієнт проходить процедуру авторизації у сервера та між ними встановлюється зашифроване з'єднання. OpenSSH сервер може працювати з протоколом ssh1, і з протоколом ssh2. В даний час протокол ssh1 вважається небезпечним, тому його використання не рекомендується. Я навмисно опускаю різні технічні подробиці роботи протоколу, тому що основною метою цього посібника є опис його налаштування та використання. Про сам протокол, принципи його роботи, алгоритми шифрування тощо існує безліч статей в інтернеті, наприклад докладно про це можна почитати.

Встановлення

Встановити OpenSSHможна з терміналу командою:

sudo apt-get install ssh

У метапакеті ssh міститься як клієнт, так і сервер, але при цьому, швидше за все, буде встановлений тільки сервер, тому що клієнт вже є в Ubuntu за замовчуванням.

Налаштування сервера

Під час встановлення SSH-сервер автоматично прописується в автозавантаження. Керувати його запуском, зупинкою або перезапуском можна за допомогою команд:

sudo service ssh stop| start| restart

Основний файл конфігурації SSH-сервера - файл /etc/ssh/sshd_config, доступний для читання або редагування лише суперкористувачу. Після кожної зміни цього файлу необхідно перезапустити ssh-сервер для застосування таких змін.

Приклад конфігурації SSH-сервера в Ubuntu за промовчанням:

# Приклад конфігурації open-ssh сервера з російськими # # коментарями..2010. # # # # # # Умовні позначення: # # Під "за замовчуванням" - мається на увазі поведінка sshd при # # невказаній явно директиві. Варто зауважити, що в Ubuntu # # файл sshd_config вже містить ряд налаштувань, які # # є налаштуваннями за замовчуванням саме для Ubuntu. # # Такі параметри вказані в цьому файлі. # # # ################################################ ############# ################ Налаштування адрес/портів і т.д. ########### ######################################## ###################### # # ## Port ######################### ############################ # # # # Використовуваний порт. Можна вказувати кілька, наприклад: # # Port 22 # # Port 23 # # Port 24 # # Рекомендується використовувати нестандартний порт, т.к. # # Стандартний часто сканується ботами на предмет # # Потенційних "дірок". Може бути опущений, якщо задано # # через адресу. Див. також параметр ListenAddress. # # # Port 22 # # ## ListenAddress ######################################## ### # # # Мережева адреса, на якій "слухає" сервер. Адреса можна # # записувати так: # # ListenAddress host | IPv4_addr | IPv6_addr # # ListenAddress host | Port. Якщо ви # # використовувати ListenAddress не вказуючи порт, то опція # # Port повинна передувати опції ListenAddress. Якщо не # # вказувати, то за промовчанням слухає на всіх локальних # # адресах. Можна вказати кілька адрес. # # # ## AddressFamily ############################################ # # Вказує, яке сімейство IP адрес має бути # # використане sshd. Можливі варіанти: # # "any" - будь-які # # "inet" (тільки IPv4) # # "inet6" (тільки IPv6) # # За замовчуванням - "any". # AddressFamily inet # # ## UseDNS ######################################### ######## # # # Вказує, чи повинен sshd перевіряти ім'я хоста і # # використовуючи це ім'я звіряти IP адреса передана клієнтом з # # отриманим від DNS. # # Значення за промовчанням - "yes". # # # ################################################ ############# ############# Налаштування доступу користувачів ############## ####### ################################################## ### # # # Пустить/не пустити користувача визначається директивами # # 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 # # заданий рівним 15 і ClientAliveCountMax залишений за # # замовчуванням, клієнти, що не відповідають, будуть відключені приблизно # # через 45 секунд. Ця директива працює тільки для # # протоколу ssh2. # # # ## ClientAliveInterval ##################################### # # # Задає тимчасовий інтервал в секундах. Якщо протягом # # цього інтервалу не було обміну даними з клієнтом, sshd # # посилає повідомлення зашифрованим каналом, # # запитує відповідь від клієнта. За замовчуванням – 0, тобто. # # не надсилати таких повідомлень. Ця директива працює # # тільки для протоколу ssh2. # # # ################################################ ############# ################ Загальні опції автентифікації #################### ################################################## ######## # # ## AuthorizedKeysFile ##################################### # # # # Вказує файл, у якому містяться публічні ключі, # # використовувані для автентифікації користувачів. Директива # # може містити маркери виду %М, які підставляються в # # процесі встановлення з'єднання. # # Визначено наступні маркери: # # %% - замінюється літералом "%" # # %h - замінюється домашньою директорією # # аутентифікується користувача # # %u - замінюється ім'ям користувача, що аутентифікується # # Таким чином, файл з ключами може бути заданий як # абсолютним шляхом (тобто один спільний файл з ключами), так і динамічно - в залежності від користувача (тобто по файлу на кожного користувача). # # За замовчуванням - ".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 # # в процесі автентифікації, заснованої на перевірці хоста. # # (RhostsRSAAuthentication або HostbasedAuthentication). # # Файли /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 yes # # ## Protocol ######################################## ######## # # # Вказує, який протокол повинен використовувати sshd. # # Можливі значення '1' та '2' - ssh1 і ssh2 # # відповідно. Можливий одночасний запис, при якому значення # слід розділяти комами. # # За замовчуванням - "2,1". # # Варто відзначити, що порядок проходження протоколів в # # запису не ставить пріоритет, т.к. клієнт вибирає який # # з кількох запропонованих сервером протоколів йому # # використовувати. Запис "2,1" абсолютно ідентична # # запису "1,2". # # # Protocol 2 # # ## UsePAM ######################################## ########## # # # Включає інтерфейс PAM (Pluggable Authentication Module # # interface). на основі ## запиту-відповіді (ChallengeResponseAuthentication та ##PasswordAuthentication) Т.к. аутентифікація # # запитів-відповідей у ​​PAM зазвичай виконує ту ж роль, # # що і парольна автентифікація, вам слід відключити # # або PasswordAuthentication, або # # ChallengeResponseAuthentication. Варто зазначити, що # # якщо директива UsePAM включена - ви не зможете запустити # # sshd від імені користувача, відмінного від root. # # Значення за промовчанням - "no". # # # UsePAM yes # # ## PasswordAuthentication ################################## # # # Вказує, дозволена чи аутентифікація з використанням # # пароля. # # За замовчуванням – “yes”. # # # ## HostKey ############################################ ##### # # # Вказує файл, що містить закритий хост-ключ, # # використовується SSH. За замовчуванням - /etc/ssh/ssh_host_key # # для протоколу ssh1 та /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. # # Актуально лише для протоколу ssh1. # # За замовчуванням - "no". # # # RhostsRSAAuthentication no # # ## RSAAuthentication ######################################## # # Вказує, чи "чиста" RSA-автентифікація дозволена. # # Актуально лише для протоколу ssh1. # # За замовчуванням – “yes”. # # # RSAAuthentication yes # # ## ServerKeyBits ######################################## ### # # # Визначає число біт у тимчасовому ключі сервера для # # протоколу ssh1. Мінімальне значення 512. # # Значення за замовчуванням - 1024. # ServerKeyBits 768 # # ################################# ########################### ########### Опції протоколу 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, aes256-ctr # # # ## HostbasedAuthentication ################################## # # # Вказує, чи дозволена аутентифікація , Заснована на # # перевірці хоста. Перевіряється rhosts або /etc/hosts.equiv, # # і в разі успіху, спільного з успішною перевіркою # # публічного ключа, доступ дозволяється. Ця директива # # однакова з директивою RhostsRSAAuthentication і # # підходить лише протоколу ssh2. # # За замовчуванням - "no". # # # HostbasedAuthentication no # # ## 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 , які дозволяють здійснити # # KDC's identity) # # За замовчуванням - "no". # # # ## KerberosGetAFSToken ##################################### # # # Якщо активовано AFS і користувач отримав Kerberos 5 TGT, # # чи намагатися отримати AFS токен до того, як користувач # # отримає доступ до своєї домашньої папки. # # За замовчуванням - "no". # # # ## KerberosOrLocalPasswd ################################### # # # Вказує, як чинити у випадку , якщо автентифікація # # через Kerberos завершилася невдачею. Якщо # # значення = "yes" - пароль буде перевірено за допомогою # # будь-якого додаткового локального механізму авторизації, # # наприклад - /etc/passwd. # # За замовчуванням – “yes”. # # # ## KerberosTicketCleanup ################################### # # # Вказує, чи потрібно автоматично знищувати файл з # # кешем тикету користувача після завершення сеансу. # # За замовчуванням – “yes”. # # # ################################################ ############################## Опції перенаправлення ################### ## ################################################ ############# # ## AllowAgentForwarding ################################# ### # # # Вказує, дозволити або заборонити перенаправлення # # ssh-agent"а. За замовчуванням - "yes", тобто дозволити. # # Варто помітити, що відключення перенаправлення не # # збільшить безпеки поки користувачам також не буде # # заборонено shell доступ, тому що вони завжди зможуть встановити # # свої власні аналоги агента. ################ # # # Вказує, дозволити або заборонити перенаправлення TCP.# # За замовчуванням - "yes", тобто дозволити. у випадку з AllowAgentForwarding відключення # # перенаправлення не збільшить безпеки, поки у # # користувачів буде консольний доступ, тому що вони зможуть # # встановити свої аналоги # # # # # # ## GatewayPorts ######### ##################################### # # Вказує, чи дозволяти віддаленим хостам доступ до # # перенаправлених портів . За замовчуванням sshd слухає # # з'єднання до перенаправлених портів тільки на локальному # # інтерфейсі (loopback). Це не дає іншим віддаленим хостам # приєднуватися до перенаправлених портів. Можна # # використовувати GatewayPorts, щоб дозволити sshd це # # робити. Директива може приймати 3 значення: # # "No" - тільки loopback. # # "yes" - будь-які адреси. # # "clientspecified" - адреси, вказані клієнтом. # # # ## 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 та DEBUG1 еквівалентні один одному. # # DEBUG2 і DEBUG3 задають найвищі рівні налагоджувального # # виведення. Запис логів з рівнем DEBUG загрожує приватності користувачів і не рекомендований. # # # LogLevel INFO # # ########################################### #################################### Перенаправлення X11 ############ ######## ########################################### ################## # # ## X11Forwarding ############################ ################ # # # Вказує, чи дозволено перенаправлення графічної # # підсистеми X11. Може набувати значення “yes” або “no”. # # За замовчуванням - "no". # # Увага - включення простого перенаправлення Х11 - # # Великий ризик як сервера, так клієнтів, т.к. у випадку такого перенаправлення проксі-дисплей sshd приймає з'єднання з будь-яких адрес. Використовуйте # # директиву X11UseLocalhost для обмеження доступу до # # серверу перенаправлення "іксів". Варто зазначити, що # # відключення перенаправлення не дасть гарантії, що користувачі не зможуть перенаправляти Х11, т.к. маючи # # консольний доступ вони завжди встановити свій # # перенаправник. Перенаправлення X11 буде # # автоматично вимкнено, якщо буде задіяна # # директива UseLogin. # # # X11Forwarding yes # # ## X11UseLocalhost ######################################## # # # # Вказує, чи повинен sshd обмежити область # # перенаправлення Х11 локальною loopback адресою, або # # повинен дозволити будь-які адреси. За замовчуванням - sshd # # "Саджує" сервер перенаправлення Х11 на локальну адресу # # і задає частину змінної оточення DISPLAY, що відповідає # # за ім'я хоста як "localhost". Варто зауважити, що деякі старі клієнти Х11 можуть не працювати з такими налаштуваннями. За умовчанням – "yes", тобто. перенаправлення # # обмежене локалхостом, значення - "no" - відключає # # обмеження. # # # ## XAuthLocation ############################################ # # Вказує повний шлях до програми xauth. # # За замовчуванням - /usr/bin/X11/xauth. # # # ## X11DisplayOffset ######################################## # # # Вказує номер першого дисплея, доступного sshd в # # як перенаправлення X11. Це зроблено для того, щоб перенаправлені "ікси" не перетиналися з реальними. За замовчуванням - 10. # # # X11DisplayOffset 10 # # ###################################### ######################################### Різні опції ####### ################################################### ########################### # ### LoginGraceTime ################### ######################## # # # Час, після якого сервер відключає # # користувача, якщо той не зміг задовільно # # залогінитися. Значення 0 - дозволяє користувачеві # # логінитися нескінченно. За замовчуванням – 120 (секунд). # # # LoginGraceTime 120 # # ## MaxAuthTries ######################################## #### # # # Вказує максимальну кількість спроб аутентифікації, # # дозволене для одного з'єднання. # # Як тільки число невдалих спроб перевищить половину заданого значення # #, всі наступні спроби будуть # # заноситися в журнал. Значення за замовчуванням - 6. # # # ## MaxSessions ##################################### ####### # # # Вказує максимальну кількість одночасних підключень # # для кожного мережного з'єднання. За замовчуванням - 10. # # # ## 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 ########################################## ####### # # # Вказує файл, що містить ідентифікатор процесу # # (process 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, arandom і 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 # # KerberosAut PasswordAuthentication # # PermitOpen # # PermitRootLogin # # RhostsRSAAuthentication # # RSAAuthentication # # X11DisplayOffset # # X11Forwarding # # X11UseLocalHost #

Можна скопіювати наведений вище текст у власний sshd_config і використовувати в подальшому для налаштування.

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

Port, ListenAddress та AddressFamily

Ці три параметри визначають, на яких портах та адресах ваш сервер чекатиме вхідні з'єднання. По-перше, має сенс наскільки можна обмежити сімейство оброблюваних адрес реально використовуваними, т. е. якщо ви використовуєте лише IPv4 - відключіть IРv6, і навпаки. Зробити це можна за допомогою параметра AddressFamily, наприклад (для дозволу IPv4 та заборони IPv6):

AddressFamily inet

По-друге, бажано змінити стандартний порт (22), на якому слухає sshd. Це пов'язано з тим, що численні мережеві сканери постійно намагаються з'єднатися з 22 портом і як мінімум отримати доступ шляхом перебору логінів/паролів зі своєї бази. Навіть якщо у вас і відключено парольну автентифікацію - ці спроби сильно засмічують журнали і (у великій кількості) можуть негативно вплинути на швидкість роботи сервера ssh. Якщо ж ви з якоїсь причини не бажаєте змінити стандартний порт, ви можете використовувати як різні зовнішні утиліти для боротьби брутфорсерами, наприклад fail2ban, так і вбудовані, такі як MaxStartups.
Задати порт можна як абсолютним значенням всім інтерфейсів з допомогою директиви Port , і конкретним значенням кожному за інтерфейсу, з допомогою директиви ListenAddress . Наприклад:

Port 2002

ListenAddress 192.168.0.1:2003 ListenAddress 192.168.1.1:2004

Заборона віддаленого доступу для суперкористувача

За промовчанням root-доступ заборонено за паролем (за ключом - можна) - опція PermitRootLogin встановлена ​​в without-password . Але за умови, що за замовчуванням в Ubuntu користувач, доданий при встановленні системи, має можливість вирішувати всі адміністративні завдання через sudo, створювати можливість root доступу до системи через ssh - виглядає нерозумно (навіть при аутентифікації за ключом). Рекомендується зовсім вимкнути. цю опцію або застосовувати її тільки в режимі forced-commands-only . Відключити root-доступ можна так:

PermitRootLogin no

Парольна автентифікація

Дозволена за замовчуванням парольна автентифікація є практично найпримітивнішим способом авторизації в sshd. З одного боку це спрощує конфігурацію та підключення нових користувачів (користувачеві достатньо знати свій системний логін/пароль), з іншого боку пароль завжди можна підібрати, а користувачі часто нехтують створенням складних та довгих паролів. Спеціальні боти постійно сканують доступні з інтернету ssh сервери та намагаються авторизуватися на них шляхом перебору логінів/паролів зі своєї бази. Настійно не рекомендується використовувати парольну автентифікацію. Вимкнути її можна так:

PasswordAuthentication no

Якщо з якихось причин вам все ж таки хочеться використовувати парольну автентифікацію - подбайте про те, щоб ніхто не міг авторизуватися з порожнім паролем. Для цього задайте директиву PermitEmptyPasswords:

PermitEmptyPasswords no

Протоколи SSH1 та SSH2

Як було зазначено, sshd може працювати з протоколами SSH1 і SSH2. При цьому використання небезпечного SSH1 не рекомендується. Змусити sshd працювати лише з протоколом SSH2 можна так:

Аутентифікація на основі SSH2 RSA-ключів

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

PubkeyAuthentication yes

Сервер повинен знати, де слід шукати публічний ключ користувача. Для цього використовується спеціальний файл authorized_keys . Синтаксис може бути наступним:

# Коментарі записуються тільки з нового рядка # загальний вигляд записів у файлі authorized_keys # [опції] тип_ключа(ssh-rsa або ssh-dss) дуже_довга_рядок_незрозуміла_простій_людині [логін@хост] [email protected] from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== [email protected] command="dump /home",no-pty,no-port-forwarding ssh-dss AAAAC3...51R== example.net permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh -dss AAAAB5...21S== tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...== [email protected]

Можна вказати як один спільний файл із ключами, так і за файлом на кожного користувача. Останній спосіб є зручнішим і безпечнішим, тому що можна по-перше вказувати різні комбінації ключів для кожного користувача, а по-друге обмежити доступ до публічного ключа користувача. Задати файл із ключами можна за допомогою директиви AuthorizedKeysFile:

AuthorizedKeysFile %h/.ssh/my_keys

для схеми користувач - файл
або

AuthorizedKeysFile /etc/ssh/authorized_keys

для схеми із загальним файлом. За замовчуванням SSH-клієнт шукає ключі у файлі ~/.ssh/authorized_keys.

Ще про безпеку

Додаткові налаштування

Користувачі та групи.

Якщо у вас на сервері «живе» багато користувачів, а доступ через ssh ви хочете дозволити лише декільком з них - ви можете використовувати директиви DenyUsers, AllowUsers, DenyGroups і AllowGroups. Докладніше про ці директиви див. коментарі на прикладі sshd_config .

Опції визначення стану з'єднання

За замовчуванням із способів визначення стану з'єднання включений тільки спосіб перевірки TCP з'єднання - TCPKeepAlive , проте, sshd вміє визначати стан з'єднання і зручнішими та безпечнішими способами. Докладніше див. відповідний розділ у прикладі sshd_config.

Продуктивність. MaxStartups

Перенаправлення портів

Перенаправлення X11

На сервері у файлі /etc/ssh/sshd_config виставити параметр (за замовчуванням увімкнено):

ForwardX11 yes

На клієнті у файлі /etc/ssh/ssh_config виставити параметри (за замовчуванням вимкнено):

ForwardAgent yes ForwardX11 yes

Запускати на клієнті можна так ssh yurauname@serverip firefox. Або спочатку заходимо ssh yurauname@serverip потім запускаємо, наприклад sudo synaptic.

SFTP

За замовчуванням в sshd вбудований SFTP-сервер. Протокол SFTP (SSH File Transfer Protocol) - SSH-протокол передачі файлів. Він призначений для копіювання та виконання інших операцій із файлами поверх надійного та безпечного з'єднання. Як правило, як базовий протокол, що забезпечує з'єднання, і використовується протокол SSH2. Щоб увімкнути підтримку SFTP, додайте в sshd_config рядок

Subsystem sftp /usr/lib/openssh/sftp-server

За промовчанням підтримка SFTP увімкнена.

Використання критеріїв. Директива Match

Налаштування SSH-клієнта

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

ssh-keygen -t rsa

Отримуємо пропозицію ввести пароль для захисту файлу ключа (виявляється корисним при попаданні файла в чужі руки). Якщо ми збираємося по SSH виконувати скрипти, залишаємо порожнім. Передаємо публічний ключ на сервер командою

Ssh-copy-id -i ~/ .ssh/ id_rsa.pub user@ server

Все можна заходити.

Коли ssh працює на нестандартному порту:

Ssh-copy-id -i ~/ .ssh/ id_rsa.pub "-p port user@server"

Якщо виникає помилка: Bad port "umask 077; test -d .ssh || mkdir .ssh ; cat >> .ssh/authorized_keys"

спробуйте взяти параметри в лапки:

Ssh-copy-id "-i /home/user/.ssh/id_rsa.pub "-p port user@server""

Зручно при підключенні на віддаленій системі користуватися утилітою screen.

Налаштування віддаленої ssh-директорії в Nautilus

Монтування віддаленої директорії за допомогою sshfs

Монтування віддаленого каталогу до локального каталогу

sshfs user@ hostingserver.ru:/ home/ userdir ~/ sshfsdir

Розмонтування

Fusermount -u ~/ sshsfdir

SSH aliases

При використанні кількох серверів з різними параметрами доступу (нестандартний порт, довге ім'я хоста, логін відмінний від локального, тощо) інколи втомливо вводити всі налаштування підключення щоразу заново. Для полегшення цього можна використовувати або.

Установки зберігаються в ~/.ssh/config для одного користувача та /etc/ssh/ssh_config глобально для всіх користувачів.

Приклад конфіг. Описано може бути безліч серверів. Детальніше у man ssh_config(не плутати з sshd_config)

Host AliasName # Довільне ім'я хоста HostName 1.2.3.4 # Можна вказувати як IP, так і hostname (якщо працює DNS) User YourUserName # Якщо користувач не збігається з локальним користувачем Port YourSSHPort # Якщо нестандартний порт

Після цього можна підключатися до сервера командою

ssh AliasName

ssh-agent

Діагностика проблем підключення

Аналіз лога підключення:

ssh -vvv user@ host

Аналіз конфігураційних файлів клієнта та сервера.

Розташування конфігураційних файлів можна дізнатися з

man ssh man sshd

Використання смарт-карток

1. Створення сертифіката та експорт відкритого ключа, а також клієнтська частина на Windows + Putty SC описано на сайті: http://habrahabr.ru/post/88540/ Описане доповнення Key Manager доступне тільки в старих версіях Firefox. Перевірено на версії 3.5 для Windows. Пряме посилання на додаток: https://addons.mozilla.org/ru/firefox/addon/key-manager/

2. Підготовка сервера. Вам необхідно переконатися, що у конфігурації sshd дозволена аутентифікація за допомогою публічних ключів. Для цього необхідно у файлі "sshd_config" вказати значення параметра "PubkeyAuthentication" у "yes". Потім у файл "~/.ssh/authorized_keys" додаємо наш публічний ключ отриманий раніше (одним рядком). Зверніть увагу, файл ".ssh/authorized_keys" знаходиться в домашньому каталозі того користувача, який потім буде логінуватися за публічним ключем.

3. Клієнтська частина на Linux. Потрібно перескладання пакета OpenSSH без параметрів. Рекомендується вказати лише префікси каталогів, наприклад –prefix=/usr. Також слід врахувати, що файли конфігів будуть у /usr/etc. Перед початком необхідні пакети: opensc-lite-devel, zlib-devel, openssl-devel. Встановлюємо драйвер смарт-картки. Для зручності в конфізі ssh_config (не плутати з sshd_config) вказати шлях до бібліотеки pkcs: PKCS11Provider=<путь к библиотеке>

4. На клієнті запускаємо ssh user@host Якщо смарт-карта (токен) підключена, буде запитаний пароль та виконано вхід до сесії SSH .

Можливі проблеми під час використання

Звична комбінація клавіш Ctrl + S , що використовується в багатьох редакторах для збереження виправлень, при роботі в терміналі з ssh-сервером призведе до виконання команди XOFF, що зовні нагадує зависання сесії. Однак, це не так. Сервер продовжує приймати символи та команди, що вводяться, але не виводить це на екран. Щоб вийти з такого скрутного становища досить застосувати комбінацію Ctrl + Q, тим самим включивши режим XON назад.

Посилання

Т. е. user1 може бути прописаний як у себе - у файлі /home/user1/.ssh/keys) так і в іншого користувача, що дозволить йому виконувати зі свого комп'ютера вхід як «під собою», так і під «іншим»

Хостинг із ssh доступомзустрічається напевно не так часто, принаймні, на мій досвід. Мій останній SSH хостинг підтримує, і я вирішив випробувати його в справі, до того ж у мене для цього був вагомий привід. Справа в тому, що мій поточний хостинг детально не показує розмір файлів.

Через FTP клієнт це теж не подивитись, а мені це дуже необхідно, тому що місце на хостингу швидко закінчилося і мені потрібно видалити все сміття, щоб не купувати додаткові мегабайти та не платити зайве. А ще нещодавно мої сайти заразили, і я і без ssh доступу це було б неможливо.

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

Що таке хостинг із ssh доступом?

Але спочатку скажу про те, що таке SSH, тому що, можливо, не всі знають, що це за звір. А якщо коротко, то згідно з Вікіпедією це:

SSH (англ. Secure SHell – «безпечна оболонка») – мережевий протокол прикладного рівня, що дозволяє виробляти віддалене керування операційною системою та тунелювання TCP-з'єднань (наприклад, для передачі файлів). SSH припускає вибір різних алгоритмів шифрування. SSH-клієнти та SSH-сервери доступні для більшості мережевих операційних систем.

З ssh можна працювати безпосередньо через термінал за допомогою команд Linux. Підключитися до сервера дуже легко, потрібно набрати команду в такому форматі:

Ssh ім'я_користувача@адреса_сервера

Як бачите, все дуже просто. Спробую підключитись через ssh до свого хостингу. Але не тут було, хостинг наполегливо не хотів мене приймати за цим протоколом. Я написав у службу підтримки і тепер чекаю на відповідь.

Ну а поки я вам розповім, як зручно можна підключитися через ssh через файловий менеджер Nautilus. Підключившись до нього за SSH, ви будете працювати з файлами, які лежать на хостингу, ніби вони лежать на вашому комп'ютері. Відкриваємо Nautilus і натискаємо Ctrl+L, щоб в адресному рядку можна було написати шлях до сервера ssh:

Sftp:// [email protected]

Потім вас попросять ввести пароль, і ви побачите у файловому менеджері всі свої файли. Ось такі переваги є у хостингу із ssh.

Тому вибираючи хостинг звертайте на це увагу. Мій хостинг IHOR дає доступ до SSH і тому я користуюся ним уже кілька років.

РАДА ВЕБМАСТЕР:Уміння заробляти в інтернеті - це тільки пів справи, друга половина - це вміння ВИГІДНО переводити в готівку електронні гроші. Ось список офшорних банківських карток, на які можна виводити кошти і потім знімати з них хрусткі купюри:

1. Payoneer- Найпопулярніша у світі платіжна система для фрілансерів. Видає карти, перебуває у США.

2. EpayService- Американська платіжна система, дуже популярна у багатьох країнах, безкоштовно дає картку MasterCard у EVRO для мешканців СНД та Європи.

3. Skrill- Єдина платіжна система, яка працює з криптовалютами і при цьому випускає безкоштовні банківські картки MasterCard.

4. AdvCash- Офшорний банк знаходиться в Белізі, можна відкрити рахунок у доларах, євро, фунтах та рублях.

5. Payeer- Штаб квартира цієї платіжної системи знаходиться в Грузії, тут також можна відкрити рахунок у доларах, євро та рублях.

Домен RU - 99 руб Домен РФ – 99 руб