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

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

Час на виконання: 25 хвилин

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

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

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

Діагностувати, чи виконується команда локально, чи на віддаленому сервері, перевіряючи hostname, whoami та pwd.
Налаштувати базове підключення SSH, використовуючи правильний синтаксис username@host, опціональний вибір порту та навмисне відключення.
Порівняти автентифікацію за паролем з автентифікацією за SSH-ключем та обрати безпечніший метод для доступу людей і автоматизованих систем.
Оцінити ризики доступу до сервера перед виконанням команд, які змінюють файли, логи, конфігурацію або стан сервісів.

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

Гіпотетичний сценарій: ви допомагаєте колезі дослідити Service, який працює на ноутбуці, але дає збій на машині з Linux, де його запускає решта команди. Колега надсилає вам ім’я хоста, обліковий запис користувача та повідомлення: «Зайди по SSH і перевір логи». Якщо слова local, remote, server, shell, key та prompt зливаються в одне ціле, ситуація стає стресовою ще до початку справжнього усунення несправностей.

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

Kubernetes робить цю основу ще важливішою, а не навпаки. Кластер Kubernetes 1.35 побудований із серверів, які називаються вузлами, і навіть коли kubectl стає вашим основним інтерфейсом кластера, вам усе одно потрібна ментальна модель того, що команда має розташування, користувача та радіус ураження. Цей модуль дає вам цю модель до того, як поверхня команд стане більшою.

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

Сервери — це комп’ютери з певною роботою

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

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

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

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

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

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

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

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

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

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

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

Локальний і віддалений стосуються того, де виконується робота

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

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

Коли ви відкриваєте термінал і вводите ls, оболонка на вашому власному комп’ютері виводить список файлів з вашого власного поточного каталогу. Коли ви підключаєтеся до сервера за допомогою SSH і потім вводите ls, оболонка на сервері виводить список файлів з поточного каталогу сервера. Літери на вашій клавіатурі є локальними, але виконання команди після входу є віддаленим.

Ось чому досвідчені інженери виробляють звичку перевіряти контекст перед дією. Запрошення може показувати користувача та хост, але запрошення можна налаштовувати, і іноді вони вводять в оману. Команди, такі як hostname, whoami та pwd, дають вам незалежні докази щодо машини, облікового запису та каталогу, якими ви зараз керуєте.

hostname
whoami
pwd

Ці три перевірки відповідають на три окремі запитання. hostname відповідає на запитання «яка машина виконує цю команду?». whoami відповідає на «який обліковий запис виконує цю команду?». pwd відповідає на «де у файловій системі я перебуваю?». Разом вони зменшують імовірність того, що ви застосуєте виправлення до свого ноутбука, вважаючи, що ви на сервері, або, що ще гірше, застосуєте руйнівну зміну до production, вважаючи, що ви у тренувальному середовищі.

Зупиніться та подумайте: ви відкриваєте термінал, одразу запускаєте hostname і бачите ім’я свого ноутбука. Потім ви запускаєте ssh admin@10.0.0.5, успішно проходите автентифікацію, знову запускаєте hostname і бачите інше ім’я. Яка машина тепер отримає команду touch practice.txt? Файл створюється на віддаленій машині, оскільки активна оболонка після входу через SSH належить цьому віддаленому хосту.

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

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

Редагування фотографії на робочому столі вашого ноутбука є локальним, оскільки програма та файл містяться на машині перед вами.
Використання SSH для перевірки логів на вебсервері в Лондоні є віддаленим, оскільки команда для логів виконується на цьому сервері.
Виконання pwd відразу після відкриття термінала є локальним, оскільки віддаленого сеансу ще не існує.
Введення ls після підключення через ssh admin@10.0.0.5 є віддаленим, оскільки оболонка тепер перебуває на 10.0.0.5.
Запит вашим браузером сторінки з Вікіпедії є віддаленим з точки зору браузера, оскільки сервер надсилає дані сторінки назад.

Сценарій вправи: ви документуєте процес Deployment і хочете, щоб перший рядок кожного сеансу усунення несправностей доводив контекст. Надійний ранбук не починається з «перезапустіть Service». Він починається з «підключіться до правильного хоста, запишіть hostname, запишіть whoami, запишіть pwd, потім огляньте Service». Цей порядок може здаватися повільним, але він захищає систему до того, як команди стануть потужними.

