Пора вже записати собі про MikroTik та Users Management – бо пост давно в чернетках лежить, ну і заодно і налаштувати аутентифікацію SSH з ключами.

Але пройдемось по основним концептам та налаштуванням Authentication, Authorization, Accounting в MikroTik – групи, політики та юзери.

Що є і що треба зробити:

• роутер MikroTik RB4011
• треба створити нового root user замість дефолтного admin
• додати read-only user
• налаштувати аутентифікацію SSH

Всі user permissions визначаються групою юзера та його properties – див. User Groups:

• Groups: містить список Policies та описує дозволи юзерів цієї групи в системі
• Policy: визначає який конкретний scope дозволів – підключення по SSH, редагування конфігурації тощо
• User: і врешті-решт власні properties юзера визначають як він аутентифікується – логін-пароль, звідки доступний доступ, etc

Окрім локальної бази груп юзерів можна налаштувати інтеграцію з зовнішніми системами – FreeRADIUS, JumpCloud, див. RADIUS.

Але для домашнього роутера це точно оверкіл.

Попередні частини по налаштуванню MikroTik – MikroTik: перше знайомство та Getting Started та MikroTik: налаштування WireGuard та підключення Linux peers.

User Groups та Policies

В RouterOS не надто гнучка система для управління доступами – далеко не RBAC в Kubernetes, але, звісно, є можливість створювати групи і юзерів з різними правами доступу.

В комплекті маємо 3 дефолтні групи:

• full: повний доступ – дефолтний юзер admin саме в цій групі
• write: можна змінювати більшість налаштувань – але без доступу до user management
• read: тільки читати конфіг – але нічого змінювати
  • хоча дозвіл на reboot тут є

Всі user permissions кожного юзера в кожній групі визначаються набором політик цієї групи.

Політики дефолтні, вони вже є в системі – редагувати чи створювати нові ми не можемо.

Подивитись список груп та політики кожної групи:

/user group print

Policies

Політики діляться на дві основні групи – Login і Config.

З того, що цікаво прямо зараз:

• login policies:
  • ssh, web, winbox: як можемо підключатись
  • password: зміна пароля (тільки для себе)
• config policies:
  • read та write: читання чи редагування конфігурації роутера
  • policy: управління групами та юзерами
  • test: використання утиліт типу ping, traceroute, etc
  • sensitive: чи будуть відображатись ключі, сертифікати

Створення Group

Напряму підключити політики до юзера не можна – тому робимо через окрему групу, до якої потім додамо юзера.

Маємо на увазі, що один юзер може мати тільки одну групу (да, зовсім не Kubernetes RBAC…).

Створюємо групу, задаємо дозвіл на SSH чи читання конфігурації:

/user group add name=setevoy-ro policy=read,ssh

Перевіряємо список:

/user group print where name=setevoy-ro

Видалити групу – з /user group remove <ID>.

Редагування Policies для Group

Додати або видалити пермішени – /user group set.

Важливий нюанс: при set треба задавати весь новий список. Тобто, якщо передати просто “policy=web” – то група залишиться без SSH, тому передаємо всі:

/user group set [find name=setevoy-ro] policy=ssh,read,web

Або якщо треба відключити політику – вказуємо через !policy-name, або просто set без цієї політики:

/user group set [find name=setevoy-ro] policy=ssh,read,!web

Отримати список всіх юзерів:

/user print detail

Для кожного юзера задаються його параметри, основні:

• address: звідки дозволено підключення
• group: група юзера
• name: ім’я
• password: пароль

group=full та новий Admin User

MikroTik рекомендує видаляти дефолтного юзера admin – бо всім відоме ім’я, див. Securing your router.

Тому робимо нового адміна з дефолтною групою full та обмежуємо мережі, з яких буде доступ.

Так як тут передається пароль – то команда в історії не зберігається і відразу після Enter зникне з консолі:

/user add name=gw-setevoy-root password="change-me-now" group=full address=192.168.0.0/24,192.168.100.0/24,10.100.0.0/24 comment="New root user for RB4011"

Відключаємо дефолтного admin:

/user disable admin

Потім можна видалити взагалі з /user remove admin.

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

Custom Group і новий юзер

Додаємо нового read-only user з групою setevoy-ro, яку створили вище, доступ дозволяємо тільки з локальної мережі:

/user add name=gw-setevoy-ro password="change-me-now" group=setevoy-ro address=192.168.0.0/24 comment="Read only user for RB4011"

Перевіряємо юзерів тепер:

/user print detail  where name=gw-setevoy-ro

І пробуємо підключитись:

[setevoy@setevoy-work ~] $ ssh [email protected]
...
[gw-setevoy-ro@mikrotik-rb4011-gw] > 

Write permissions не маємо, відповідно якщо спробуємо щось змінити – отримаємо помилку “not enough permissions“:

/interface wireguard add name=wg-test
not enough permissions (9)

І в address вказували тільки одну, локальну – тому з VPN підключитись не вийде:

Аби додати ще мережу, з якої дозволяємо доступ – ще раз /user set, і, як і при group set, теж вказуємо повний список мереж – і стару, і нову:

/user set gw-setevoy-ro address=192.168.0.0/24,10.100.0.0/24

Тепер можемо підключитись – перевіряємо активні сесії з /user active print:

Policy “sensitive”

Приклад того, як працює sensitive – бо не дуже очевидна штука і не дуже розкрито в документації.

Для прикладу – під адміном створимо новий WireGuard інтерфейс:

/interface wireguard add name=wg-test

Юзер setevoy має full групу, а full група має sensitive policy – тому setevoy може побачити приватний ключ WireGuard з show-sensitive:

/interface wireguard print detail show-sensitive

Але для юзера gw-setevoy-ro, у якого група не має політики sensitive – значення буде сховане за “***”:

SSH та ключі

Ну і про чудове: раз у нас є SSH – то є і можливість використовувати ключі для аутентифікації.

Important та keep in mind: з дефолтними налаштуваннями після додавання ключу парольна аутентифікація для юзера, якому доданий ключ, більше недоступна:

Але можна задати password-authentication=yes, див. SSH Server.

На ноуті створюємо ключ:

[setevoy@setevoy-work ~] $ ssh-keygen -t ed25519 -C "gw-setevoy-ro@rb4011" -f ~/.ssh/gw-setevoy-ro

Отримуємо його pub key:

[setevoy@setevoy-work ~]  $ cat ~/.ssh/gw-setevoy-ro.pub 
ssh-ed25519 AAA***a2lM gw-setevoy-ro@rb4011

На MikroTik є два варіанти додати ключ для юзера – скопіювати туди сам файл gw-setevoy-ro.pub, або передати зміст при виклику /user ssh-keys import.

Приклад з копіюванням – передаємо з ноута на роутер, адресу задаємо з двокрапкою в кінці – “192.168.0.1:” – скопіювати в корінь системи.

З ноутбука робимо scp:

[setevoy@setevoy-work ~]  $ scp .ssh/gw-setevoy-ro.pub 192.168.0.1:

На MikroTik перевіряємо файл:

/file print where name=gw-setevoy-ro.pub

Додаємо до юзера з /user ssh-keys import та public-key-file:

/user ssh-keys import user=gw-setevoy-ro public-key-file=gw-setevoy-ro.pub

Перевіряємо ключі юзера:

/user ssh-keys print  where user=gw-setevoy-ro

Тепер можемо підключатись з ноутбука без пароля:

[setevoy@setevoy-work ~] $ ssh -i .ssh/gw-setevoy-ro [email protected]

Другий варіант – передати ключ через аргумент key:

/user ssh-keys add user=setevoy key="ssh-ed25519 AAA***SWoE gw-setevoy-root@rb4011"

Додаємо на ноутбуці використання ключа в ~/.ssh/config (в мене ключі в 1Password, тому його агент):

Host gw.net.setevoy 192.168.0.1
  IdentityAgent ~/.1password/agent.sock
  IdentityFile ~/.ssh/gw-setevoy-root.pub
  IdentitiesOnly yes

Готово.