Автоматизація Zapier/IFTTT і вхід за SSH-ключем

Дві лінії одного уроку

Сьогодні ти прибираєш пароль зі свого входу на сервер і вперше пускаєш на нього подію, яку створив не ти, а зовнішній сервіс

Чого навчишся за цей урок

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

Хід уроку

Слова «SSH-ключ» і «тригер» поки нічого не означають. Розберемо їх по черзі. А «скоуп» ти вже знаєш із уроку 10. Сьогодні подивишся на нього з іншого боку — на екрані згоди чужого сервісу.

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

Обидві про одне й те саме. Чим ти доводиш, що це справді ти? І скільки прав віддаєш назовні?

Що ти зробиш за 120 хвилин

1. згенеруєш пару ed25519 у себе на комп'ютері;
2. покладеш публічну частину в ~/.ssh/authorized_keys на сервері;
3. виставиш права 700 на теку і 600 на файл;
4. зайдеш на сервер без пароля й побачиш свій вхід у журналі;
5. збереш сценарій «тригер → фільтр → дія» у Zapier або IFTTT;
6. напишеш api/hook.php, який ловить подію в ~/data/events.jsonl;
7. зробиш сторінку /events/ з часом останньої події.

Твій сервер уже атакують. Просто зараз

Не тому, що ти комусь цікавий. Тому що адресу не треба знати — її знаходять суцільним перебором діапазонів

Уяви людину, яка йде вулицею і смикає всі двері підряд. Не тому, що шукала саме твої. Просто якісь виявляться незамкненими.

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

Логіни в цих спробах завжди ті самі: root, admin, test, ubuntu, pi, user, oracle, postgres. Це стандартні акаунти, які на багатьох машинах справді існують.

Головне тут не кількість. Головне — що кожна з цих спроб перевіряє саме пароль.

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

Чому пароль програє ключу — чесно, з арифметикою

Не тому, що «пароль слабкий». Тому що в пароля чотири вроджені вади, і жодна не лікується довжиною

Порівняємо чесно. Припустимо, що бот встигає 10 спроб на секунду по одному серверу. Для нього це дуже щедро.

Насправді sshd за замовчуванням дає лише 6 спроб на одне з'єднання — параметр MaxAuthTries 6. Далі боту доводиться підключатися наново, і це коштує часу.

Як працює пара ключів — без магії

Один файл лишається в тебе назавжди, другий можна друкувати на футболці. Уся конструкція тримається саме на цій асиметрії

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

Команда ssh-keygen робить одразу два файли, і вони математично пов'язані. З приватного можна порахувати публічний. З публічного приватний — ні, і саме на цьому все стоїть.

id_ed25519

приватний. Ніколи не залишає твій комп'ютер. Не копіюється, не пересилається, не заливається по FTP, не кладеться в репозиторій.

id_ed25519.pub

публічний. Один рядок тексту. Його можна віддавати, публікувати й розсилати — з нього нічого не дістати.

Що відбувається під час входу

Спочатку клієнт і сервер домовляються, як шифрувати саме з'єднання. Цей обмін зветься протоколом Діффі — Гелмана.

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

1. клієнт каже: «я petro, хочу зайти ось цим публічним ключем»;
2. сервер шукає цей рядок у ~/.ssh/authorized_keys. Немає — розмова закінчена;
3. є — сервер каже: «добре, підпиши ось це» (у «це» входить ідентифікатор сеансу);
4. клієнт підписує приватним ключем і надсилає підпис;
5. сервер перевіряє підпис публічним ключем зі свого файлу. Збігається — пускає.

Генеруємо пару: одна команда і три рішення

Команда коротка, але кожен її параметр — це рішення, яке потім не переграєш

-t ed25519

тип ключа. Сучасний стандарт: коротший за RSA, швидший і без вибору довжини — там її просто немає, вона фіксована. Якщо старий сервер його не приймає, запасний варіант — -t rsa -b 4096.

-C "…"