SSH відкриває безпечну оболонку на іншій машині

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

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

SSH має дві основні сторони. Клієнт SSH — це програма, яку ви запускаєте зі свого термінала, зазвичай має назву ssh. Сервер SSH — це Service, який прослуховує з’єднання на віддаленій машині; у системах Linux він зазвичай надається OpenSSH. Якщо віддалений Service SSH не встановлено, не запущено, заблоковано брандмауером або він прослуховує інший порт, ваш клієнт не відкриє сеанс.

Базова команда SSH залишає видимими важливі частини:

ssh username@ip-address

У цій формі ssh — це клієнтська програма, username — обліковий запис, який ви хочете отримати на віддаленому сервері, @ відокремлює обліковий запис від хоста, а ip-address — це мережеве розташування. Справжній приклад приватної мережі може виглядати так:

ssh chef@192.168.1.100

Хост також може бути ім’ям DNS замість числової адреси. Імена DNS простіше запам’ятовувати людям, і вони дозволяють командам інфраструктури змінювати базову адресу, не змушуючи кожного оператора запам’ятовувати нове число.

ssh chef@kitchen.example.com

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

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

Ваше запрошення може змінитися з такого, що виглядає локальним, на таке, що виглядає віддаленим. Ставтеся до цього як до корисної підказки, а не як до єдиного доказу. Запрошення — це текст, згенерований конфігурацією оболонки, тоді як hostname безпосередньо запитує операційну систему.

yourname@your-laptop ~ $

chef@remote-server ~ $

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

echo $USER
echo $HOME

Запустіть ті самі команди локально перед будь-яким підключенням SSH, щоб мати базовий орієнтир. Потім уявіть або перевірте ті самі команди після входу як інший віддалений користувач. Назви змінних ті самі, але їхні значення надходять із середовища, де оболонка фактично виконується.

echo $USER
echo $HOME

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

Типовий порт SSH зазвичай 22, але реальні системи іноді вибирають інший порт через мережеву політику, налаштування лабораторії, переспрямування портів або свідоме рішення адміністратора. Ви вказуєте цей порт за допомогою -p, а конкретний файл закритого ключа — за допомогою -i. Докладний режим, -v, виводить деталі підключення, які є корисними, коли автентифікація або доступність мережі не вдаються.

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

Перш ніж запустити це, який вивід ви очікуєте від докладного режиму? Ви маєте очікувати більше діагностичного тексту перед тим, як вхід буде успішним або невдалим, а не інший тип оболонки. Докладний вивід призначений для пояснення, а не для зміни віддаленої машини.

ssh -v chef@server.com

Опції можна комбінувати, коли сервер використовує нестандартний порт, і ви повинні використовувати певний ключ. Порядок -p та -i не має значення, якщо вони з’являються перед ціллю user@host.

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

Паролі, ключі SSH та довіра до хоста

Автентифікація — це етап, на якому сервер вирішує, чи дозволено вам стати вказаним віддаленим користувачем. Найпростіший метод — це пароль: сервер запитує пароль від облікового запису, ви вводите його, і сервер його перевіряє. Паролі звичні, але звичність — це не те саме, що експлуатаційна безпека.

ssh chef@kitchen.example.com
# Server asks: chef@kitchen.example.com's password:
# You type your password (it won't show on screen -- that's normal)

SSH навмисно приховує введення пароля. Відсутність крапок, зірочок або символів, що рухаються, не є помилкою; це заважає комусь поруч дізнатися довжину пароля. Правильна реакція — обережно ввести пароль і натиснути Enter, а не вставляти його у вікно чату, командний рядок чи видиму нотатку через те, що вам здається, ніби запрошення зависло.

Паролі мають три практичні слабкі місця в роботі з серверами. Люди використовують їх повторно, зловмисники виманюють їх через фішинг, а автоматизація погано з ними справляється. Скрипт розгортання, який чекає, поки хтось введе пароль, не є автоматизацією, тоді як скрипт розгортання, що зберігає багаторазовий пароль у відкритому тексті, створює нову проблему керування секретами.

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

