0x00. Інтро

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

Це коротка практична інструкція для RouterOS v7: згенерувати ключову пару, імпортувати публічну половину в роутер, увійти приватною половиною й обійти єдину проблему, на якій спотикається більшість (RSA-ключі, що мовчки не працюють із сучасними OpenSSH-клієнтами).

Трохи термінів спершу:

  • Ключова пара — два взаємопов’язані файли: приватний ключ (лишається на вашій машині, ніколи її не покидає) і публічний ключ (.pub, його безпечно роздавати й встановлювати на роутер).
  • ed25519 — сучасний, невеликий, швидкий тип ключа. Кращий за RSA там, де підтримується, — а RouterOS 7.x його підтримує.

Для прикладів будемо виористовувати: користувач admin, хост 192.168.88.1 (типова LAN-адреса MikroTik). Підставте свої.

0x01. Генерація ключової пари

На вашій робочій машині (Linux, macOS чи Windows з OpenSSH) створіть ключову пару. ed25519 — рекомендований вибір:

ssh-keygen -t ed25519 -f ~/.ssh/mikrotik -C "admin@mikrotik"
  • -f ~/.ssh/mikrotik — куди записати ключі. Створюються два файли: ~/.ssh/mikrotik (приватний) і ~/.ssh/mikrotik.pub (публічний).
  • -C "admin@mikrotik" — коментар/мітка, суто для вашого власного обліку.

У вас запитають парольну фразу (passphrase). Для інтерактивного використання задайте її; для повністю автономного ключа автоматизації можна лишити порожньою (-N '').

Якщо доводиться використовувати RSA (напр. старіший клієнт без ed25519), зробіть його щонайменше 4096 біт:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/mikrotik -C "admin@mikrotik"

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

0x02. Завантаження й імпорт публічного ключа

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

Крок 1 — завантажити файл .pub

Скопіюйте публічний ключ на роутер вручну ( Files/ Upload ) або через scp, якщо вже налаштований ssh доступ. Зверніть увагу на прапорець -O: SSH-сервер RouterOS не підтримує сучасну передачу на основі SFTP, яку сучасний OpenSSH використовує за замовчуванням, тож треба примусово ввімкнути застарілий протокол scp через -O:

scp -O ~/.ssh/mikrotik.pub admin@192.168.88.1:

Кінцева двокрапка : означає «домашня тека користувача на роутері» — файл потрапляє у файлове сховище RouterOS як mikrotik.pub. Переконатися, що він прибув, можна з консолі роутера:

/file print

Крок 2 — імпортувати для користувача

Тепер зайдіть на роутер (вхід по паролю на цьому етапі ще працює) і виконайте імпорт, прив’язавши ключ до конкретного користувача:

/user ssh-keys import public-key-file=mikrotik.pub user=admin

Саме цей крок насправді активує ключ. Перевірте, що він зареєструвався:

/user ssh-keys print

Ви маєте побачити запис для користувача admin із типом і розміром ключа.

0x03. Вхід із ключем

Назад на робочій машині вкажіть ssh на приватний ключ через -i:

ssh -i ~/.ssh/mikrotik admin@192.168.88.1

Дві поведінки RouterOS, які варто знати:

  • Обмеження за адресою. Користувача RouterOS можна прив’язати до вихідної мережі через address=. Якщо ви це задасте, під’єднання звідусіль інде відхиляються незалежно від ключа. Наприклад, щоб дозволити цілу керувальну підмережу:

    /user set admin address=192.168.88.0/24

  • Лише ключ за замовчуванням. Щойно у користувача імпортовано SSH-ключ, RouterOS за замовчуванням переходить на вхід лише по ключу для цього користувача й відмовляє в паролі. Зазвичай це те, що потрібно. Якщо вам свідомо треба, щоб вхід по паролю й далі працював поряд із ключем, увімкніть його явно:

    /ip ssh set always-allow-password-login=yes

0x04. Проблема: ssh-rsa (SHA-1) вимкнено за замовчуванням

Ось те, що викликає найбільше плутанини. Сучасний OpenSSH (8.8 і новіші) вимкнув старий алгоритм підпису ssh-rsa — ця назва стосується саме RSA-підписів на основі SHA-1, який вважається слабким. Сам RSA-ключ нормальний; заблоковано саме SHA-1-підпис.

Симптом: ви коректно імпортували RSA-ключ, /user ssh-keys print його показує, а клієнт усе одно падає з:

Permission denied (publickey).

…і, що збиває з пантелику, воно може падати з одного клієнта (напр. старішого чи Windows ssh) і працювати з іншого (сучасного Linux OpenSSH) із тим самим ключем. Причина в тому, що RouterOS 7.x підтримує новіші підписи rsa-sha2, тож сучасний клієнт домовляється про SHA-256 і успішно заходить, тоді як старіший клієнт пропонує лише SHA-1 і отримує відмову.

Два варіанти виправлення, найкращий — перший:

  1. Надайте перевагу ed25519 (найчистіше). Він обходить усе питання із SHA-1 і підтримується на RouterOS 7.x. Якщо можете перегенерувати ключ — зробіть так і рухайтеся далі.

  2. Знову ввімкніть ssh-rsa на клієнті як обхідний шлях, якщо ви застрягли з RSA-ключем і старішим клієнтом:

    ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -i ~/.ssh/mikrotik admin@192.168.88.1

    Щоб зробити це постійним, додайте до ~/.ssh/config для цього хоста:

    Host 192.168.88.1
    User admin
    IdentityFile ~/.ssh/mikrotik
    PubkeyAcceptedAlgorithms +ssh-rsa

0x05. Перевірка й діагностика

Коли вхід не працює, ці три команди покривають більшість випадків:

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

    ssh -v -i ~/.ssh/mikrotik admin@192.168.88.1

    Шукайте рядки Offering public key і send_pubkey_test, а також будь-яке Permission denied одразу після них.

  • На роутері — чи зареєстровано ключ?

    /user ssh-keys print

  • На роутері — налаштування SSH-сервера (напр. чи ще дозволено вхід по паролю):

    /ip ssh print

Швидкий уявний чек-лист, якщо все одно не працює: правильний користувач в імпорті? ключ справді імпортовано (а не лише завантажено)? address= не блокує ваш вихідний IP? і для RSA — проблема із SHA-1 з розділу 0x04.

0x06. Підсумок — чому ключі кращі за паролі для автоматизації

Для людини, що набирає одну команду, пароль підходить. Для автоматизації — ні: пароль мусить десь жити — у скрипті, змінній середовища, конфізі планувальника — де він може витекти, і кожен автономний запуск повторно шле його по мережі. Ключова пара вирішує обидві проблеми: приватний ключ лишається на одній машині, роутер тримає лише безпечну публічну половину, і немає секрета, який треба набирати чи зберігати у відкритому вигляді. До того ж ви отримуєте контроль на рівні користувача й ключа на роутері (обмеження address=, вхід лише по ключу) і чистий спосіб ротації доступу — просто видаліть запис ключа.

Почніть з ed25519, імпортуйте публічний ключ для виділеного користувача, обмежте його через address= — і ваші бекапи та скрипти під’єднуються без жодного пароля в полі зору.

Refs