коментар у кінці публічного ключа. Він ні на що не впливає технічно, але саме за ним ти через рік зрозумієш, який рядок у authorized_keys звідки. Пиши «хто@яка машина + місяць».

passphrase

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

Як відрізнити публічний файл від приватного за один погляд

Кладемо публічний ключ на сервер і виставляємо права

Файл ~/.ssh/authorized_keys — це просто список рядків. Один рядок — один дозволений ключ

Найпростіший спосіб — команда ssh-copy-id. Вона сама створить теку, сама допише рядок у кінець файлу і сама поставить права. Пароль ти вводиш тут востаннє.

Другий рядок тут важливіший за перший. Ключ -o PasswordAuthentication=no забороняє клієнту питати пароль.

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

$pub = Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub" -Raw
ssh ТВІЙ-ЛОГІН@91.219.61.4 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && echo '$pub' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Тут && усередині лапок виконує вже віддалений bash на сервері, а не PowerShell — тому воно працює. Пам'ятай різницю: у самому PowerShell 5.1 && між командами не існує, там пишуть команда; if ($?) { наступна }.

Права: що справді ламається, а що ні

Навколо прав на ~/.ssh ходить багато неточностей. Розберемо чесно, бо ти це перевіриш і побачиш розбіжність.

Симулятор входу: що сервер перевіряє на кожному кроці

Обери спосіб входу і ситуацію. Сторінка покаже рукостискання крок за кроком і те, що після нього залишиться в auth.log

Значення maxretry = 5, findtime = 10m і bantime = 10m у лічильнику — це значення з поставки fail2ban (секція [DEFAULT] у jail.conf). На реальному сервері їх міняють у jail.local.

Читаємо auth.log: анатомія рядка

Один рядок журналу відповідає на п'ять питань одразу: коли, хто, звідки, чим і чи пустили

Найчастіші рядки й що вони означають

Тренажер: розбери фрагмент журналу

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

Ключ витік. Що робити і чому «змінити пароль» не допоможе

Пароль — це те, що ти знаєш. Ключ — це файл. Файл не міняють, файл відкликають

Коли витікає пароль, ти вводиш новий, і старий перестає діяти в ту саму секунду. Бо пароль на сервері один, і перевіряється він за одним записом.

Із ключем усе інакше. Сервер пускає кожен рядок з authorized_keys. Поки твій втрачений рядок там лежить, він працює. Зміна пароля на це не впливає ніяк.

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

З фразою зловмисникові доведеться її підбирати. Формат ключа навмисно робить кожну спробу повільною. Ключ ми однаково міняємо — просто без паніки.

Автоматизація: тригер → фільтр → дія

Zapier і IFTTT не вміють нічого, чого не вміє звичайний скрипт. Вони вміють інше: чекати подію цілодобово замість тебе

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

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

Третя — дія: що зробити з подіями, які пройшли фільтр. Наприклад, надіслати їх на твій сервер.

Квоти: чому сценарій замовкає 12 числа

Безкоштовні тарифи не «повільніші» — вони закінчуються. І закінчуються тихо: сценарій просто перестає спрацьовувати.

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

function onFormSubmit(e) {
  var v = e.namedValues;

  // 2. Фільтр: пропускаємо далі лише свій клас
  if (String(v['Клас']) !== '10А') return;

  // 3. Дія: POST на власний приймач
  UrlFetchApp.fetch('http://91.219.61.4/s/ТВІЙ-ЛОГІН/api/hook.php', {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify({
      source: 'apps-script',
      type: 'form',
      title: String(v['Назва гуртка'])
    }),
    muteHttpExceptions: true
  });
}

Тарифи змінюються — таблицю вище перевірено у вересні 2026 за сторінками zapier.com/pricing і ifttt.com/plans. Перед уроком відкрий їх сам: якщо число інше, вір сайту, а не сторінці.

Екран згоди: скільки прав ти щойно віддав

Коли ти тиснеш «Дозволити», зовнішній сервіс отримує токен і зберігає його в себе. Далі все залежить від того, що цим токеном можна