You have a KEY (private key) -- kept on your computer, never shared.
The server has a LOCK (public key) -- it knows what key fits.

When you connect:
1. You present your key
2. The server checks: "Does this key fit my lock?"
3. If yes: "Come in!" (no password needed)
4. If no: "Access denied."

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

Створення ключа Ed25519 зазвичай виконується за допомогою ssh-keygen. Вам не потрібно генерувати новий ключ лише для того, щоб прочитати цей модуль, але ви повинні розпізнавати цю команду та стандартні імена файлів, які вона створює. Ed25519 широко рекомендується для сучасного використання ключів SSH, оскільки він компактний, швидкий і підтримується поточними випусками OpenSSH.

ssh-keygen -t ed25519

Ця команда зазвичай створює два файли в каталозі .ssh вашої домашньої директорії. ~/.ssh/id_ed25519 — це приватний ключ, і він має залишатися приватним. ~/.ssh/id_ed25519.pub — це публічний ключ, який можна скопіювати до сервісів на зразок GitHub або у файл authorized_keys сервера, коли цей сервер повинен прийняти ваш вхід.

~/.ssh/id_ed25519      private key, kept on your computer
~/.ssh/id_ed25519.pub  public key, copied to systems that should trust you

На багатьох серверах Linux публічні ключі, дозволені для облікового запису, містяться у ~/.ssh/authorized_keys для цього облікового запису. Цей файл також не має ніякої магії; це список, який сервер SSH перевіряє під час автентифікації. Якщо ваш публічний ключ присутній, а дозволи файлу дозволяють службі SSH безпечно його прочитати, ваш відповідний приватний ключ зможе підтвердити вашу особу.

remote user home
└── .ssh
    └── authorized_keys   accepts matching private keys for this account

Довіра до хоста — це поняття, окреме від автентифікації користувача. Коли ви вперше підключаєтеся до нового хоста, SSH може попередити, що справжність хоста не встановлено, і показати відбиток (fingerprint). Це клієнт запитує: “Чи справді я спілкуюся з тим сервером, з яким думаю, що спілкуюся?”, а не сервер запитує, хто ви.

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)?

Для локального тренувального підключення до localhost прийняття цього запиту є цілком логічним, оскільки хостом є ваша власна машина. Для робочого сервера (production server) ви маєте перевірити відбиток через надійне джерело, наприклад, метадані хмарної консолі, командний runbook або значення, надане адміністратором. Сліпе прийняття змінених ключів хоста формує саме ту звичку, якій SSH намагається запобігти.

Який підхід ви б обрали в цій ситуації і чому: спільний пароль для п’ятьох учасників команди чи п’ять окремих пар ключів SSH із п’ятьма окремими публічними ключами на сервері? Підхід з окремими ключами кращий, оскільки доступ кожній людині можна надавати, перевіряти та скасовувати незалежно. Спільні облікові дані ускладнюють процес відкликання доступу та забезпечення підзвітності.

Життєвий цикл віддаленого сеансу

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

Your computer                          Remote server
    |                                       |
    |  --- ssh chef@server.com ---------->  |
    |                                       |  "Connection request received"
    |  <--- "Prove your identity" --------  |
    |                                       |
    |  --- sends key/password ----------->  |
    |                                       |  "Identity confirmed"
    |  <--- "Welcome! Here's a shell" ----  |
    |                                       |
    |  --- ls, pwd, nano, etc. --------->  |  (commands run HERE, on the server)
    |  <--- [ BLANK 1: Predict what happens here ] --- |
    |                                       |
    |  --- [ BLANK 2: How do you disconnect? ] ------> |
    |                                       |  "Goodbye"
    |  (back to local terminal)             |

Перший пропуск — це вивід команди, оскільки сервер надсилає назад результат команди, яку ви виконали віддалено. Другий пропуск — це exit, тому що ця команда закриває віддалену оболонку і повертає вас до вашого локального термінала. Ctrl + D часто робить те саме, оскільки надсилає сигнал завершення вводу в оболонку, але exit є явним і зручним для читання в навчальних прикладах.

