Модуль 0.8: Сервери та SSH

Складність: [ШВИДКО] — Концепції та практичне підключення

Час на проходження: 25 хвилин

Передумови: Модуль 0.5 — Редагування файлів

Що ви зможете зробити

Після цього модуля ви зможете:

Пояснити, що таке сервер і чому йому не потрібні екран чи клавіатура
Під’єднатися до віддаленої машини за допомогою SSH та керувати нею через термінал
Розрізняти автентифікацію за паролем та на основі ключів SSH і пояснити, чому ключі безпечніші
Перевірити, чи ви на потрібній машині після підключення (використовуючи hostname, whoami, pwd)

Чому це важливо

Усе, що ви робили досі, відбувалося на вашому комп’ютері. Ваша кухня, ваші файли, ваш термінал. Але в реальному світі технологій більшість подій відбувається на комп’ютерах, які знаходяться десь інде — у дата-центрі, у хмарі або в серверній стійці, до якої ви ніколи не торкнетеся фізично.

Ці інші комп’ютери називаються серверами, а спосіб спілкування з ними — SSH.

Коли ви працюєте з Kubernetes, ви будете керувати серверами (багатьма). Розуміння того, що таке сервери і як до них підключатися, не є опціональним — це фундаментальна база.

Що таке сервер?

Сервер — це просто комп’ютер. Це все. Ніякої магії чи таємниць.

Слово «сервер» описує те, що комп’ютер робить, а не те, чим він є. Сервер — це комп’ютер, завдання якого — обслуговувати (serve) інші комп’ютери.

Ваш ноутбук:
  - Має екран, клавіатуру, трекпад
  - Створений для ОДНІЄЇ людини, яка сидить перед ним
  - Працює з графічним інтерфейсом (вікна, іконки, миша)
  - Ви переглядаєте вебсторінки, пишете документи, дивитеся відео

Сервер:
  - Часто НЕ має екрана, клавіатури чи миші
  - Створений для одночасного обслуговування БАГАТЬОХ користувачів/комп'ютерів
  - Зазвичай працює ТІЛЬКИ з інтерфейсом термінала (без робочого столу)
  - Він хостить вебсайти, запускає бази даних, обробляє дані

Аналогія з кухнею

Подумайте про це так:

Ваш ноутбук — це домашня кухня. Ви готуєте для себе. Ви їсте в тій же кімнаті, де готуєте. «Шеф-кухар» і «клієнт» — це одна і та сама особа.
Сервер — це кухня ресторану. Вона існує для того, щоб готувати їжу та відправляти її назовні в обідній зал, повний клієнтів. На кухні немає обідніх столів — це не її робота. Її робота — готувати та подавати.

Коли ви відвідуєте вебсайт, ваш браузер (клієнт в обідньому залі) надсилає запит серверу (кухні в підсобному приміщенні). Сервер готує відповідь (готує страву) і відправляє її назад у ваш браузер (подає страву).

Ваш ноутбук проти сервера

«Під капотом» вони мають однакові основні частини:

Компонент	Ваш ноутбук	Типовий сервер
CPU	4-8 ядер	16-128 ядер
RAM	8-32 GB	64-512 GB
Storage	256 GB - 2 TB	1 TB - 100 TB+
Екран	Так	Зазвичай ні
Клавіатура	Так	Зазвичай ні
Операційна система	macOS/Windows	Linux (майже завжди)
Призначення	Одна людина, багато завдань	Багато клієнтів, специфічні завдання

Сервер — це, по суті, потужний комп’ютер, оптимізований для обробки багатьох запитів одночасно, роботи 24/7 та віддаленого керування.

Local vs. Remote

Два слова, які ви чутимете постійно:

Local (локальний) = ваш комп’ютер, прямо тут, перед вами
Remote (віддалений) = інший комп’ютер десь інде, до якого ви підключаєтеся через мережу

Локальний: Ваша кухня. Ви стоїте в ній.
Віддалений: Кухня в іншому місті. Ви телефонуєте їм, щоб дати замовлення.

Коли ви вводите ls у своєму терміналі зараз, ця команда виконується локально — на вашому комп’ютері.

Коли ви підключаєтеся до сервера і вводите ls, ця команда виконується віддалено — на сервері. Але у вашому терміналі це виглядає точно так само. У цьому і полягає краса.

Швидка перевірка: локально чи віддалено?

Зупиніться та подумайте: Класифікуйте ці 5 сценаріїв як локальні або віддалені операції.