На екрані згоди написано, що саме сервіс проситиме робити. Цей перелік дозволених дій ти вже зустрічав на уроці 10 — це скоуп (scope). Там ти сам звужував його до read-only. Тут скоуп просить чужий сервіс, а звужуєш його все одно ти.

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

Правило просте: сервіс не повинен мати більше прав, ніж потрібно його сценарію. Це той самий принцип найменших привілеїв, що й на уроці 10.

Різниця лише в тому, кого він тепер стосується. Там ішлося про твій власний скрипт, тут — про чужу компанію на іншому кінці світу.

Три причини, чому «дам повний доступ, так простіше» — погана ідея

1. Токен лежить не в тебе. Він у базі сервісу. Зламають сервіс — зламають і твій Диск, хоча ти нічого не робив;
2. Ти не побачиш зловживання. Сервіс, який має право читати все, читає все тихо: ніяких листів «ваш файл відкрито»;
3. Дозвіл не має терміну. Ти забудеш про сценарій через місяць, а токен житиме, поки ти вручну не відкличеш його в налаштуваннях акаунта.

Свій приймач: hook.php і журнал подій

Зовнішній сервіс присилає JSON. Твоє завдання — прийняти, обрізати, записати рядок і не впасти на будь-якому смітті

Формат журналу — JSONL: один рядок дорівнює одному повному JSON-об'єкту. Такий файл легко дописувати в кінець і легко читати частинами.

Великий JSON-масив довелося б щоразу перечитувати цілком. Тут — ні: новий рядок просто лягає в кінець.

<?php
declare(strict_types=1);

// 1. Приймаємо тільки POST і тільки розумного розміру
$raw = file_get_contents('php://input');
if ($_SERVER['REQUEST_METHOD'] !== 'POST' || strlen($raw) > 8192) {
    http_response_code(405);
    exit('method not allowed');
}

// 2. Битий JSON не повинен валити сервіс
$data = json_decode($raw, true);
if (!is_array($data)) {
    http_response_code(400);
    exit('bad json');
}

// 3. Беремо лише відомі поля й обрізаємо довжину
$event = [
    'ts'     => gmdate('c'),
    'source' => substr((string)($data['source'] ?? 'unknown'), 0, 40),
    'type'   => substr((string)($data['type']   ?? 'event'),   0, 40),
    'title'  => substr((string)($data['title']  ?? ''),        0, 200),
];

// 4. Пишемо ПОЗА веб-корінням: ~/www/api/ -> на два рівні вгору -> ~/data/
$path = dirname(__DIR__, 2) . '/data/events.jsonl';
$line = json_encode($event, JSON_UNESCAPED_UNICODE) . "\n";
file_put_contents($path, $line, FILE_APPEND | LOCK_EX);

http_response_code(200);
header('Content-Type: application/json');
echo json_encode(['ok' => true]);

dirname(__DIR__, 2)

піднімає шлях на два рівні від теки скрипта: ~/www/api → ~/www → ~. Так журнал гарантовано лежить поза www, і не залежить від того, з якої теки запущено PHP.

?? і substr

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

LOCK_EX

дві події, що прийшли одночасно, не змішають свої рядки в один.

gmdate('c')

час у UTC в форматі ISO 8601. Час сервера, а не автора події — так рядки завжди йдуть по порядку.

{"ts":"2026-09-02T08:41:07+00:00","source":"apps-script","type":"form","title":"Заявка на гурток робототехніки"}
{"ts":"2026-09-02T09:15:52+00:00","source":"apps-script","type":"form","title":"Заявка на гурток 3D-друку"}
{"ts":"2026-09-02T11:02:30+00:00","source":"ifttt","type":"weather","title":"Завтра дощ: нагадати про парасольку"}
{"ts":"2026-09-02T12:47:11+00:00","source":"unknown","type":"event","title":""}

Останній рядок — це чийсь порожній POST на твою адресу. Він валідний, тому й записався.

Такі рядки варто рахувати окремо. Їхня кількість показує, наскільки твій приймач відкритий цілому світу.