Під час робочої середини сеансу кожна звичайна команда термінала, яку ви вивчили, зберігає своє написання, але змінює свою ціль. ls показує список віддалених файлів, pwd виводить віддалену директорію, nano редагує віддалений файл, а cat /etc/os-release зчитує інформацію про віддалену операційну систему. Видиме вікно термінала не перемістилося, але оболонка перемістилася.

ls
pwd
nano notes.txt
cat /etc/os-release

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

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

hostname
whoami
pwd
date

Команда date додана, оскільки час має значення під час усунення несправностей. Якщо журнали (logs) ведуться за UTC, але годинник вашого ноутбука показує місцевий час, ви можете шукати інформацію не в тому часовому вікні. Вивід дати також підтверджує, що системний годинник віддаленої машини не має серйозних розбіжностей, що може вплинути на сертифікати, автентифікацію, заплановані завдання (scheduled jobs) та порядок журналів.

Збої з’єднання також є частиною життєвого циклу. “Connection timed out” часто вказує на проблеми з маршрутизацією, брандмауером (firewall), вимкненим хостом або неправильною адресою. “Connection refused” зазвичай означає, що хост відповів, але жодна служба SSH не прослуховує цю адресу та порт. “Permission denied”, як правило, означає, що ви дісталися служби SSH, але автентифікація не вдалася.

Симптом	Ймовірний рівень	Перша перевірка для початківця
Connection timed out	Мережевий шлях або firewall	Перевірте хост, мережу, VPN та правила групи безпеки
Connection refused	Служба SSH або порт	Перевірте, чи прослуховує сервер очікуваний порт
Permission denied	Автентифікація	Перевірте ім’я користувача, файл ключа, пароль та доступ до облікового запису
Host key warning changed	Ідентичність хоста	Зупиніться та перевірте, чи був сервер перебудований або перехоплений

Сценарій вправи: вам сказано підключитися як ubuntu, але ви тричі намагаєтеся використати admin і отримуєте повідомлення Permission denied. Мережа може бути в порядку. Сервер може працювати нормально. Помилкою може бути просто ім’я облікового запису, і рішенням буде використання імені користувача, призначеного образом системи або адміністратором.

Практика SSH без хмарного сервера

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

Перед підключенням зафіксуйте свій локальний контекст. Це дасть вам з чим порівнювати після входу та потренує м’язову пам’ять, яку ви пізніше будете використовувати на хмарних серверах та вузлах Kubernetes. Якщо ви використовуєте ssh localhost, ім’я хоста може бути однаковим до і після, оскільки обидві сторони є тією самою машиною, тому підтвердженням є встановлення сеансу та процес автентифікації, а не інше ім’я хоста.

hostname
whoami
pwd

На macOS вам може знадобитися увімкнути Віддалений вхід (Remote Login) перед тим, як сервер SSH почне приймати локальні підключення. Відкрийте Системні параметри (System Settings), перейдіть до Загальні (General), потім до Спільний доступ (Sharing) і увімкніть Віддалений вхід. Після цього вигляд команди буде таким самим, як і для сервера в іншому місці.

ssh localhost

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

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)?

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

hostname
whoami
pwd
ls
echo "Hello from SSH!"

Після завершення роботи виконайте чисте відключення. Ваше запрошення має повернутися до локальної оболонки після виходу з віддаленої. Якщо ви не впевнені, чи повернулися ви назад, виконайте hostname ще раз і порівняйте результат із вашими записами.

exit

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

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

Після цього перевірте той самий локальний процес підключення. Якщо воно завершиться невдало, прочитайте текст помилки замість того, щоб сліпо повторювати спроби. Відсутня служба, заблокований порт або неправильне ім’я облікового запису викликають інші симптоми, ніж неправильний пароль.

ssh localhost

На Windows точне налаштування localhost залежить від того, чи встановлено та запущено додатковий компонент OpenSSH Server. Для цього модуля початкового рівня цілком прийнятно практикуватися в читанні команд без зміни служб Windows. Важлива частина полягає в тому, щоб розпізнати форму справжнього з’єднання та запрошення (prompt), яке з’являється після успішного входу.

# This is what connecting to a real server would look like:
ssh yourname@192.168.1.100

# You would see:
yourname@192.168.1.100's password:

# After entering the password:
yourname@remote-server:~$