Редагування фотографії на робочому столі вашого ноутбука.

Використання SSH для перевірки логів вебсервера в Лондоні.

Запуск pwd у терміналі відразу після його відкриття.

Введення ls після підключення через ssh admin@10.0.0.5.

Ваш браузер запитує вебсторінку з Вікіпедії.

Відповіді

1. **Локально** (відбувається на машині перед вами) 2. **Віддалено** (ви кажете далекому серверу показати його логи) 3. **Локально** (ви ще не підключилися до іншої машини) 4. **Віддалено** (ваш термінал тепер керує машиною 10.0.0.5) 5. **Віддалено** (сервер Вікіпедії надсилає вам дані сторінки)

SSH: Ваш захищений тунель до віддалених кухонь

SSH розшифровується як Secure Shell (захищена оболонка). Це програма, яка дозволяє безпечно відкрити сесію термінала на віддаленому комп’ютері.

Уявіть SSH як захищену телефонну лінію до віддаленої кухні. Ви берете слухавку (відкриваєте SSH), набираєте номер (підключаєтеся до сервера) і починаєте давати замовлення (вводити команди). Шеф-кухар на віддаленій кухні виконує їх, а ви чуєте результат через слухавку.

Частина «захищена» (secure) є важливою: усе, що ви надсилаєте через SSH, шифрується. Ніхто не може підслухати вашу розмову. Це як мати приватну, зашифровану телефонну лінію.

Кілька слів про змінні оточення

Ви іноді бачитимете такі речі, як $USER або $HOME у командах або документації. Це змінні оточення (environment variables) — іменовані коробки, які ваша система автоматично заповнює корисними значеннями.

$USER містить ваше ім’я користувача
$HOME містить шлях до вашої домашньої директорії

Спробуйте їх:

echo $USER
echo $HOME

Вам не потрібно їх встановлювати — ваш комп’ютер робить це за вас під час входу в систему. Ми згадуємо про це зараз, тому що команди SSH часто використовують $USER, і ви будете зустрічати змінні оточення протягом усієї кар’єри.

Спробуйте зараз

Запустіть ці команди у своєму терміналі прямо зараз:

echo $USER
echo $HOME

Зупиніться та подумайте: Якщо ви під’єднаєтеся до віддаленого сервера за допомогою ssh chef@192.168.1.100 і потім запустите echo $USER, що він виведе? Ім’я користувача вашого ноутбука чи chef?

Відповідь
Він виведе chef! Коли ви заходите на сервер через SSH, команди виконуються в контексті віддаленого користувача. Змінна $USER на цьому сервері встановлена в ім'я користувача, під яким ви увійшли.

Команда SSH

Базова команда SSH виглядає так:

ssh username@ip-address

Розберемо її:

ssh — програма, яку ви запускаєте
username — ім’я вашого облікового запису на віддаленому сервері (як ваш бейдж на віддаленій кухні)
@ — просто роздільник (символ «at» або «равлик»)
ip-address — адреса віддаленого сервера (як номер телефону кухні)

Реальний приклад може виглядати так:

ssh chef@192.168.1.100

Або з доменним іменем замість IP-адреси:

ssh chef@kitchen.example.com

Що відбувається під час підключення

1. Ви вводите: ssh chef@kitchen.example.com
2. SSH зв'язується з віддаленим сервером
3. Сервер запитує: "Хто ти? Доведи це."
4. Ви надаєте доказ (пароль або ключ — про це нижче)
5. Сервер каже: "Ласкаво просимо, шеф. Ось твій термінал."
6. Ваш prompt (запрошення) змінюється, показуючи ім'я віддаленого сервера
7. Кожна команда, яку ви вводите, тепер виконується на ВІДДАЛЕНОМУ сервері
8. Введіть "exit", щоб відключитися та повернутися до локального термінала

Ваше запрошення термінала (prompt) може змінитися з:

yourname@your-laptop ~ $

на:

chef@remote-server ~ $

Саме так ви розумієте, що підключені до іншої машини.

Паролі проти ключів SSH

Є два способи підтвердити свою особу віддаленому серверу:

Паролі

Простий спосіб. Сервер запитує пароль, ви його вводите.

ssh chef@kitchen.example.com
# Сервер запитує: chef@kitchen.example.com's password:
# Ви вводите пароль (він не відображатиметься на екрані — це нормально)

Паролі працюють, але мають проблеми:

Ви повинні вводити їх щоразу
Їх можна вгадати або вкрасти
Вони незручні для автоматизованих систем

Ключі SSH (кращий спосіб)

Подумайте про це: Паролі можна вгадати, вкрасти або виманити через фішинг. Що, якби замість того, щоб повідомляти серверу секретне слово, ви могли б довести свою особу за допомогою чогось, що належить тільки вам — як фізичний ключ, що підходить до певного замка? Це саме те, що роблять ключі SSH. Сервер ніколи не дізнається ваш «пароль» — він просто перевіряє, чи підходить ваш ключ.

Ключі SSH працюють за системою «замок і ключ»:

Ви маєте КЛЮЧ (приватний ключ) — зберігається на вашому комп'ютері, ніколи нікому не передається.
Сервер має ЗАМОК (відкритий ключ) — він знає, який ключ до нього підходить.

Під час підключення:
1. Ви пред'являєте свій ключ
2. Сервер перевіряє: "Чи підходить цей ключ до мого замка?"
3. Якщо так: "Заходьте!" (пароль не потрібен)
4. Якщо ні: "Доступ заборонено."

Це як мати фізичний ключ від дверей віддаленої кухні. Вам не потрібно нікому говорити пароль — ви просто відкриваєте двері.

Генерація ключів SSH (вам не потрібно робити це прямо зараз, просто знайте як):

ssh-keygen -t ed25519

Це створює два файли:

~/.ssh/id_ed25519 — Ваш приватний ключ (ключ). НІКОЛИ нікому його не передавайте.
~/.ssh/id_ed25519.pub — Ваш відкритий ключ (замок). Ви можете вільно ним ділитися.

Ви копіюєте відкритий ключ на сервер, і відтоді можете підключатися без пароля.

Подумайте про це так: Приватний ключ — це ключ від вашого будинку. Відкритий ключ — це копія замка на ваших дверях. Ви можете дати замок будь-кому і сказати: «постав це на свої двері». Тепер ваш ключ відкриває і їхні двері також. Але ніхто не може виготовити ключ, просто дивлячись на замок.

Поширені параметри SSH

Параметр	Що він робить	Приклад
`-p`	Підключитися через інший порт (за замовчуванням 22)	`ssh -p 2222 chef@server.com`
`-i`	Використати специфічний файл ключа	`ssh -i ~/.ssh/mykey chef@server.com`
`-v`	Режим детального виводу (показує, що відбувається — корисно для відладки)	`ssh -v chef@server.com`

Міні-вправа: Складіть команду

Зупиніться та подумайте: Напишіть точну команду SSH для підключення користувача admin на сервері 10.0.0.5, використовуючи порт 2222 та файл ключа ~/.ssh/work_key.

Відповідь

ssh -p 2222 -i ~/.ssh/work_key admin@10.0.0.5

(Примітка: порядок -p та -i не має значення, головне, щоб вони йшли перед частиною user@host).

Життєвий цикл з’єднання

Ваш комп'ютер                          Віддалений сервер
    |                                       |
    |  --- ssh chef@server.com ---------->  |
    |                                       |  "Запит на з'єднання отримано"
    |  <--- "Підтвердь свою особу" --------  |
    |                                       |
    |  --- надсилає ключ/пароль ----------->  |
    |                                       |  "Особу підтверджено"
    |  <--- "Вітаємо! Ось ваша оболонка" --  |
    |                                       |
    |  --- ls, pwd, nano тощо ---------->  |  (команди виконуються ТУТ, на сервері)
    |  <--- [ ПРОПУСК 1: Передбачте, що тут повертається ] --- |
    |                                       |
    |  --- [ ПРОПУСК 2: Як відключитися? ] ------> |
    |                                       |  "До побачення"
    |  (повернення до локального термінала) |

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

Відповіді
ПРОПУСК 1: Сервер надсилає назад результати/вивід ваших команд.
ПРОПУСК 2: Ви вводите exit, щоб відключитися та повернутися до локального термінала.

Зупиніться та подумайте: Якщо ви зайшли через SSH на сервер і запустили rm -rf /home/yourname/projects, що станеться? Це видалить файли на вашому ноутбуці чи на сервері? Це не підступне запитання — але це саме та помилка, яка спричиняла реальні аварії. Завжди перевіряйте hostname після підключення, щоб переконатися, що ви на тій машині, на якій думаєте.

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

Чому це важливо для Kubernetes