# Сценарій автоматизації

**Кейс.** Навіщо це взагалі потрібно, одним реченням.

| Частина | Що саме |
|---|---|
| Тригер | нова відповідь у формі «Запис у гурток» |
| Фільтр | поле «Клас» = 10А, поле «Гурток» не порожнє |
| Дія | POST JSON на http://91.219.61.4/s/<логін>/api/hook.php |
| Сервіс | Zapier / IFTTT / Apps Script — що саме використано |

## Квоти мого тарифу
- ліміт: ... задач або аплетів
- як часто опитується тригер: ...
- що буде, коли ліміт вичерпається: ...

## Як цей сценарій може зламатися тихо
1. ...
2. ...

## Як я про це дізнаюсь
Сторінка /events/ показує час останньої події. Якщо він старший за добу — ...

Практика: ключ, сценарій, приймач

Кроки 1—9 — у себе на комп'ютері й на сервері по SSH. Кроки 10—11 — у сервісі автоматизації. По FTP їдуть три файли: api/hook.php з кроку 12, events/index.php з кроку 15 і api/scenario.md з кроку 16. Галочки зберігаються

Автоперевірка

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

Демонстраційний режим: результат згенеровано для показу. На сервері ця кнопка викликає POST /api/check, який запускає /opt/lessons/11/check.sh від імені учня.

Що вчитель дивиться на твоєму екрані

• сам сценарій у Zapier або IFTTT: тригер, фільтр і історію запусків — що він справді спрацьовував, а не був створений хвилину тому;
• як ти заходиш на сервер зі свого ноутбука без пароля — командою ssh -o PasswordAuthentication=no;
• вивід ls -l ~/.ssh у тебе локально: що приватний ключ на місці й має права 600;
• екран згоди сервісу: які саме скоупи ти дозволив і чому саме ці;
• твій scenario.md — і просить назвати два способи, якими сценарій може зламатися тихо.

Шкала виконання

Це те, що бачить учитель, коли виставляє оцінку.

Шість речень, які варто запам'ятати

• приватний ключ не передається мережею ніколи — передається підпис, і він прив'язаний до конкретного сеансу;
• пароль підбирають не перебором усіх варіантів, а списком уже відомих;
• ключ не міняють — ключ відкликають, прибравши рядок із authorized_keys;
• 777 на ~/.ssh дозволяє сусідові дописати свій ключ, тому сервер відмовляється працювати з такою текою;
• зовнішньому сервісу дають рівно ті права, які потрібні сценарію, бо токен зберігається не в тебе;
• автоматизація ламається тихо — тому першою будують сторінку, на якій видно час останньої події.

Де найчастіше помиляються

• у authorized_keys вставлено вміст приватного ключа: рядок починається з -----BEGIN — це аварія, ключ міняємо;
• ключ згенеровано на сервері — приватна частина лишилася на спільній машині, сенс схеми втрачено;
• authorized_keys набрано в nano з переносом рядка посеред base64 — вхід не працює, а помилки не видно: сервер просто мовчки просить пароль;
• ключ перевірено командою ssh без -o PasswordAuthentication=no: клієнт тихо перейшов на пароль, а учень вирішив, що ключ працює;
• chmod -R 777 ~ «щоб FTP не лаявся» — і вхід за ключем ліг;
• events.jsonl покладено в ~/www/data/ — весь журнал подій віддається по HTTP усьому світу;
• у scenario.md записано «ліміт великий, вистачить» замість конкретного числа з тарифу.

Домашнє завдання

Опиши в ~/www/api/scenario.md два способи, якими твій сценарій може зламатися тихо. Тобто перестати працювати так, що помилки ніхто не побачить. Для кожного напиши, як саме ти про це дізнаєшся.

Підказки, куди дивитися. Скінчилася квота тарифу. Токен доступу відкликали або в нього минув термін. Сервіс перейменував поле у формі. Твій сервер відповів 500, а сервіс не повторив спробу.

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

Звідки взяті числа й формулювання