# Now every command runs on the remote server.
# Type "exit" to disconnect.

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

# Connect to a server in the cloud
ssh ubuntu@54.123.45.67

# You'd see:
ubuntu@ip-54-123-45-67:~$

# Now you're inside a Linux server in a data center somewhere
# Every command runs there:
ls          # Shows files on the server
pwd         # Shows your path on the server
nano        # Opens nano on the server
cat /etc/os-release    # Shows the server's operating system

# Disconnect when done
exit

Kubernetes не скасовує ці знання. У багатьох керованих кластерах ви рідко підключаєтеся по SSH до вузлів, і це зазвичай добре, оскільки API кластера має бути стандартною поверхнею керування. У навчальних лабораторіях, кластерах bare-metal, під час екстреної діагностики та в деяких середовищах, якими керують самостійно, SSH все ще з’являється, і та сама дисципліна розрізнення локального та віддаленого захищає вас від неправильного розуміння того, якою машиною ви керуєте.

Як мислення SSH переноситься на Kubernetes

Kubernetes запроваджує нові іменники, але не скасовує старі. Вузол (node) досі є сервером, процес досі десь виконується, шлях до файлу досі належить конкретній машині чи контейнеру (container), а оператору досі потрібно знати ціль перед виконанням дії. Різниця полягає в тому, що Kubernetes додає шар API, який може розподіляти роботу між багатьма серверами, тому ціль може вибиратися опосередковано, а не через відкриття оболонки на одному хості.

У Kubernetes 1.35 ви зазвичай будете інспектувати ресурси кластера (cluster) за допомогою kubectl, а не здійснювати вхід на кожен вузол (node). Це звичка вищого рівня, і вона є правильною поведінкою за замовчуванням для більшості питань щодо робочих навантажень. Тим не менш, ментальна модель SSH допомагає, оскільки kubectl має власну версію локального й віддаленого: команда виконується локально, запит до API надсилається до кластера, а ефект відбувається на ресурсах, якими керують віддалені сервери.

Подумайте про ланцюжок від вашої клавіатури до робочого навантаження. Ваш термінал надсилає команду до локальної програми. Ця програма надсилає автентифікований запит до сервера API Kubernetes. Площина управління (control plane) зберігає або зчитує бажаний стан, а робочі вузли (worker nodes) запускають контейнери (containers), які задовольняють цей стан. Якщо ви розумієте, де виконується кожна частина, ви з меншою ймовірністю будете звинувачувати свій ноутбук у проблемі з вузлом, або звинувачувати вузол у проблемі з локальною конфігурацією.

Така сама звичка перевіряти контекст стає ще конкретнішою згодом. Працюючи з SSH, ви запитуєте: «Який хост, який користувач, яка директорія?». Працюючи з Kubernetes, ви запитуєте: «Який кластер, який простір імен (namespace), який ресурс, який контейнер?». Звичка залишається ідентичною, хоча команди відрізняються. Спочатку ви підтверджуєте ціль, оскільки правильна команда, спрямована на неправильну ціль, — це все ще погана операція.

Наприклад, майбутній процес діагностики несправностей може починатися з kubectl get pods, щоб ідентифікувати проблемне робоче навантаження, потім kubectl logs, щоб прочитати вивід його контейнера, і kubectl describe node, щоб дослідити вузол, на якому його розміщено. Більшість цієї роботи не повинна вимагати SSH. Якщо сам вузол має проблему з диском, мережею або системною службою, яку не пояснює API кластера, оператор може тоді відкрити SSH-сесію на цей конкретний вузол і використати ті ж самі перевірки контексту з цього модуля.

Важливий урок полягає не в тому, щоб «підключатися по SSH до всього». Важливий урок — «знати, яку поверхню управління ви використовуєте». SSH керує оболонкою машини. kubectl керує ресурсами Kubernetes через API Kubernetes. Хмарна консоль керує ресурсами провайдера. Змішування цих поверхонь без їхнього чіткого найменування призводить до плутанини, оскільки кожна з них має різні дозволи, журнали аудиту, типи збоїв і шляхи відновлення.