Kubernetes працює на серверах — зазвичай на багатьох. Типовий кластер Kubernetes може мати:

3 сервери для «control plane» (офіс управління рестораном)
10-100+ серверів як «worker nodes» (кухні, які безпосередньо готують їжу)

Ви будете використовувати SSH для підключення до цих серверів, пошуку несправностей, перевірки логів та керування конфігураціями. Команди, які ви вивчили в попередніх модулях — ls, cd, nano, cat — працюють на цих віддалених серверах точно так само.

Чи знали ви?

SSH стандартизовано як протокол захищеного віддаленого доступу. RFC 4251 визначає SSH як протокол для безпечного віддаленого входу та інших захищених мережевих служб через незахищену мережу. Це головна причина, чому він замінив старі інструменти віддаленого входу, такі як telnet.
Порт 22 — це стандартний порт для SSH, призначений IANA. Ось чому в багатьох прикладах використовується 22, якщо адміністратор навмисно його не змінив.
SSH — це універсальний інструмент для операцій. OpenSSH описує себе як програмне забезпечення для віддаленого входу та віддаленого виконання команд, тому ви побачите SSH на хмарних віртуальних машинах, внутрішніх серверах Linux, лабораторних машинах тощо.

Посилання: RFC 4251, RFC 4250 та документація OpenSSH.

Типові помилки

Помилка	Чому це проблема	Що робити замість цього
Передача приватного ключа	Будь-хто з вашим приватним ключем може отримати доступ до ваших серверів	Ніколи не діліться `id_ed25519` (файлом БЕЗ `.pub`). Діліться тільки файлом `.pub`
Забули, що ви на віддаленому сервері	Ви можете видалити файли або змінити налаштування не на тій машині	Завжди перевіряйте своє запрошення (prompt) і використовуйте `hostname`, щоб переконатися, на якій ви машині
Введення пароля не в те поле	SSH приховує введення пароля (ні крапок, ні зірочок). Люди думають, що він зламався, і пишуть його там, де він видимий	Коли SSH просить пароль, просто введіть його «наосліп» і натисніть Enter. Він ОТРИМУЄ ваші натискання клавіш
Не відключилися після завершення роботи	Залишення відкритих сесій SSH витрачає ресурси сервера і може бути ризиком для безпеки	Введіть `exit` або натисніть `Ctrl + D`, коли закінчите
Паніка при розриві з’єднання	Переривання мережі трапляються — це не означає, що щось зламалося	Просто підключіться знову тією ж командою SSH. Ваші файли на сервері нікуди не зникли

Контрольні запитання

Ви зайшли через SSH на сервер і запустили hostname — він показує назву вашого ноутбука. Що сталося?

Відповідь
Насправді ви не підключені до віддаленого сервера! Або з'єднання SSH не вдалося, або ви вже ввели `exit` і повернулися до локального термінала, не помітивши цього. Оскільки ви запустили `hostname` і побачили назву свого ноутбука, ви підтвердили, що ваші команди наразі виконуються локально, а не віддалено. Завжди перевіряйте своє запрошення та використовуйте `hostname`, щоб перевірити середовище та уникнути запуску руйнівних команд на нетій машині.
Колега просить вас надіслати йому ваш приватний ключ SSH, щоб він міг швидко зайти на сервер, яким ви обоє керуєте. Що ви скажете і чому?

Відповідь
Ви повинні відповісти «категорично ні». Ваш приватний ключ (наприклад, `id_ed25519`) — це ваш особистий «ключ від будинку», і ним ніколи не можна ділитися ні з ким, навіть з колегами. Якщо їм потрібен доступ до сервера, вони мають згенерувати власну пару ключів SSH і дати вам свій *відкритий* ключ (`id_ed25519.pub`), який ви потім додасте до списку дозволених на сервері. Це гарантує безпеку доступу кожного та дозволяє пізніше відкликати їхній доступ, не змінюючи власний ключ.
Ви налаштовуєте новий сервер розгортання (deployment server), і йому потрібно безпечно підключатися до сервера бази даних без пароля. Який ключ (відкритий чи приватний) ви розміщуєте на сервері бази даних і чому?

Відповідь
Ви розміщуєте відкритий ключ на сервері бази даних (він виступає як замок). Приватний ключ залишається на сервері розгортання (він виступає як ключ). Сервер перевіряє, чи приватний ключ машини, що підключається, відповідає збереженому відкритому ключу. Знання відкритого ключа нікому не допоможе видати себе за сервер розгортання, що забезпечує безпеку з'єднання.
Коли ви підключені до віддаленого сервера через SSH і вводите touch recipe.txt, де створюється файл?