Усі розрахунки часу підбору з кроку 3 можна перевірити калькулятором: припущення про швидкість написані просто на схемі

• RFC 4252, розділ 7 «Public Key Authentication Method: publickey» — першоджерело того, як влаштована автентифікація ключем: клієнт надсилає підпис, у який входить ідентифікатор сеансу, а не розшифроване число. rfc-editor.org/rfc/rfc4252
• RFC 8709 — алгоритми ssh-ed25519 в SSH; звідси постійний префікс рядка публічного ключа. rfc-editor.org/rfc/rfc8709
• RFC 8032, EdDSA — означення Ed25519 і рівень стійкості близько 2¹²⁸ операцій, з якого рахується нижня смуга на схемі кроку 3. rfc-editor.org/rfc/rfc8032
• ssh-keygen(1) — ключі -t, -C, -l, -f і -a rounds (кількість раундів KDF для парольної фрази, за замовчуванням 16). man.openbsd.org/ssh-keygen.1
• sshd(8), розділ AUTHORIZED_KEYS FILE FORMAT — формат рядка й вимоги до прав; там же описано, що StrictModes перевіряє право запису для групи та інших. man.openbsd.org/sshd.8
• sshd_config(5) — значення за замовчуванням: StrictModes yes, MaxAuthTries 6, PubkeyAuthentication yes, PermitRootLogin prohibit-password. man.openbsd.org/sshd_config.5
• fail2ban, файл jail.conf — значення з поставки в секції [DEFAULT]: bantime = 10m, findtime = 10m, maxretry = 5. Саме вони в симуляторі кроку 7. github.com/fail2ban/fail2ban
• RFC 5737 — діапазони 192.0.2.0/24, 198.51.100.0/24 і 203.0.113.0/24 зарезервовані для документації. Усі адреси на цій сторінці взято звідти, вони нічиї. rfc-editor.org/rfc/rfc5737
• Розмір словника паролів — файл rockyou.txt зі збірки SecLists містить близько 14,3 млн паролів. Число взято як порядок величини для схеми кроку 3, а не як точну характеристику конкретного бота. github.com/danielmiessler/SecLists
• Живі спостереження за скануванням порту 22 — публічний дашборд SANS Internet Storm Center. Туди варто зайти, щоб побачити, що «стіна атак» — не педагогічна вигадка. isc.sans.edu · port 22
• last(1) — команда читає /var/log/wtmp і доступна звичайному користувачеві; /var/log/auth.log натомість належить root:adm. Перевір у себе: ls -l /var/log/auth.log /var/log/wtmp. man7.org · last(1)
• Тарифи Zapier — безкоштовний план: 100 задач на місяць, двокрокові Zap, опитування раз на 15 хвилин; Webhooks by Zapier належить до платних (premium) застосунків. Перевірено у вересні 2026. zapier.com/pricing
• Тарифи IFTTT — безкоштовний план: 2 аплети, стандартна швидкість; сервіс Webhooks і багатокрокові аплети — лише в Pro і Pro+. Перевірено у вересні 2026. ifttt.com/plans
• Скоупи Google OAuth 2.0 — повний перелік із формулюваннями, які учень бачить на екрані згоди: drive.file, drive, spreadsheets.readonly, gmail.readonly. developers.google.com · OAuth scopes
• Google Apps Script, UrlFetchApp — метод fetch() і параметри method, contentType, payload, muteHttpExceptions із плану Б у кроці 10. developers.google.com · UrlFetchApp
• PHP: file_put_contents — прапорці FILE_APPEND і LOCK_EX, якими дописується рядок у events.jsonl. php.net · file_put_contents
• JSON Lines — опис формату «один рядок = один JSON-об'єкт». jsonlines.org
• Кодування й && у Windows PowerShell 5.1 — чому curl там є псевдонімом Invoke-WebRequest і чому оператор && між командами недоступний. learn.microsoft.com · Invoke-WebRequest

Повний список із поясненнями, що звідки взято і що є ілюстративним прикладом, — у файлі urok-11-джерела.md поруч із цією сторінкою.