Сценарій вправи: Pod зазнає збою, оскільки не може виконати запис на змонтований том, і учень негайно хоче підключитися по SSH до робочого вузла. Кращим першим кроком є інспектування подій Pod-а, конфігурації тому, простору імен і класу сховища (storage class) через API Kubernetes. Використання SSH стає доцільним лише тоді, коли докази вказують на проблему на рівні вузла, таку як переповнений диск, зламане монтування або збій системної служби, які не вдається вирішити інструментам вищого рівня.

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

Зручний для новачків спосіб тримати це під контролем — описувати кожну дію в одному реченні перед її виконанням. «Я запускаю локальну команду, яка відкриває віддалену оболонку на хості x під користувачем y». «Я запускаю локальну команду, яка запитує API Kubernetes про Pod-и в просторі імен z». Якщо це речення не виходить сформулювати чітко, зупиніться, поки ціль і поверхня управління не стануть зрозумілими.

Уважне читання запитів оболонки, шляхів і виводу

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

Почніть із запиту оболонки (prompt), але не зупиняйтеся на цьому. Запит, такий як ubuntu@ip-10-0-1-25:~$, підказує користувача, хост і директорію, проте він усе ще є умовністю, створеною конфігурацією оболонки. Вагоміші докази надходять від команд, мета яких — напряму запитати систему. Саме тому цей модуль повторює hostname, whoami і pwd, доки вони не стануть звичними.

Шляхи вимагають такої ж обережності. Шлях /home/admin/app на вашому ноутбуці та /home/admin/app на сервері можуть мати ідентичне написання та зовсім різний вміст. Текст шляху сам по собі не ідентифікує машину. Вам потрібен контекст хоста і контекст поточної сесії до того, як шлях набуде сенсу.

Вивід також може містити підказки щодо привілеїв. Якщо whoami виводить root, ваші команди можуть мати широкі повноваження на віддаленій машині, і слід бути більш обережними. Якщо виведено звичайний обліковий запис, такий як ubuntu, деякі команди можуть потребувати sudo, а деякі файли можуть бути навмисно недоступними. Жоден з результатів не є автоматично добрим чи поганим; він каже вам, яку саме владу має поточна оболонка.

Таке саме уважне читання допомагає з паролями та ключами. Якщо SSH каже Permission denied (publickey), сервер може взагалі не приймати вхід за паролем, і багаторазове введення пароля вашого звичайного облікового запису не допоможе. Якщо він каже Permission denied, please try again, автентифікація за паролем може бути дозволена, але значення є неправильним. Якщо справа ніколи не доходить до повідомлення про автентифікацію, можливо, ви натомість маєте справу з проблемою мережі чи служби.

Ставтеся до скопійованих команд як до чернеток, а не як до істини. Інструкція з експлуатації (runbook) може містити правильний шаблон, але неправильний хост для вашої ситуації, або товариш по команді може вставити команду зі staging-середовища, поки ви досліджуєте production. Перед тим як натиснути Enter, прочитайте ім’я користувача, хост, порт, шлях до ключа та контекст поточної оболонки як окремі фрагменти інформації.

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

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

Коли це застосовно, а коли ні

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

Не ставтеся до SSH як до єдиного способу керувати серверами. Управління конфігураціями, cloud-init, незмінні образи (immutable images), контролери Kubernetes, CI-конвеєри та робочі процеси GitOps існують, тому що повторювана ручна робота в оболонці погано масштабується. SSH — це гострий, корисний інструмент, але якщо кожна зміна в production вимагає, щоб людина вводила команди на багатьох хостах, цей процес з часом почне дрейфувати.

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

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

Відповідний антипатерн — це «сліпота до запиту оболонки» (prompt blindness). Сліпота до запиту виникає, коли термінал виглядає настільки знайомим, що ви перестаєте бачити, куди він вказує. Команди потрапляють у цю пастку, оскільки локальна і віддалена оболонки приймають однакову мову команд, і тому що продуктивні оператори діють швидко. Рішення — це не страх; рішення — це крихітний ритуал перевірки, який виживає в умовах швидкості.

Фреймворк для прийняття рішень

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