Відповідь
На віддаленому сервері, а не на вашій локальній машині. Коли ви підключені через SSH, кожна команда, яку ви вводите, виконується на віддаленому сервері. Файл `recipe.txt` створюється у файловій системі сервера. Ваша локальна машина не отримує копію. Щоб перевірити, на якій ви машині, подивіться на запрошення термінала або введіть `hostname`.
Просунутий рівень: Вам потрібно автоматизувати розгортання з CI-сервера (Continuous Integration) на 50 робочих машин. Ви б використали автентифікацію за паролем чи за ключами? Поясніть свою логіку.

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

Практична вправа: SSH до Localhost

Ми потренуємося працювати з SSH, підключившись до вашого власного комп’ютера. Це може здатися безглуздим («Я і так уже тут!»), але це демонструє, як саме працює SSH — і цей досвід ідентичний підключенню до справжнього віддаленого сервера.

На macOS:

Спочатку увімкніть віддалений вхід (SSH), якщо він ще не увімкнений:

Відкрийте System Settings (Системні параметри)
Перейдіть у General > Sharing (Загальні > Спільний доступ)
Увімкніть Remote Login (Віддалений вхід)

Тепер у вашому терміналі:

ssh localhost

Ви побачите щось на кшталт:

The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:AbCdEf123456...
Are you sure you want to continue connecting (yes/no)?

Введіть yes і натисніть Enter. (Це з’являється лише під час першого підключення до нового сервера. Комп’ютер каже: «Я ніколи раніше не спілкувався з цим сервером — ти впевнений, що він справжній?»)

Введіть пароль вашого Mac, коли з’явиться запит.

Тепер ви «підключені». Спробуйте:

hostname
whoami
pwd
ls
echo "Hello from SSH!"

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

Щоб відключитися:

exit

На Linux:

На Linux налаштування сервера SSH за замовчуванням залежать від дистрибутива. Наприклад, багато десктопних версій не мають SSH-сервера, поки ви його не встановите. На системах Debian або Ubuntu, де OpenSSH Server відсутній, ви можете встановити та запустити його так:

sudo apt update
sudo apt install -y openssh-server
sudo systemctl enable --now ssh

Потім:

ssh localhost

Виконайте ті самі кроки, що і для macOS вище.

На Windows:

SSH до localhost на Windows складніший у налаштуванні. Замість цього просто потренуйтеся в синтаксисі команди:

# Ось як виглядало б підключення до реального сервера:
ssh yourname@192.168.1.100

# Ви б побачили:
yourname@192.168.1.100's password:

# Після введення пароля:
yourname@remote-server:~$

# Тепер кожна команда виконується на віддаленому сервері.
# Введіть "exit", щоб відключитися.

Що сталося б зі справжнім сервером

Якби у вас був хмарний сервер (ви отримаєте його, коли почнете трек Kubernetes), досвід був би таким:

# Підключення до сервера в хмарі
ssh ubuntu@54.123.45.67

# Ви б побачили:
ubuntu@ip-54-123-45-67:~$

# Тепер ви всередині Linux-сервера в якомусь дата-центрі
# Кожна команда виконується там:
ls          # Показує файли на сервері
pwd         # Показує ваш шлях на сервері
nano        # Відкриває nano на сервері
cat /etc/os-release    # Показує операційну систему сервера

# Відключіться після завершення
exit

Це виглядало б, відчувалося і працювало б точно так само, як вправа з localhost. Єдина різниця — фізичне розташування комп’ютера.

Критерії успіху: Ви повинні запустити hostname у своєму терміналі перед підключенням через SSH і запам’ятати результат. Потім успішно відкрити SSH-з’єднання і знову запустити hostname після підключення. Якщо ви використовуєте ssh localhost, hostname зазвичай залишиться незмінним, оскільки ви підключаєтеся до тієї самої машини; доказом буде те, що ви встановили сесію SSH, виконали в ній команди та чисто відключилися. Якщо ви підключаєтеся до іншої машини, hostname має змінитися. У будь-якому випадку, запустіть принаймні одну іншу команду, щоб перевірити файлову систему, а потім правильно відключіться.

Наступний модуль

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

Ви щойно скористалися інструментом, яким щодня користуються досвідчені інженери. Ви на своєму місці.