Потреба	Краща відправна точка	Компроміс
Дізнатися, як відчувається віддалена оболонка	`ssh localhost` або лабораторна ВМ	Безпечно і конкретно, але не повноцінна виробнича модель
Проінспектувати один сервер інтерактивно	SSH з перевірками контексту	Швидко і прямолінійно, але легко забути про документацію
Скопіювати відкритий ключ для дозволу входу	Процес налаштування облікового запису SSH	Просто для невеликих команд, але потребує відповідальності за володіння та дисципліни відкликання
Змінити багато серверів в однаковий спосіб	Автоматизація або управління конфігураціями	Більше налаштувань, але безпечніший огляд і повторюваність
Працювати з робочими навантаженнями Kubernetes	API Kubernetes через `kubectl`	Вищий рівень і можливість аудиту, але проблеми на рівні вузла досі можуть потребувати SSH

Рішення також залежить від того, чи є сервер «худобою» (cattle), чи «домашнім улюбленцем» (pet). Сервер-«улюбленець» з любов’ю модифікується на місці, що може бути зрозумілим у невеликій лабораторії, але небезпечно при масштабуванні. Сервер у стилі «худоби» можна замінити за допомогою конфігурації, і прямий SSH стає рятівним люком для діагностики, а не нормальним способом внесення змін.

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

Чи знали ви?

Архітектура SSH стандартизована в RFC 4251. Цей RFC описує SSH як безпечний віддалений вхід і інші безпечні мережеві служби поверх небезпечної мережі, що є саме тією ментальною моделлю для новачків, яка вам потрібна, перш ніж робота із серверами стане рутиною.
Порт 22 — це зареєстрований порт за замовчуванням для SSH. Реєстр імен служб IANA призначає ssh порту TCP 22, саме тому приклади й правила брандмауера часто згадують 22, якщо тільки адміністратор свідомо не обере інший порт.
OpenSSH вперше з’явився у 1999 році як частина проєкту OpenBSD. Він став найпоширенішою реалізацією SSH на Unix-подібних системах, оскільки надавав безплатний, практичний набір інструментів для віддаленого входу, віддаленого виконання команд і пов’язаних безпечних операцій.
Kubernetes 1.35 досі працює на серверах, що називаються вузлами (nodes). Навіть коли ви використовуєте API Kubernetes замість SSH для звичайного управління робочими навантаженнями, ідентичність вузлів, віддалене виконання та обережні перевірки контексту залишаються частиною словника операційної діяльності.

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

Помилка	Чому це трапляється	Як це виправити
Передача вашого закритого ключа іншим	Люди плутають закритий ключ із відкритим, оскільки обидва файли мають схожі назви	Ніколи не діліться файлом `id_ed25519`; надавайте лише `id_ed25519.pub` або інший файл відкритого ключа
Забування про те, що ви перебуваєте на віддаленому сервері	Вікно термінала виглядає так само після входу, тому оператор покладається на звичку	Виконайте `hostname`, `whoami` та `pwd` після підключення і перед тим, як будь-що змінювати
Введення пароля в неправильне місце	SSH приховує введення пароля, що змушує новачків думати, ніби запит оболонки не приймає натискання клавіш	Введіть пароль у запиті SSH, очікуйте, що символів не буде видно, і натисніть Enter
Використання неправильного імені віддаленого користувача	Образи хмарних провайдерів і лабораторні середовища часто використовують назви облікових записів, такі як `ubuntu`, `ec2-user` або `admin`	Прочитайте інструкції лабораторії або провайдера і підставте правильного користувача перед символом `@`
Ігнорування попереджень про ключ хоста	Люди сприймають попередження як прикрість, а не як перевірку ідентичності хоста	Перевірте відбиток через довірену документацію або в адміністратора перед його прийняттям
Залишення сесій відкритими після виконання завдання	Термінал залишається підключеним, оскільки ніщо не змушує користувача закривати оболонку	Введіть `exit` або натисніть `Ctrl + D`, потім переконайтеся, що ви повернулися до локального запиту оболонки
Автоматизація з паролями	Скрипт, який потребує від людини введення пароля, спочатку здається простим, але ламає автоматичну роботу без нагляду	Використовуйте автентифікацію на основі ключів з належним обробленням секретів і контролем доступу на рівні кожної системи
Паніка, коли з’єднання переривається	Переривання мережі відчувається як втрата даних, коли модель віддаленого/локального є новою	Підключіться заново, ще раз перевірте контекст і пам’ятайте, що віддалені файли залишаються на сервері

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

Запитання 1: Ви підключаєтеся до сервера через SSH, виконуєте `hostname`, і він показує ім'я вашого ноутбука. Що ви перевіряєте перед виконанням будь-яких інших команд?

Вам слід спочатку визначити, чи дійсно SSH-з’єднання було успішним, чи ви вже повернулися до вашої локальної оболонки. Локальне ім’я хоста після спроби віддаленого входу зазвичай означає, що з’єднання не вдалося, ви вийшли з нього не помітивши цього, або ж навмисно підключилися до localhost. Перевірте вивід команд над рядком запрошення, виконайте whoami та pwd, і перепідключайтеся лише після того, як дізнаєтеся, яка оболонка зараз активна. Безпечна реакція — це зупинитися та перевірити контекст, а не продовжувати виконувати команди сервера.

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

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

Запитання 3: Сервер розгортання повинен підключитися до сервера бази даних без введення пароля людиною. Яка частина пари ключів належить серверу бази даних?

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

Запитання 4: Ви підключені за допомогою `ssh admin@10.0.0.5` і виконуєте `touch recipe.txt`. Де створюється файл і як ви можете це довести?

Файл створюється на віддаленій машині за адресою 10.0.0.5, у поточному каталозі віддаленої оболонки. Ви можете довести контекст, виконавши hostname, whoami та pwd до або після команди, а потім переглянути вміст каталогу за допомогою ls. Ваші клавіатура та вікно термінала є локальними, але оболонка, що отримує команди, — віддалена. Якщо ви введете exit, а потім виконаєте ls локально, ви дивитиметеся на інший контекст файлової системи.

Запитання 5: Ваша команда SSH одразу повертає повідомлення "Connection refused", але ім'я хоста правильне. Який рівень ви досліджуєте першим?

Повідомлення “Connection refused” зазвичай означає, що хост відповів, але ніщо не прийняло з’єднання на цільовому порту. Перевірте, чи встановлено SSH-сервер, чи він працює і чи прослуховує використаний вами порт. Також перевірте, чи не використовує сервер нестандартний порт, який вимагає ssh -p. Це відрізняється від повідомлення “Permission denied”, яке означає, що ви досягли сервісу SSH, але не пройшли автентифікацію.

Запитання 6: Вам потрібно запустити однакове оновлення пакетів на багатьох серверах. Чому ручний SSH може бути хибним основним методом?

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

Запитання 7: Після підключення до нового виробничого хоста SSH попереджає, що ключ хоста змінився. Якою має бути обережна реакція?

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

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

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

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

Зафіксуйте свій локальний контекст, виконавши hostname, whoami та pwd перед будь-якою командою SSH.
Відкрийте SSH-з’єднання з localhost, приймаючи запит хоста при першому підключенні лише в тому випадку, якщо ви навмисно підключилися до власної машини.
Всередині SSH-сеансу виконайте hostname, whoami, pwd, ls та echo "Hello from SSH!".
Відключіться за допомогою exit, потім знову виконайте hostname, щоб підтвердити, що ви повернулися до локального рядка запрошення.
Напишіть одне речення, що пояснює, чи змінилося ім’я хоста, і чому такий результат є логічним для localhost.
Сформуйте, але не виконуйте команду, яка б підключила вас як admin до 10.0.0.5 на порт 2222 з файлом ключа ~/.ssh/work_key.

Вказівки до рішення

Ваш блок локального контексту має показувати машину, користувача та каталог до підключення. Команда SSH для localhost — це ssh localhost, хоча деякі системи можуть вимагати ім’я користувача, наприклад ssh yourname@localhost, залежно від налаштувань облікового запису. Всередині сеансу SSH вивід команд може виглядати дуже схожим, оскільки віддалена кінцева точка є тим самим фізичним комп’ютером, але автентифікація SSH і життєвий цикл оболонки все одно відбулися. Остаточна команда для віддаленого прикладу — ssh -p 2222 -i ~/.ssh/work_key admin@10.0.0.5.

Критерії успіху

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

Джерела

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

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