Mikrotik ssh client: Делаем доступ на Mikrotik по SSH ключу

Делаем доступ на Mikrotik по SSH ключу

Привет всем! Обратился ко мне один хороший друг и порекомендовал тему для статьи – настройку авторизации по SSH-ключу на железе Mikrotik. В целях повышения безопасности, разумеется.

Кстати, на правах рекламы, хочу порекомендовать наш магазин сетевого оборудования: antelecs.ru, все эксперименты проводятся именно на микротах с этого магазина.

Зачем нужна авторизация по SSH

Как зачем? Для повышения безопасности. Во-первых, плюсы SSH-протокола перед Telnet очевидны. Шифрование. Во-вторых, почему именно ключ? Ключевой файл (приватный ключ) при нормальном хранении получить злоумышленнику намного сложнее, чем пароль. Даже ввиду размера. Брут неэффективен от слова “совсем”.

А если защитить файл приватного ключа паролем, то и вовсе безопасность будет выше.

При этом не стоит забывать о простых вещах – как минимум переименовать администратора во что-то менее тривиальное, чем “admin”. Отключить лишние сервисы (http, telnet), а сам ssh можно перевесить на другой порт.

Вдобавок впесочить ещё Port Knocking, тогда попасть в ваш Mikrotik злоумышленнику будет куда тяжелее!

Генерируем ключи

Для генерации пары ключей (открытый – публичный и закрытый – приватный) мы воспользуемся утилиткой puttygen.exe, входящей в состав привычного SSH-клиента PuTTY. Главное окно программы выглядит вот так:

Выбираем тип ключа – SSH-2 RSA и длину ключа в битах, я оставил 2048 бит. На выходе, кстати, иногда получается ключ длиной 2047 бит, это не бага, а особенность работы алгоритма RSA – не стоит о ней волноваться.

Кстати, вспомнилось как-то, как на Pascal в институте писал реализацию алгоритма RSA – может быть повторю как-нибудь на страницах нашего сайта, весьма любопытно было.

Итак, нажимаем кнопку “Generate” и начинаем елозить мышью по окну. Не поймите меня буквально

Когда процесс генерации будет завершён, увидим окно подобное этому:

Теперь нужно скопировать публичный ключ из поля [1] в произвольный текстовый файл.

Важно. Не пользуйтесь кнопкой “Save public key”, т.к. puttygen сохраняет ключ в своём формате, который плохо совместим с нормальными ssh-сервисами.

А вот приватный ключ мы сохраним нажав на соответствующую кнопку. Итак, на выходе у вас должно получиться 2 файла: публичный ключ, сохранённый из текстового поля и приватный ключ, сохранённый посредством кнопки.

Импортируем ключи в Mikrotik

Входим в Mikrotik любым удобным для нас способом. Я в конкретном примере воспользовался WinBox.

Переходим в раздел Files и перетаскиваем туда публичный ключ!

Теперь нужно добавить этот ключ в разделе “System -> Users”. Переходим на вкладку “SSH Keys” и нажимаем на кнопку “Import SSH Key”.

В появившемся окне указываем имя пользователя, которому соответствует данный ключ, а также непосредственно файл ключа (появится выпадающий список). Затем нажимаем кнопку “Import SSH Key” уже в диалоговом окне и всё. Ключ установлен.

Входим в систему

Для входа в систему воспользуемся, как я уже упоминал, PuTTY. Создадим новое подключение, указав IP-адрес и порт, затем перейдём на следующую вкладку:

Раздел “Connection -> SSH -> Auth”, в поле “Private key file for authentication” добавим наш приватный ключ. Жмём “Open”.

После появления стандартного диалогового окна добавляем ключ в кеш.

В окне терминала введём имя пользователя “dmitry” и сразу (без пароля!) попадаем в консоль Mikrotik.Для обеспечения наилучшей безопасности, конечно, хорошо бы использовать пароль на ключ (во время генерации ключа указывается). Но это уже детали!

Всем удачи! Be secure!

Если вам понравилась данная статья – поставьте лайк! Так я буду знать стоит ли писать ещё на данную тематику. Лучшая награда писателя – отклик от читателей. Заранее благодарю.

Mikrotik и ssh — Всяко разно

Утилита plink позволяет через консоль подключаться по протоколу SSH. Plink будем использовать для отправки команд Mikrotik-у. Найти утилиту можно установив PuTTY и вызвав консоль.

В зависимости от разрядности операционной системы пути будут следующие:

• для версии х64: «C:\Program Files\PuTTY\plink.exe»
• для версии х86: «C:\Program Files (x86)\PuTTY\plink.exe»

Открытие SSH на Mikrotik (через firewall):

/ip firewall filter
add action=accept chain=input comment=»SSH» dst-port=22 protocol=\
udp src-address=192.168.*.*/**

Включаем встроенный сервис SSH:

/ip service
set ssh address=192.168.*.*/* disabled=no

Правила в firewall.

Включение правил:

plink 192.168.*.* -ssh -P 22 -l login-admin -pw P@ssW0Rd -2 -4 «/ip firewall filter;:for x from 5 to 7 do={/ip firewall filter set $x disabled=no}»

from 5 to 7 — с какого по какое правило в firewall.

Отключение правил:

plink 192.168.*.* -ssh -P 22 -l login-admin -pw P@ssW0Rd -2 -4 «/ip firewall filter;:for x from 5 to 7 do={/ip firewall filter set $x disabled=yes}»

Simple Queues (ограничение скорости).

Включение:

plink 192.168.*.* -ssh -P 22 -l login-admin -pw P@ssW0Rd -2 -4 «/queue simple enable 0»

Ноль в конце команды означает номер строки в правиле.

Отключение:

plink 192.168.*.* -ssh -P 22 -l login-admin -pw P@ssW0Rd -2 -4 «/queue simple disable 0»

Обозначения.

192.168.*.* — адрес mikrotik.

login-admin — логин для mikrotik.

P@ssW0Rd — пароль.

192.168.*.*/** — адресация сети.

Прозрачный вход по ssh на устройство Mikrotik

Прочитано:
5 548

Хочу по аналогии с моими доверенными системами (Ubuntu 12.04/14.04 Server) подключаться и к устройствам Mikrotik задействуя ssh.

Все дальнейшие действия происходят на моей рабочей/домашней системе Ubuntu 12.04.5 Desktop amd64 ноутбука Lenovo ThinkPad E555.

Первым делом активирую службу удаленного безопасного подключения через SSH (port 22) (и FTP, port 21) на устройстве Mikrotik

ekzorchik@navy:~$ winbox – 192.168.1.9 – IP – Services – находим строку где присутствует надпись ssh & ftp и если строка затемнена активируем. Затем отключаемся от Mikrotik‘а.

Далее на системе Ubuntu генерируем/проверяем наличие пары публичного ключа хоста и приватного:

ekzorchik@navy:~$ ssh-keygen -t dsa

ekzorchik@navy:~$ ls .ssh/id_dsa*

.ssh/id_dsa .ssh/id_dsa.pub

После чего передаем публичный ключ на устройство mikrotik следующим образом:

ekzorchik@navy:~$ cp /home/ekzorchik/.ssh/id_dsa.pub iddsa

ekzorchik@navy:~$ ftp 192.168.1.9

Connected to 192.168.1.9.

220 ekzorchik FTP server (MikroTik 6.33.5) ready

Name (192.168.1.9:ekzorchik): ekzorchik

331 Password required for ekzorchik

Password:

230 User ekzorchik logged in

Remote system type is UNIX.

ftp>

передаю файл публичного ключа на mikrotik:

ftp> put iddsa

local: iddsa remote: iddsa

200 PORT command successful

150 Opening ASCII mode data connection for ‘/iddsa’

226 ASCII transfer complete

605 bytes sent in 0.00 secs (13427.7 kB/s)

ftp> bye

221 Closing

подключаюсь к устройству mikrotik через winbox, открываю консоль командной строки и скопированный выше файл отпечатка системы Ubuntu 12.04.5 Desktop amd64 импортирую в хранилище ключей удаленного доверенного доступа устройства Mikrotik:

ekzorchik@navy:~$ winbox – 192.168.1.9 (Login: admin, Password = 712mbddr@) – New Terminal -

[admin@ekzorchik] > user ssh-keys import public-key-file=iddsa

На заметку: если на устройстве Mikrotik заведен еще один пользователь с правами Администратора, то тогда нужно указать что публичный ключ с системы Ubuntu (на которой запускалась команда ssh-keygen -t dsa) применим для этого пользователя:

ekzorchik@navy:~$ ssh-keygen -t dsa

[ekzorchik@ekzorchik] > user ssh-keys import public-key-file=iddsa user=ekzorchik

На заметку: импортировать ключ на устройстве Mikrotik можно также не подключаясь через winbox, а просто подключить из локальной сети посредством утилиты telnet:

ekzorchik@navy:~$ telnet 192.168.1.9

Trying 192.168.1.9…

Connected to 192.168.1.9.

Escape character is ‘^]’.

MikroTik v6.33.5 (stable)

Login: ekzorchik

Password:

[ekzorchik@ekzorchik] > user ssh-keys import public-key-file=iddsa user=ekzorchik

[admin@ekzorchik] > quit

interrupted

Отлично, теперь продемонстрирую как будет происходить аутентификация с системы Ubuntu 12.04.5 Desktop amd64 на устройстве mikrotik при безопасном подключении через ssh:

ekzorchik@navy:~$ ssh -l ekzorchik 192.168.1.9

The authenticity of host ‘192.168.1.9 (192.168.1.9)’ can’t be established.

RSA key fingerprint is 38:67:29:0f:ad:91:6a:95:68:80:f7:4a:be:5c:61:2d.

Are you sure you want to continue connecting (yes/no)? Yes

Warning: Permanently added ‘192.168.1.9’ (RSA) to the list of known hosts.

[email protected]’s password:

[ekzorchik@ekzorchik] > system routerboard print

;;; Firmware upgraded successfully, please reboot for changes

to take effect!

routerboard: yes

model: 2011UiAS-2HnD

serial-number: 614A052CFEA6

firmware-type: ar9344

current-firmware: 3.24

upgrade-firmware: 3.24

Выхожу и пробую подключить еще раз, пароль при подключении спрашиваться не должен:

[ekzorchik@ekzorchik] > quit

interrupted

Connection to 192.168.1.9 closed.

ekzorchik@navy:~$ ssh -l ekzorchik 192.168.1.9

[email protected]’s password:

хм, странно – а почему у меня все же происходит запрашивание пароля, опять документация по настройке врет или же просто многое якобы само собой разумеющееся опускается, я же в свою очередь хочу все для себя разобрать:

Оказалось все очень просто, до этого я обновлял устройство и по окончании процедуры не перезагрузил устройство, кстати в выводе выше как раз присутствует информационное сообщение, что устройство обновлено и для активации изменений его нужно перезагрузить. Перезагрузив, пробую подключиться и вуаля – подключение через ssh происходит без какого либо запроса пароля, как раз то что мне и нужно было:

ekzorchik@navy:~$ ssh -l ekzorchik 192.168.1.9

192.168.1.9 via ssh

[ekzorchik@ekzorchik] >

[ekzorchik@ekzorchik] > quit

interrupted

Connection to 192.168.1.9 closed.

Еще интересным стоит выделить возможность подключившись выполнить команду не переходя всецело в консоль устройства Mikrotik:

ekzorchik@navy:~$ ssh [email protected] system routerboard print

routerboard: yes

model: 2011UiAS-2HnD

serial-number: 614A052CFEA6

firmware-type: ar9344

current-firmware: 3.24

upgrade-firmware: 3.24

ekzorchik@navy:~$ ssh [email protected] file print

# NAME TYPE SIZE CREATION-TIME

0 advanced-tools-6.32… package 100.1KiB jan/02/1970 05:05:55

1 skins directory jan/01/1970 03:00:01

2 auto-before-reset.b… backup 78.1KiB jul/27/2015 18:50:44

3 pub directory jan/02/1970 03:06:19

4 hotspot-6.32.1-mips… package 184.1KiB jan/02/1970 05:07:44

5 system-6.32.1-mipsb… package 6.8MiB jan/02/1970 05:08:01

6 ekzorchik-20151218-… backup 49.0KiB dec/17/2015 21:48:50

7 dhcp-6.32.1-mipsbe.npk package 168.1KiB jan/02/1970 05:07:35

8 autosupout.rif .rif file 491.7KiB jan/27/2016 14:16:47

посредством этой возможности можно сделать хоть и корявый но как на первый шаг сгодится скрипт, который будет делать бекап устройства, забирать/отправлять по почте/ftp бекап на доверенное хранилище.

А теперь если же нужно забрать с устройства Mikrotik к примеру конфигурационный файл устройства со всеми настройками или же просто бекап, то сделать это можно следующим образом:

[ekzorchik@ekzorchik] > system backup save name=backup

Saving system configuration

Configuration backup saved

[ekzorchik@ekzorchik] > file print

# NAME TYPE SIZE CREATION-TIME

0 skins directory jan/01/1970 07:00:02

1 disk4 disk dec/15/2015 18:30:44

2 Mikrotik_27012015.b… backup 13.0KiB jan/27/2016 20:17:52

3 backup.backup backup 13.0KiB jan/27/2016 20:19:56

ekzorchik@navy:~$ sftp [email protected]:backup.backup

Connected to 192.168.1.9.

Fetching /backup.backup to backup.backup

/backup.backup 100% 13KB 13.0KB/s 00:00

ekzorchik@navy:~$ dir -sh backup.backup & file backup.backup

[1] 30479

16K backup.backup

backup.backup: data

[1]+ Готово dir -sh backup.backup

А если сделать маленький скрипт на системе Ubuntu посредством которого уже сделаем бекап на устройстве с генерирование текущей даты и времени и скопируем его себе на рабочую станцию:

ekzorchik@navy:~$ nano backup_192_168_1_9

#!/bin/bash

bfile=$(date +%d%m%y_%H_%M)

ssh [email protected] system backup save name=Backup192_168_1_9_$bfile

sftp [email protected]:Backup192_168_1_9_$bfile.backup

ekzorchik@navy:~$ chmod +x backup_192_168_1_9

Запускаю данный скрипт:

ekzorchik@navy:~$ ./backup_192_168_1_9

Configuration backup saved

Connected to 192.168.1.9.

Fetching /Backup192_168_1_9_270116_17_03.backup to Backup192_168_1_9_270116_17_03.backup

/Backup192_168_1_9_270116_17_03.backup 100% 13KB 13.0KB/s 00:00

ekzorchik@navy:~$ dir -sh Backup192_168_1_9_270116_17_03.backup && file $_

16K Backup192_168_1_9_270116_17_03.backup

Backup192_168_1_9_270116_17_03.backup: data

Отлично — это полный бекап, а теперь нужно добавить еще в скрипт экспорт всех настроек в виде скрипта выполнив который при восстановлении произойдет восстановление функционала до рабочего уровня если вдруг что-то произошло (вышло из строя/неосторожная настройка и т.д.)

#!/bin/bash

bfile=$(date +%d%m%y_%H_%M)

efile=$(date +%d%m%y_%H_%M)

ssh [email protected] system backup save name=Backup192_168_1_9_$bfile

ssh [email protected] export file=Export192_168_1_9_$efile.rsc

sftp [email protected]:Backup192_168_1_9_$bfile.backup

sftp [email protected]:Export192_168_1_9_$efile.rsc

ekzorchik@navy:~$ ./backup_192_168_1_9

Configuration backup saved

Connected to 192.168.1.9.

Fetching /Backup192_168_1_9_270116_17_12.backup to Backup192_168_1_9_270116_17_12.backup

/Backup192_168_1_9_270116_17_12.backup 100% 16KB 15.9KB/s 00:00

Connected to 192.168.1.9.

Fetching /Export192_168_1_9_270116_17_12.rsc to Export192_168_1_9_270116_17_12.rsc

/Export192_168_1_9_270116_17_12.rsc 100% 244 0.2KB/s 00:00

ekzorchik@navy:~$ dir -sh Export192_168_1_9_270116_17_12.rsc && file $_

4.0K Export192_168_1_9_270116_17_12.rsc

Export192_168_1_9_270116_17_12.rsc: ASCII text, with CRLF line terminators

Ну вот уже лучше, не правда ли, я посредством скрипта и активированной возможности аутентификации на устройстве Mikrotik посредством публичного ключа с доверенного хоста провожу без парольный вход, делаю бекап и экспорт всех команд посредством которых настроено оборудование (применяется в целях изучения, а как сделать ту или иную настройку не через Winbox или же Web-интерфейс, а задействовав командную строку – так более продуктивно и приобретается опыт), как на устройство так и на локальную систему Ubuntu 12.04.5 Desktop amd64

Ну а что теперь, считаю данную заметку завершенной, в дальнейшем на основе этой я рассмотрю другую еще более интересную и практическу, а пока собственно все – с уважением автор блога, ekzorchik.

Бекапим Mikrotik с помощью SSH и SCP / Хабр

Если заглянуть назад в прошлое когда еще не было Ansible или других систем удаленного администрирования linux мы пользовались только своими подручными скриптами, позволяли им подключаться к системам по ssh с помощью ключей. Думаю и по сей день многие использую свои скрипты взамен системам централизованного управления.

Я и решил поделиться своим опытом.

Нужно было написать скрипт который умеет ходить на заданное количество хостов и бекапит некоторые файлы конфигураций.

Логика работы выстроилась сразу. Зайти на хост по ssh, выполнить некоторые команды для подготовки бекапов и забрать готовые файлы с помощью scp.

Первым делом нужно создать пользователя который будет иметь доступ к необходимым данным с необходимыми правами. Тут я думаю каждый сам сможет разобраться в какую группу определить пользователя. Главное помнить:

1. Имя пользователя для работы входа без пароля должно быть одинаковое на всех хостах или придется для каждого хоста указывать свой логин что не есть удобно;
2. Пользователь должен иметь доступ на хост без пароля (ssh-keygen в помощь) ;
3. Пользователь должен иметь доступ к файлам которые необходимо забрать.

тут можно пойти несколькими путями 1) выполнить команду в удаленном shell для сбора необходимых данных подлежащих резервированию и потом их забрать 2) настроить cron на хосте и выполнять команду сбора данных а уже потом, когда нибудь, заходить на хост и забирать готовые пирожки бекапы. Конечно мы пойдем по первому пути

Имеем такую конфигурацию —

10 хостов (Mikrotik) с которых необходимо получить два типа бекапов — бинарный (для восстановления с нуля) и конфигурацию без паролей и сертификатов для заливки на работающий конфиг. Так же в полном нашем распоряжении имеется машина с debian 8 на борту назовем ее сервер (и не важно что это контейнер, важно что это дебиан) ну и конечно куда ж без него — zabbix-server.

• IP Mikrotik — 10.10.0.1, 10.10.1.1, 10.10.2.1, 10.10.3.1, 10.10.4.1, 10.10.5.1, 10.10.6.1, 10.10.7.1, 10.10.8.1, 10.10.9.1;
• IP Zabbix-server — 10.10.10.10;

Для упрощения задачи zabbix-hostname будет в формате mik(третий октет в десятичном формате).host таким образом получаем —

• Zabbix hostnames — mik0.host, mik1.host, mik2.host, mik3.host, mik4.host, mik5.host, mik6.host, mik7.host, mik8.host, mik9.host

Если кто не помнит — zabbix hostname мы указываем в файле настроек zabbix-agent(агент тут не нужен, но все же) и на сервере zabbix в web-ui.

Первым делом создаем на нашем сервере ключ RSA. Почему RSA — да вообщем то по привычке, кстати, старые версии RB поддерживают только DSA, а все что свежее 6.35 уже работает с RSA и DSA, потому смотрите по обстановке, можно и обновиться, как сделал я 🙂, если у вас уже есть готовый ключ — пропускайте этот шаг.

ssh-keygen -t RSA

Переносим содержимое файла $HOME/.ssh/id_rsa.pub с сервера на наши хосты. Я ленивый и для Mikrotik использовал winbox.

Для линукс можно сделать проще создаем скрипт sh и запускаем его от имени пользователя которым мы будем ходить на хост за бекапами (на хостах пользователь уже должен быть) такого содержания —
Если у вас ключ DSA то измените id_rsa.pub на id_dsa.pub

#!/usr/bin/env bash

hosts=(10.10.0.1 10.10.1.1 10.10.2.1 10.10.3.1 10.10.4.1 10.10.5.1 10.10.6.1 10.10.7.1 10.10.8.1 10.10.9.1)
username='user'
for host in ${hosts[*]} 
        do
                cat $HOME/.ssh/id_rsa.pub | ssh -o "StrictHostKeyChecking no" ${user}@${host} 'cat >> ~/.ssh/authorized_keys'
        done

Запускаем его и вводим поочередно пароли для всех 10 серверов.

В скрипте есть подвох — специально не стал добавлять проверку, а то совсем забуду как клавиши нажимать -) если вы все прочитали то подвох не сработает.

Тааак, что там дальше, а, точно, мы уже умеем ходить без пароля на все хосты под пользователем допустим user.
Мы же хотим получить конфиги Mikrotik. Собственно приступим.

Создаем на сервере вот такой вот скрипт —

#!/usr/bin/env bash

hosts=(10.10.0.1_mik0.host_22 \
       10.10.1.1_mik1.host_22 \
       10.10.2.1_mik2.host_22 \
       10.10.3.1_mik3.host_22 \
       10.10.4.1_mik4.host_22 \
       10.10.5.1_mik5.host_22 \
       10.10.6.1_mik6.host_22 \
       10.10.7.1_mik7.host_22 \
       10.10.8.1_mik8.host_22 \
       10.10.9.1_mik9.host_22 )
# bash array of values. All values are arrays too, after remove splitter "_".
# Sub array content IP_ZABBIX-HOSTNAME_SSH-DAEMON-PORT
cdate=`date +%d-%m-%Y` # System date =) Hi Max
dir="/mik_backup/" # Storage for backups
cmd="/system backup save name=backup; export file=backup.rsc hide-sensitive" # command that do the preparation of backup
username="user" # SSH user
zabbix_hp=(10.10.10.10 10051) # IP then PORT
age="30" # remove all backups older then 30 days
itemname="backup" # zabbix item
error_value="1" # error value for trigger
value="0" # good value =)

for host in ${hosts[*]} # Get values from main list
do
hostname=($(echo ${host} | tr "_" " ")) # Get values from sub list
ssh ${username}@${hostname[0]} -o "StrictHostKeyChecking no" -p${hostname[2]} "${cmd}"
new_dir="${HOME}${dir}${hostname[1]}/${cdate}"
mkdir -p ${new_dir}
scp -P${hostname[2]} ${username}@${hostname[0]}:backup.backup  ${new_dir}
scp -P${hostname[2]} ${username}@${hostname[0]}:backup.rsc ${new_dir}
check=`find ${new_dir} -type f -name backup.*`
if [ "${check}" == "" ]
then
zabbix_sender -z ${zabbix_hp[0]} -p ${zabbix_hp[1]} -s ${hostname[1]} -k ${itemname} -o ${error_value}
else
zabbix_sender -z ${zabbix_hp[0]} -p ${zabbix_hp[1]} -s ${hostname[1]} -k ${itemname} -o ${value}
fi
done
find ${HOME}${dir} -mindepth 2 -mtime ${age} -type d -exec rm -rf {} \; #clear dirs

Постарался максимально прокомментировать все что происходит в скрипте. Давайте разберем, что же тут такое делается.

Тут мы говорим каким интерпретатором будем выполнять код

#!/usr/bin/env bash

Тут создаем массив с необходимыми нам данными для подключения к хостам и отправки данных в zabbix

hosts=(10.10.0.1_mik0.host_22 \
       10.10.1.1_mik1.host_22 \
       10.10.2.1_mik2.host_22 \
       10.10.3.1_mik3.host_22 \
       10.10.4.1_mik4.host_22 \
       10.10.5.1_mik5.host_22 \
       10.10.6.1_mik6.host_22 \
       10.10.7.1_mik7.host_22 \
       10.10.8.1_mik8.host_22 \
       10.10.9.1_mik9.host_22 )

Тут думаю только одна переменная нуждается в объяснении — $cmd. Это две команды которые выполняются на Mikrotik последовательно. Первая создает бинарный бекап

вторая создает скрипт с настройками без выгрузки паролей и ключей шифрования.

cdate=`date +%d-%m-%Y` # System date =) Hi Max
dir="/mik_backup/" # Storage for backups
cmd="/system backup save name=backup; export file=backup.rsc hide-sensitive" # command to do the preparation of backup
username="user" # SSH user
zabbix_hp=(10.10.10.10 10051) # IP then PORT
age="30" # remove all backups older then 30 days
itemname="backup" # zabbix item
error_value="1" # error value for trigger
value="0" # good value =)

Основное тело программы. На входе в цикл мы имеем массив содержащийся в переменной $hosts. Цикл работает так — берем первый элемент массива, у нас он равен 10.10.0.1_mik0.host_22 и начинаем с ним работать. Первым же действием мы заносим в переменную $hostname массив созданный из первого элемента массива $hosts. Делаем мы это с помощью команды tr по сути как в python эмитируем действие метода строки .split(). Получается вполне сносно. Мы получаем 3 элемента в массиве $hostname. Первый элемент — ip хоста. Второй элемент — zabbix-hostname. Третий элемент — ssh-port.

Дальше мы обращаемся к этим элементам с помощью индекса, опять же python.

Далее формируем древо каталогов для хранения файлов и указываем scp какие файлы забирать. Прошу не пинать — если кто подскажет как с помощью scp в такой конструкции обращаться к файлам по маске + в карму.

После того как мы получили файлы — отправляем в zabbix сообщение об успехе.

Проверка создания конфига производится простым поиском файла в каталоге назначения. Можно было сделать сравнение md5 на Mikrotik и в каталоге назначения, но это уже другая история, хотя я так делал.

for host in ${hosts[*]} # Get values from main list
do
hostname=($(echo ${host} | tr "_" " ")) # Get values from sub list
ssh ${username}@${hostname[0]} -o "StrictHostKeyChecking no" -p${hostname[2]} "${cmd}"
new_dir="${HOME}${dir}${hostname[1]}/${cdate}"
mkdir -p ${new_dir}
scp -P${hostname[2]} ${username}@${hostname[0]}:backup.backup  ${new_dir}
scp -P${hostname[2]} ${username}@${hostname[0]}:backup.rsc ${new_dir}
check=`find ${new_dir} -type f -name backup.*`
if [ "${check}" == "" ]
then
zabbix_sender -z ${zabbix_hp[0]} -p ${zabbix_hp[1]} -s ${hostname[1]} -k ${itemname} -o ${error_value}
else
zabbix_sender -z ${zabbix_hp[0]} -p ${zabbix_hp[1]} -s ${hostname[1]} -k ${itemname} -o ${value}
fi
done

Тут чистим место. Переменная $age поможет нам сохранить бекапы столько сколько нам этого надо

find ${HOME}${dir} -mindepth 2 -mtime ${age} -type d -exec rm -rf {} \; #clear dirs

Теперь самое тривиальное.

Создаем на сервере zabbix шаблон или просто элемент данных типа zabbix_trapper на наших узлах которые мы заблаговременно добавили на мониторинг в zabbix.

Не буду выкладывать шаблон из одного элемента данных и одного триггера. Думаю сделать его сможет каждый. Главное помнить, если хосты мониторятся через zabbix-proxy, данные вы должны отправлять на zabbix-proxy. В ином случае отправляем все на zabbix-server.

Не важно даже какой будет IP у этих хостов в zabbix web ui. Важно чтобы совпадали hostname с данными в скрипте.

PS. На все скрипты нужно кинуть chmod +x так их можно будет запускать без вызова интерпретатора.

P.S.S Чтобы передавать scp список файлов для резервного копирования на linux можно сделать еще одни массив и вложить его в цикл for. Можно сделать все в виде получаемых параметров. Ну вообщем можно развлечься.

RSA и DSA генерация ключей

Автор Андрей Смирнов На чтение 8 мин. Просмотров 4.3k. Опубликовано 05.07.2017

Научиться настройке MikroTik можно на онлайн курсе по оборудованию этого производителя. Автор курса является сертифицированным тренером MikroTik. Подробней Вы можете прочитать в конце статьи.

Бывают ситуации, когда обычной связки логин и пароль недостаточно: не удовлетворяет внутренней политике безопасности, либо удобству подключения к сетевому оборудованию. Хочется использовать простое, быстрое и вместе с тем надежное и безопасное решение. Кстати, если вы еще не читали о базовых принципах защиты периметра Mikrotik, крайне рекомендую ознакомиться.

Заходим на Микротик без пароля по DSA SSH

Для начала вам необходимо сгенерировать открытый ключ dsa на вашем компьютере с linux (открытый ключ вы в последствие загрузите на Мikrotik).
В системе Linux введите следующую команду:

ssh-keygen -t dsa

Команда создаст пару ключей DSA, совместимую с Mikrotik / Linux
Система попросит ответить на вопросы:

root@desktop:~# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
0a:c1:34:da:d1:b1:f0:b5:f2:39:04:85:9d:d0:ac:2d root@desktop
The key's randomart image is:
+--[ DSA 1024]----+
|        .=o=     |
|        . *.     |
|         .  E    |
|        ..       |
|      . S.o      |
|       + =..     |
|      . =.o      |
|     . o *..     |
|    ..o o +.     |
+-----------------+
root@desktop:~#

Не забудьте оставить парольную фразу пустой, если вы собираетесь использовать этот ключ в автоматизированных сценариях и система не прерывала запуск скрипта запросом пароля.

Загрузка ключа в Mikrotik по FTP

Теперь, когда ключ был создан, пришло время загрузить его в Mikrotik с помощью FTP. Убедитесь, что служба FTP включена на Микротике. Загрузите ключ id_dsa.pub через ftp, используя команды ниже:

root@desktop:~# cd /root/.ssh/
root@desktop:~/.ssh# ftp 192.168.11.30
Connected to 192.168.11.30.
220 MikroTik FTP server (MikroTik 3.3) ready
Name (192.168.11.30:root): admin
331 Password required for admin
Password:
230 User admin logged in
Remote system type is UNIX.
ftp> put id_dsa.pub
local: id_dsa.pub remote: id_dsa.pub
200 PORT command successful
150 Opening ASCII mode data connection for '/id_dsa.pub'
226 ASCII transfer complete
608 bytes sent in 0.00 secs (12007.5 kB/s)
ftp> exit
221 Closing
root@desktop:~/.ssh#

Импортируем DSA ключ

Теперь зайдем на Mikrotik через Winbox и запустим Terminal, вам нужно импортировать ключ. Для импорта ключа используйте команду ниже:

user ssh-keys import file=id_dsa.pub
user: admin

Поле пользователя выше определяет, какая учетная запись пользователя будет регистрироваться при передаче ключа. В этом примере я использую id администратора по умолчанию.
Все сделано. Вы создали пару ключей и импортировали открытый ключ на Mikrotik,

Теперь вы можете запускать команды с удаленного компьютера без использования пароля.

Ниже приведены некоторые примеры из нашего Linux (при первом входе в систему он спросит вас «Вы уверены, что хотите продолжить подключение (да / нет)?» Введите yes для продолжения):

ssh [email protected]  /system resource print
The authenticity of host '192.168.11.30 (192.168.11.30)' can't be established.
DSA key fingerprint is 00:aa:bb:51:8b:1c:c3:df:4d:3c:29:d8:af:48:15:d4.
Are you sure you want to continue connecting (yes/no)? yes

Снова попробуйте выполнить команду, и на этот раз она будет выполняться плавно, не спрашивая ничего.

root@desktop:~# ssh [email protected]  /system resource print
uptime: 40m37s
version: "3.3"
free-memory: 40512kB
total-memory: 62276kB
cpu: "Intel(R)"
cpu-count: 1
cpu-frequency: 3200MHz
cpu-load: 1
free-hdd-space: 956832kB
total-hdd-space: 1021408kB
write-sect-since-reboot: 2373
write-sect-total: 2373

Вы можете сделать много интересного, используя этот метод: связать скрипты с php или webmin и управлять своим mikrotik с помощью webmin в качестве фронт энда.

Настраиваем доступ к SSH с помощью открытого ключа RSA на маршрутизаторе MikroTik

В RouterOS 6.31 MikroTik представил поддержку ключей RSA для аутентификации, поэтому я решил протестировать ее. Аутентификация с открытым ключом SSH на RouterOS с использованием ключей DSA поддерживается уже давно. Этот учебник MikroTik проведет вас через процесс настройки аутентификации с помощью ключей RSA. Этот урок состоит из трех статей в одной, выберите ту, которая соответствует вашей среде. SSH с хоста Linux, Putty в Windows или SecureCRT в Windows.

Генерация пары ключей RSA в Ubuntu Linux

Шаг 1. Запуск ssh-keygen

user@linux:~$ ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (/home/osboxes/.ssh/id_rsa):
Created directory '/home/osboxes/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/osboxes/.ssh/id_rsa.
Your public key has been saved in /home/osboxes/.ssh/id_rsa.pub.
The key fingerprint is:
8e:1e:a0:85:b9:1f:f4:80:a8:89:cd:a8:ae:99:db:48 osboxes@osboxes
The key's randomart image is:
+---[RSA 2048]----+
| |
| |
| |
| . + |
|. + = S |
|o= = + o |
|=E= . + . |
|o= . o . |
|Xo. . . |
+-----------------+

Шаг 2. Копирование открытого ключа на маршрутизатор MikroTik.

user@linux:~$ scp ~/.ssh/id_rsa.pub [email protected]:mykey.pub

The authenticity of host '192.168.1.99 (192.168.1.99)' can't be established.
RSA key fingerprint is aa:25:f6:25:12:f1:57:9b:97:1c:b6:af:dd:f2:97:e4.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.99' (RSA) to the list of known hosts.
[email protected]'s password:
id_rsa.pub 100% 397 0.4KB/s 00:00

user@linux:~$ scp ~/.ssh/id_rsa.pub [email protected]:mykey.pub

Генерация пары ключей RSA с использованием SecureCRT (Windows)

Важно! Если вы уже создали закрытый / открытый ключ с помощью SecureCRT, убедитесь, что вы сделали резервную копию своих ключей или просто используете существующую пару ключей.

1. Прежде чем начать, выберите «Параметры | Глобальные параметры | SSh3 ”из меню, чтобы увидеть, если вы уже сгенерировали и настроили пару ключей SSH.
2. Выберите “Инструменты | Создать открытый ключ…”
3. Нажмите кнопку “Далее”
4. Выберите RSA в нашем случае
5. Оставьте поле пустым для аутентификации без пароля
6. Используйте длину ключа 2048
7. Нажмите «Далее» после генерации ключа RSA.
8. Выберите, где сохранить пару ключей, например, папку «Мои документы» с именем «sshkeys».

Создаем пару ключей SSH, используя PuTTY’s puttygen.exe (Windows)

1. Нажмите «Win+R», в строке пропишите «C:\Program Files (x86)\PuTTY\puttygen.exe», нажмите Enter
2. Убедитесь, что тип ключа — «SSH-2 (RSA)», а длина ключа — «2048». Нажмите «Создать».
3. Выберете «Сохранить закрытый ключ» и «Сохранить открытый ключ», чтобы сохранить каждый отдельности. В нашем случае папка называется «Мои документы» \ sshkeys и открытый ключ — «puttykey.pub».

Установка открытого ключа RSA и привязка к пользователю

Шаг 1. Используйте winbox, чтобы убедиться, что файл был скопирован на маршрутизатор

Шаг 2а. Импортируйте открытый ключ с помощью Winbox.

Шаг 2б. Импортируем открытый ключ с помощью командной строки

[admin@MikroTik] > /user ssh-keys import public-key-file=mykey.pub user=admin

Проверяем полученный результат:

[admin@MikroTik] > /user ssh-keys print

Flags: R - RSA, D - DSA
# USER BITS KEY-OWNER
0 R admin 2048 admin@host

Проверяем свою конфигурацию, подключившись по SSH

user@linux:~$ ssh [email protected]

[admin@MikroTik] >

Отлично! Подключаемся без пароля

Как экспортировать конфигурацию маршрутизатора с использованием SSH

user@linux:~$ ssh [email protected] /export > myconfig.rsc

user@linux:~$ head myconfig.rsc

# sep/10/2015 10:46:44 by RouterOS 6.31
# software id = 0340-0M77
#
/ip address
add address=192.168.1.99/24 interface=ether1 network=192.168.1.0
/ip dhcp-client
add dhcp-options=hostname,clientid interface=ether1
...

И снова никаких паролей!

Как создать бинарную резервную копию и перенести с помощью SCP

user@linux:~$ ssh [email protected] /system backup save name=myrouter.backup
Configuration backup saved

user@linux:~$ scp [email protected]:/myrouter.backup ./
myrouter.backup 100% 18KB 18.1KB/s 00:00

user@linux:~$ ls -al myrouter.backup
-rw-r----- 1 osboxes osboxes 18573 Sep 11 04:35 myrouter.backup

Комментарии приветствуются.

MikroTik: куда нажать, чтобы заработало?
При всех своих достоинствах, есть у продукции компании MikroTik один минус – много разобщенной и далеко не всегда достоверной информации о ее настройке. Рекомендуем проверенный источник на русском языке, где все собрано, логично и структурировано – видеокурс «Настройка оборудования MikroTik». В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект. Все материалы остаются у вас бессрочно. Начало курса можно посмотреть бесплатно, оставив заявку на странице курса. Автор курса является сертифицированным тренером MikroTik.

MikroTik RouterOS API для Python

В рамках этой статьи будет рассматриваться взаимодействие с устройством через специальный программный интерфейс управления (API — application programming interface). По функциональности этот интерфейс аналогичен конфигурации устройства через telnet или ssh. Отличие состоит в том, что telnet и ssh относятся к интерфейсам взаимодействия устройства и человека, а API — взаимодейтствия устройства и устройства, т.е. MikroTik API как нельзя лучше подходит для целей автоматизации.

Ранее было сказано, что в качестве языка программирования при демонстрации работы с API RouterOS будет использоваться Python 3. RouterOS API Python 3 поддерживает взаимодействие с сетевыми устройствами через протоколы telnet и ssh, однако работа с этими модулями трудоёмка, например, результат выполнения команды необходимо выделять с помощью регулярного выражения из общего ответа устройства. Одним из модулей, который значительно упрощает взаимодействие с сетевыми устройствами, является модуль netmiko, однако на текущий момент в нём не реализована поддержка RouterOS. Синтаксис языка Python 3 в рамках статьи рассматриваться не будет.

Для взаимодействия с устройством необходимо включить поддержку API непосредственно на устройстве, перейдя в раздел “/ip services”. По-умолчанию API работает через порт 8728. Кроме того, RouterOS поддерживает защищённый вариант программного интерфейса API over SSL (api-ssl по-умолчанию использует порт 8729).

Разработчики RouterOS не предоставили библиотеки для работы через API для популярных языков программирования, однако описали протокол взаимодействия в официальной документации. Помимо описания протокола взаимодействия представлены примеры программ, в том числе для языка Python 3.

Взяв за основу файл с примером, при подготовке статьи был описан файл с классом ApiRos, позволяющий выполнить подключение и взаимодействие с устройством через API. Помимо этого, были добавлены три функции: для открытия/закрытия сокета и вывода ответа устройства на экран. При демонстрации будут использованы следующие функции и классы:

• libapi — файл библиотеки, подготовленный для статьи. Файл содержит основные функции и классы для взаимодействия с устройством;
• ApiRos — класс устройств под управлением RouterOS;
• socketOpen — функция открытия сокета;
• socketClose — функция закрытия сокета;
• login — функция авторизации на устройстве;
• writeSentence — функция отправки команды на устройство;
• readResponse — функция получения результата выполнения команды с устройства.

Следует упомянуть о формате команд, т.к. он отличается от синтаксиса, используемого при конфигурации вручную. Команды вводятся в виде списка, где первый элемент — команда, в которой пробелы заменяются на символ “/”, а последующие элементы уточняют запрос:

1. команды просмотра: фильтр запроса начинается с вопросительного знака, после чего следует текст фильтра, например “?type=ether”. Уточняющих команд может быть несколько;
2. команды изменения конфигурации: фильтр начинается с символа равенства, после чего следует имя параметра и его значение, например “=name=ISP1”. Уточняющих команд может быть несколько.

Демонстрация работы с API

Составим программу для получения списка IP-адресов на устройствах R2 и R3. Листинг программы ip_get.py с комментариями представлен ниже.

Листинг ip_get.py

import libapi

devices = [

      { ‘ip’: ‘172.16.16.13’,

      ‘login’: ‘user’,

      ‘pass’: ‘user’},

      { ‘ip’: ‘172.16.16.12’,

      ‘login’: ‘spw’,

      ‘pass’: ‘spw’}]

for device in devices:

      print(«Connect to {}:».format(device[‘ip’]))

      #Создание сокета и объекта устройства

      s = libapi.socketOpen(device[‘ip’])

      dev_api = libapi.ApiRos(s)

      #Авторизация на устройстве

      if not dev_api.login(device[‘login’], device[‘pass’]):

            break

      #Список команд

      command = [«/ip/address/print»]

      #Выполнение команды на устройстве

      dev_api.writeSentence(command)

      #Получение результата выполнения команды

      res = libapi.readResponse(dev_api)

      #Закрытие сокета

      libapi.socketClose(s)

      #Форматированный вывод результата команды

      print(»    Command result:»)

      print(»        {:^18} {:10}».format(‘IP’, ‘Interface’))

      for element in res:

            print(»        {:18} {:^10}».format(element[2].split(‘=’)[2],

                  element[4].split(‘=’)[2])) 

      print(»)

Принцип работы программы заключается в следующем:

• в словаре devices описаны реквизиты доступа к R2 и R3;
• в цикле обрабатывается словарь devices и выполняется подключение к каждому из устройств;
• после подключения на устройстве выполняется команда “/ip address print”;
• результат выполнения команды сохраняется в переменную res;
• закрывается подключение к устройству;
• выполняется форматированный вывод содержимого переменной res.

Результат выполнения программы представлен на рисунке 3.8:

Рисунок 3.8 — Результат выполнения программы ip_get.py

В конфигурации устройств присутствует только по одному ip-адресу, что видно на рисунке. Следует обратить внимание, что средства Python позволяют формировать вывод полученной информации так, как этого требует решаемая задача. Кроме того, полученные данные могут быть записаны в файл или быть использованы в других программах.

Пусть администратор сети решил насроить OSPF, выделив для идентификаторов Router-id адреса из сети 10.52.52.0/24. Для R2 выбран идентификатор 10.52.52.12, а для R3 10.52.52.13.

Составим программу, которая будет создавать для OSPF bridge-интерфейс и ассоциировать созданный интерфейс с выделенным IP-адресом. Листинг программы ip_add.py представлен ниже:

Листинг ip_add.py

import libapi

devices = [

      { ‘ip’: ‘172.16.16.13’,

      ‘login’: ‘user’,

      ‘pass’: ‘user’},

      { ‘ip’: ‘172.16.16.12’,

      ‘login’: ‘spw’,

      ‘pass’: ‘spw’}]

new_network = ‘10.52.52.{}/32’

new_interface = ‘br_ospf’

for device in devices:

      print(«Connect to {}:».format(device[‘ip’]))

      #Создание сокета и объекта устройства

      s = libapi.socketOpen(device[‘ip’])

      dev_api = libapi.ApiRos(s)

      #Авторизация на устройстве

      if not dev_api.login(device[‘login’], device[‘pass’]):

            break

      #Команда для добавление bridge-интерфейса

      command = [«/interface/bridge/add», «=name={}».format(new_interface)]

      #Выполнение команды на устройстве

      dev_api.writeSentence(command)

      #Получение результата выполнения команды

      res = libapi.readResponse(dev_api)

      #Команда для добавления IP-адреса на bridge-интерфейс

      command = [«/ip/address/add»,

            «=address={}».format(new_network.format(device[‘ip’].split(‘.’)[3])),

            «=interface={}».format(new_interface)]

      #Выполнение команды на устройстве

      dev_api.writeSentence(command)

      #Получение результата выполнения команды

      res = libapi.readResponse(dev_api)

      #Закрытие сокета

      libapi.socketClose(s)

Результат выполнения программы ip_add.py представлен на рисунке 3.9:

Рисунок 3.9 — Результат выполнения программы ip_add.py

Несмотря на то, что в переменную res записывался результат применения команды, она не использовалась в текущей программе. Убедимся, что ip-адреса успешно добавлены, запустив программу ip_get.py:

Рисунок 3.10 — Результат выполнения программы ip_get.py

По результату работы программы видно, что программа ip_add.py выполнила действия согласно поставленной задаче: создан bridge-интерфейс и он ассоциирован с IP-адресом из выделенной сети.

Составим программу, выполняющую передачу файла script_spw на маршрутизаторы R2 и R3. Для этого нет необходимости использовать API, можно успешно реализовать это с помощью стандартных средств Python, выполнив подключение к устройствам по FTP (поддержка FTP должна быть предварительно активирована на устройствах). Листинг программы file_add.py представлен ниже.

Листинг file_add.py

import ftplib

devices = [

      { ‘ip’: ‘172.16.16.13’,

      ‘login’: ‘user’,

      ‘pass’: ‘user’},

      { ‘ip’: ‘172.16.16.12’,

      ‘login’: ‘spw’,

      ‘pass’: ‘spw’}]

filename = ‘script_spw’

for device in devices:

      print(«Connect to {}:».format(device[‘ip’]))

      with ftplib.FTP(device[‘ip’], device[‘login’], device[‘pass’]) as con:

            with open(filename, «rb») as f:

                  send_file = con.storbinary(«STOR » + filename, f)

                  print(»    File transfer: done»)

Выполним программу, после чего выполним программу, которая выводит список файлов на устройствах (по аналогии с программой ip_get.py). Результат выполнения представлен на рисунке 3.11:

Рисунок 3.11 — Результат выполнения программы file_add.py

На рисунке видно, что изначально на устройствах присутствуют две директории pub и skins, созданные по-умолчанию, а после успешного выполнения программы file_add.py, на устройствах появляется файл script_spw.

Составим программу, выполняющую загрузку файлов с устройств по протоколу FTP. Листинг программы file_get.py:

Листинг программы file_get.py

import ftplib

devices = [

      { ‘ip’: ‘172.16.16.13’,

      ‘login’: ‘user’,

      ‘pass’: ‘user’},

      { ‘ip’: ‘172.16.16.12’,

      ‘login’: ‘spw’,

      ‘pass’: ‘spw’}]

filename_pattern = ‘backup_{}.backup’

for device in devices:

      print(«Connect to {}:».format(device[‘ip’]))

      filename = filename_pattern.format(device[‘ip’])

      with ftplib.FTP(device[‘ip’], device[‘login’], device[‘pass’]) as con:

            with open(filename, «wb») as f:

                  con.retrbinary(‘RETR ‘ + filename, f.write)

                  print(»    File transfer: done»)

Перед выполнением программы file_get.py выполним backup на всех устройствах, изменив команду в программе ip_add.py. Имя backup-файла будет соответствовать следующему шаблону: “backup_*IP-адрес*.backup”. Результат выполнения программы file_get.py представлен на рисунке 3.12.

Рисунок 3.12 — Результат выполнения программы file_get.py

После выполнения программы file_get.py в текущей директории появились два файла backup_172.16.16.12.backup и  backup_172.16.16.13.backup, в соответствии с задачей.

Скрипты Ansible в MikroTik RouterOS

СКРИПТЫ, ВЫПОЛНЯЕМЫЕ НА ЛОКАЛЬНОМ УСТРОЙСТВЕ

Использование Ansible

Ansible является системой управления конфигурациями, изначально создаваемой для управления серверной инфраструктурой, однако, в процессе развития в систему были добавлены модули для работы с сетевым оборудованием различных производителей.

К сожалению, в сравнении с серверами, функционал Ansible для работы с сетевым оборудованием достаточно скромен, но выполнение базовых операций поддерживается. Например, одним из принципов системы Ansible является его иммутабельность, т.е., если на сервере установлен желаемый пакет и администратор повторит запуск задания на установку этого пакета, то Ansible это распознает и задание выполнять не будет. Это было бы удобно использовать и для конфигураций сетевого оборудования, однако такой функционал пока не реализован.

Скрипты Ansible поддерживают два режима работы: ad-hoc команды и playbook. Ad-hoc команды предназначены для выполнения разового действия с устройствами или группой устройств и выполняется из командной строки. Playbook представляет собой файл сценария, состоящий из нескольких задач, выполняемых последовательно. Для каждой из задач может быть определён набор параметров и задачи могут выполняться зависимо, например, если первая задача выполнилась с ошибкой, то последующие задачи выполняться не будут.

Независимо от режима работы, выполнение задачи вызывается из модуля. Набор модулей устанавливается вместе с Ansible и делится на две части: работа базовых модулей гарантирована при развитии системы и выходе новых версий продукта, поддержка дополнительных модулей в будущих версиях Ansible не гарантируется. В демонстрационных примерах будут использоваться модули net_put и net_get для отправки и получения файла с устройства соответственно, а также модуль routeros_command для отправки команд. Вывод результатов будет выполнен с помощью связки модулей register и debug.

Схема работы

Схема работы Ansible представлена на рисунке 3.1.

Рисунок 3.1 — Схема работы Ansible

Алгоритм работы Ansible выглядит следующим образом:

1. Администратор запускает задание в Ansible;
2. Ansible выполняет параллельное подключение к списку устройств, указанных в задании. Число параллельных сессий по умолчанию равно 5, подключение выполняется по протоколу SSH, поддерживается соединение через логин/пароль и сертификат;
3. Ansible выполняет сбор информации об устройстве;
4. Ansible выполняет задание;
5. Если заданий на выполнение больше нет, то Ansible отключается от устройства, если есть — выполняются последующие задания.

Поскольку работа Ansible выполняется через протокол SSH, то необходимо, что на устройствах была активирована поддержка этого протокола и не выполнялось блокировки подключения в файрволе.

Существует возможность подключения Ansible к устройствам через протокол telnet. Для этого в задании следует использовать модуль telnet, однако в рамках данной статьи будет использоваться способ «по умолчанию».

Файловая структура

Для работы Ansible требуется определить набор параметров. Параметры можно разделить на два типа: набор конфигурационных параметров и набор пользовательских параметров.

Конфигурационные параметры системы хранятся в файле ansible.cfg, который расположен в директории, из которой вы запускаете Ansible. Если нет необходимости, то конфигурационные параметры можно не определять, в этом случае будут использоваться параметры по-умолчанию. В рассматриваемых примерах будет использоваться файл следующего содержания:

Листинг ansible.cfg

[defaults]

inventory = ./hosts

Первая строка указывает на использование параметров по-умолчанию, а вторая на переопределение параметра inventory. Данный параметр определяет путь к файлу со списком устройств.

Набор пользовательских параметров определяется задачами, которые будут выполняться с помощью Ansible. Минимально необходимый список параметров — inventory-файл со списком устройств, в рассматриваем случае используется файл hosts.

Листинг hosts

[routers]

172.16.16.14

172.16.16.13

172.16.16.12

Inventory-файл позволяет создать группы устройств, в которые включить IP-адреса или доменные имена, а также группы, состоящие из групп устройств. В дальнейшем, при выполнении задач нет нужды перечислять все адреса устройств, для которых необходимо выполнить это задание, достаточно указать название группы. В рассматриваемом случае создана группа routers, в которую включены маршрутизаторы, указанные на рисунке 3.1.

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

Переменные группы должны быть расположены в файле с названием группы в директории group_vars, а переменные хоста в файле с адресом хоста директории host_vars. В рассматриваемой задаче подключение будет выполняться с помощью логина и пароля, для устройств R3 и R4 используется пользователь user/user, а для R2 — spw/spw. Структура размещения файлов представлена на рисунке 3.2.

Листинг routers.yml

ansible_connection: network_cli

ansible_network_os: routeros

ansible_user: user

ansible_password: user

Листинг 172.16.16.12.yml

ansible_user: spw

ansible_password: spw

Рисунок 3.2 Демонстрация примеров

Демонстрация примеров будет выполнена через playbook, которые расположены в директории, из которой будет запущен Ansible (см. рисунок 3.2). К playbook относятся файлы data_get.yml, data_set.yml, file_get.yml, file_set.yml.

Файлы с пользовательскими параметрами и playbook оформляются, как YAML-структура. Следует обратить внимание, что структура таких файлов чувствительна к синтаксису, причём пробелы и отступы тоже являются частью синтаксиса.

Установка Ansible

Управляющий хост с Ansible должен быть под управлением ОС Linux. На официальном сайте Ansible представлена подробная документация по установке, использованию и модулям системы (https://docs.ansible.com/). Один из русскоязычных материалов по первым шагам в Ansible представлен по ссылке: https://natenka.gitbooks.io/pyneng/content/book/Part_VI.html.

Демонстрация работы Ansible

При рассмотрении практических примеров будет использована схема сети, представленная на рисунке 3.1, набор и содержимое конфигурационных файлов, рассмотренные в этом разделе.

Конфигурация маршрутизаторов, используемых в демонстрационном стенде:

R2:

/ip address

add address=172.16.16.12/28 interface=ether1 network=172.16.16.0

/system identity

set name=R2

/user

add name=spw password=spw group=full

R3:

/ip address

add address=172.16.16.13/28 interface=ether1 network=172.16.16.0

/system identity

set name=R3

/user

add name=user password=user group=full

R4:

/interface bridge port

add bridge=bridge1 interface=ether3

add bridge=bridge1 interface=ether4

add bridge=bridge1 interface=ether5

add bridge=bridge1 interface=ether2-master

add bridge=bridge1 interface=wlan1

/ip address

add address=172.16.16.14/28 interface=ether1 network=172.16.16.0

/system identity

set name=R4

/user

add name=user password=user group=full

Вывод информации об устройстве

Составим playbook, который будет выполнять на маршрутизаторах команду “/system routerboard print” и результат выполнения выводить в терминал командной строки. Текст playbook data_get.yml приведён ниже.

Листинг data_get.yml

— name: Getting data from routers

  hosts: routers

  gather_facts: false

  tasks:

    — name: system command

      routeros_command:

        commands: /system routerboard print

      register: system_print

    — name: debug print

      debug: var=system_print.stdout_lines

В первом блоке содержатся параметры, применяемые ко всему playbook. В частности, указано его описание, определён список устройств, к которым он будет применён и отключен сбор фактов (см. алгоритм работы Ansible).

Далее идёт блок со списком задач. Первая задача использует модуль routeros_command и в качестве параметра этой задаче передаётся строка команды, которую нужно выполнить. Результат выполнения запоминается с помощью модуля register. Обратите внимание, что в рамках одной задачи может использоваться несколько модулей.

Вторая задача описывает вывод на экран результата работы, который был зафиксирован на предыдущем этапе в переменной system_print. Для вывода используется модуль debug.

Результат выполнения playbook представлен на рисунке 3.3. Видно, что playbook был успешно выполнен по отношению ко всем устройствам группы routers. Также можно отметить, что для R2 и R3 параметр “routerboard: no”, т.к. в роли этих маршрутизаторов используются CHR.

Рисунок 3.3 Результат выполнения playbook data_get.yml

Отправка файла на устройство

Составим playbook, который будет загружать файл предварительно сформированного скрипта spw_script на устройство R4. Содержимое playbook file_set.yml представлено ниже.

Листинг file_set.yml

— name: Set file to router

  hosts: 172.16.16.14

  gather_facts: false

  tasks:

    — name: file upload

      net_put:

        src: ./spw_script

        protocol: sftp

    — name: File demonstate after

      routeros_command:

        commands: /file print

      register: file_after

    — name: debug print after

      debug: var=file_after.stdout_lines

В отличии от playbook, рассмотренного ранее, здесь определён только один хост 172.16.16.14, а не группа хостов routers.

В разделе с заданиями представлено три задачи: первая выполняет загрузку файла скрипта с использованием модуля net_put, вторая выполняет команду отображения списка файлов, а третья выводит результат работы на экран.

Результат выполнения playbook представлен на рисунке 3.4. Видно, что модуль net_put выполняет изменения на устройстве, поэтому отображается оранжевым цветом. Это же указывается в конце выполнения “playbook – changed=1”. Кроме того, можно видеть, что в списке файлов на устройстве появился загружаемый файл.

Playbook выполнен два раза для того, чтобы продемонстрировать иммутабельность модуля net_put. Поскольку файл уже существует, то Ansible не выполняет повторную загрузку.

Рисунок 3.4 Результат выполнения playbook file_set.yml

Получение файла с устройства

Сформируем playbook, который будет создавать backup на устройстве R2 и выполнять его загрузку в директорию, из которой запускается Ansible. Содержимое playbook file_get.yml представлено ниже.

Листинг file_get.yml

— name: Save file from router

  hosts: 172.16.16.12

  gather_facts: false

  tasks:    

    — name: backup-file create

      routeros_command:

        commands: /system backup save name=backup_spw

    — name: backup-file download

      net_get:

        src: backup_spw.backup

        protocol: sftp

Первая задание выполняет на устройстве R2 сохранение backup-файла, а второе задание скачивает созданный файл с устройства. Результат выполнения playbook представлен на рисунке 3.5.

Рисунок 3.5 Результат выполнения playbook file_get.yml

Выполнение команды

Составим playbook, создающий на устройствах группы routers bridge-интерфейс. Содержимое playbook data_set.yml представлено ниже.

Листинг data_set.yml

— name: Create bridge-interfaces

  hosts: routers

  gather_facts: false

  tasks:   

    — name: Create bridge

      routeros_command:

        commands:

          — /interface bridge add name=br_spw

          — /interface bridge print

      register: bridge_print

    — name: debug print

      debug: var=bridge_print.stdout_lines

Первое задание выполняет две команды на маршрутизаторах: первая команда создаёт bridge-интерфейс с именем br_spw, а вторая выводит список созданных bridge-интерфейсов. Следует обратить внимание, что в рамках одного задания может быть выполнено несколько команд, в этом случае команды должны быть переданы как список. Вторая команда выводит результат работы на экран.

Результат выполнения playbook представлен на рисунке 3.6. Можно заметить, что bridge-интерфейсы успешно созданы, в соответствии с целью playbook.

Рисунок 3.6 Результат выполнения playbook data_set.yml

Результат повторного выполнения playbook data_set.yml представлен на рисунке 3.7. Следует обратить внимание, что модуль routeros_command не обладает иммутабельностью: несмотря на то, что интерфейс br_spw уже создан, Ansible выполняет описанные команды, о чём свидетельствует выводимое сообщение об ошибке.

Рисунок 3.7 Результат повторного выполнения playbook data_set.yml

В демонстрационных примерах пароль для доступа хранится в открытом доступе в файле с пользовательскими переменными. Это является не самым безопасным решением. Использование ключа “-k” при запуске playbook позволит запрашивать пароль перед выполнением заданий. Кроме того, для доступа к устройствам можно использовать заранее сгенерированные сертификаты.

Делаем доступ к Mikrotik по SSH ключу

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

Кстати, на правах рекламы, хочу порекомендовать магазин сетевого оборудования: antelecs.ru, все эксперименты используются именно на микротах с этого магазина.

Зачем нужна авторизация по SSH

Как зачем? Для повышения безопасности.Во-первых, плюсы SSH-протокола перед Telnet очевидны. Шифрование. Во-вторых, почему именно ключ? Ключевой файл (приватный ключ) при нормальном хранении получить злоумышленнику намного сложнее, чем пароль. Даже ввиду размера. Брут неэффективен от слова «совсем».

А если защитить файл приватного ключа паролем, то и вовсе безопасность будет выше.

При этом не стоит забывать о простых вещах — как минимум переименовать администратора во что-то менее тривиальное, чем «admin».Отключить лишние сервисы (http, telnet), а сам ssh можно перевесить на другой порт.

Вдобавок впесочить ещё Port Knocking, тогда попасть в ваш Mikrotik злоумышленнику будет куда тяжелее!

Генерируем ключи

Для генерации пары ключей (открытый публичный и закрытый — закрытый) мы воспользуемся утилиткой puttygen.exe, входящей в состав привычного SSH-клиента PuTTY. Главное окно программы выглядит вот так:

Выбираем тип ключа — SSH-2 RSA и длину ключа в битах, я оставил 2048 бит.На выходе, кстати, иногда получается ключ длиной 2047 бит, это не бага, особенность работы алгоритма RSA — не стоит о ней волноваться.

Кстати, вспомнилось как-то, как на Pascal в институте писал мониторингма RSA — может быть повторю как-нибудь на страницах нашего сайта, весьма любопытно было.

Итак, нажимаем кнопку “Generate” и начинаем елозить мышью по окну. Не поймите меня буквально

Когда процесс генерации будет завершён, увидим окно подобное этому:

Теперь нужно скопировать публичный ключ из поля [1] в произвольный текстовый файл.

Важно . Не пользуйтесь кнопкой «Сохранить открытый ключ», т.к. puttygen поддерживает ключ в своём формате, который плохо совместим с нормальными ssh-сервисами.

А вот приватный ключ мы сохраним на соответствующую кнопку. Итак, на выходе у вас должно получиться 2 файла: публичный ключ, сохранённый из текстового поля и приватный ключ, сохранённый посредством кнопки.

Импортируем ключи в Mikrotik

Входим в Mikrotik 12 сообщений для нас способом.Я в конкретном использовании воспользовался WinBox.

Переходим в раздел Files и перетаскиваем туда публичный ключ !

Теперь нужно добавить этот ключ в раздел «Система -> Пользователи». Переходим на вкладку «SSH-ключи» и нажимаем на кнопку «Импортировать SSH-ключ».

В появившемся окне указанное имя пользователя, соответствующий соответствующий ключ, появится также файл ключа (появится выпадающий список). Затем нажимаем кнопку «Импортировать SSH-ключ» уже в диалоговом окне и всё.Ключ установлен.

Входим в систему

Для входа в систему воспользуемся, как я уже упоминал, PuTTY. Создадим новое подключение, указав IP-адрес и порт, затем перейдём на следующую вкладку:

Раздел «Подключение -> SSH -> Auth», в поле «Файл закрытого ключа для аутентификации» добавим наш приватный ключ . Жмём «Открытый».

После появления стандартного диалогового окна добавляем ключ в кеш.

В окне терминала введём имя пользователя «dmitry» и сразу (без пароля!) Попадаем в консоль Mikrotik.Для обеспечения наилучшей безопасности, конечно, хорошо бы использовать пароль на ключ (во время генерации ключа указывается). Но это уже детали!

Всем удачи! Будьте осторожны!

Если вам понравилась эта статья — поставьте лайк! Так я буду знать стоит ли писать ещё на службу тематику. Лучшая награда писателя — отклик от читателей. Заранее благодарю.

.

Mikrotik и ssh — Всяко разно

Утилита plink позволяет через консоль подключаться по протоколу SSH. Plink будем использовать для отправки команд Mikrotik-у. Найти утилиту можно установив PuTTY и вызвав консоль.

В зависимости от разрядности операционной системы пути будут следующие:

• для версии х64: «C: \ Program Files \ PuTTY \ plink.exe»
• для версии х86: «C: \ Program Files (x86) \ PuTTY \ plink.exe»

Открытие SSH на Mikrotik (через межсетевой экран):

/ ip фильтр межсетевого экрана
add action = accept chain = input comment = «SSH» dst-port = 22 protocol = \
udp src-адрес = 192.168. *. * / **

Включаем встроенный сервис SSH:

/ ip сервис
установить ssh-адрес = 192.168. *. * / * отключено = no

Правила в брандмауэре.

Включение правил:

plink 192.168. *. * -ssh -P 22 -l login-admin -pw P @ ssW0Rd -2-4 «/ ip firewall filter;: для x от 5 до 7 do = {/ ip firewall filter set $ x disabled = no} «

с 5 по 7 — с какого по какое правило в брандмауэре.

Отключение правил:

plink 192.168. *. * -ssh -P 22 -l login-admin -pw P @ ssW0Rd -2-4 «/ ip firewall filter;: для x от 5 до 7 do = {/ ip firewall filter set $ x disabled = yes} «

Простые очереди (ограничение скорости).

Включение:

plink 192.168. *. * -ssh -P 22 -l login-admin -pw P @ ssW0Rd -2-4 «/ queue simple enable 0»

Ноль в конце команды означает номер строки в правиле.

Отключение:

Пинк 192.168. *. * -Ssh -P 22 -l login-admin -pw P @ ssW0Rd -2-4 «/ queue simple disable 0»

Обозначения.

192.168. *. * — адрес микротик.

login-admin — логин для mikrotik.

P @ ssW0Rd — пароль.

192.168. *. * / ** — адрес сети.

.

Прозрачный вход по ssh на устройство Mikrotik

Прочитано:
5 549

Хочу по аналогии с моими доверенными системами ( Ubuntu 12.04 / 14.04 Server ) подключиться и к устройствам Mikrotik задействуя ssh .

Все дальнейшие действия происходят на моей рабочей / домашней системе Ubuntu 12.04.5 Desktop amd64 ноутбук Lenovo ThinkPad E555 .

Первым делом активирую службу удаленного безопасного подключения через SSH (порт 22) (и FTP, порт 21) на устройстве Mikrotik

Экзорчик @ navy: ~ $ winbox - 192.168.1.9 - IP - Услуги — находим где присутствует надпись ssh & ftp и если строка затемнена активируем. Затем отключаемся от Mikrotik ‘а.

Далее на системе Ubuntu генерируем / проверяем пары публичного ключа хоста и приватного:

экзорчик @ флот: ~ $ ssh-keygen -t dsa

Экзорчик @ флот: ~ $ ls .ssh / id_dsa *

.ssh / id_dsa .ssh / id_dsa.паб

После чего передаем публичный ключ на устройство mikrotik следующим образом:

экзорчик @ флот: ~ $ cp /home/ekzorchik/.ssh/id_dsa.pub iddsa

экзорчик @ флот: ~ $ ftp 192.168.1.9

Подключен к 192.168.1.9.

220 экзорчик FTP сервер (MikroTik 6.33.5) готов

Имя (192.168.1.9:экзорчик): экзорчик

331 Требуется пароль для экзорчика

Пароль:

230 Пользователь экзорчик вошел в систему

Тип удаленной системы — UNIX.

футов>

передаю файл публичного ключа на микротик :

ftp> положить iddsa

локальный: iddsa удаленный: iddsa

200 Команда PORT выполнена успешно

150 Открытие соединения для передачи данных в режиме ASCII для ‘/ iddsa’

226 Передача ASCII завершена

605 байтов отправлено за 0,00 секунды (13427,7 кБ / с)

ftp> пока

221 Закрытие

подключаюсь к устройству mikrotik через winbox , открываю консоль строки и скопированный выше файл отпечатка системы Ubuntu 12.04.5 Desktop amd64 импортирую в хранилище ключей удаленного доверенного доступа устройства Mikrotik :

ekzorchik @ navy: ~ $ winbox - 192.168.1.9 (Логин: admin, Пароль = 712mbddr @) - Новый Терминал -

[admin @ ekzorchik]> пользовательские ssh-ключи импортируют файл публичных ключей = iddsa

На заметку: если на устройстве Mikrotik заведен еще один пользователь с правами Администратора , то тогда нужно указать что публичный ключ с системой Ubuntu (на которой запускалась команда ssh-keygen -t dsa ) применима для этого пользователя :

экзорчик @ флот: ~ $ ssh-keygen -t dsa

[ekzorchik @ ekzorchik]> user ssh-keys import public-key-file = iddsa user = ekzorchik

На заметку: импортировать ключ на устройство Mikrotik можно также не подключаться через winbox , а просто подключить из сети с помощью утилиты telnet :

ekzorchik @ navy: ~ $ telnet 192.] ’.

MikroTik v6.33.5 (стабильный)

Логин: ekzorchik

Пароль:

[ekzorchik @ ekzorchik]> user ssh-keys import public-key-file = iddsa user = ekzorchik

[admin @ ekzorchik]> выйти

прервано

Отлично, теперь реализовю как будет происходить аутентификация с системы Ubuntu 12.04.5 Desktop amd64 на устройстве mikrotik при безопасном подключении через ssh :

Экзорчик @ navy: ~ $ ssh -l Экзорчик 192.168.1.9

Подлинность хоста «192.168.1.9 (192.168.1.9)» не может быть установлена.

Отпечаток ключа

RSA: 38: 67: 29: 0f: ad: 91: 6a: 95: 68: 80: f7: 4a: be: 5c: 61: 2d.

Вы уверены, что хотите продолжить соединение (да / нет)? Есть

Предупреждение: «192.168.1.9» (RSA) постоянно добавляется в список известных хостов.

[email protected] пароль:

[ekzorchik @ ekzorchik]> системный маршрутизатор для печати

;;; Прошивка успешно обновлена, пожалуйста, перезагрузитесь для изменений

вступит в силу!

routerboard: есть

модель: 2011UiAS-2HnD

серийный номер: 614A052CFEA6

тип прошивки: ar9344

текущая прошивка: 3.24

обновление прошивки: 3.24

Выхожу и пробую подключить еще раз, пароль при подключении спрашиваться не должен:

[ekzorchik @ ekzorchik]> бросить

прервано

Подключение к 192.168.1.9 закрыто.

Экзорчик @ ВМФ: ~ $ ssh -l Экзорчик 192.168.1.9

[email protected] пароль:

хм, странно - а почему у меня все же происходит запрашивание пароля, опять документация по настройке врет или же просто многое якобы само собой разумеющееся опускается, я же в свою очередь хочу все для себя разобрать:

Оказалось все очень просто, до этого я обновлял устройство и по окончании процедуры не перезагрузил устройство, кстати, в выводе выше как раз присутствует информационное сообщение, что устройство обновлено и для активации изменений его нужно перезагрузить.Перезагрузив, пробую подключиться и вуаля - подключение через ssh происходит без какого либо запроса пароля, как раз то что мне и нужно было:

Экзорчик @ ВМФ: ~ $ ssh -l Экзорчик 192.168.1.9

192.168.1.9 через ssh

[ekzorchik @ ekzorchik]>

[ekzorchik @ ekzorchik]> бросить

прервано

Подключение к 192.168.1.9 закрыто.

Еще интересным стоит возможность подключения выполнить команду не переходя всецело в консоль устройства Mikrotik :

экзорчик @ navy: ~ $ ssh ekzorchik @ 192.168.1.9 печать системного маршрутизатора

routerboard: есть

модель: 2011UiAS-2HnD

серийный номер: 614A052CFEA6

тип прошивки: ar9344

текущая прошивка: 3.24

обновление прошивки: 3.24

ekzorchik @ navy: ~ $ ssh [email protected] файл печать

# ИМЯ ТИП РАЗМЕР ВРЕМЯ СОЗДАНИЯ

0 расширенных инструментов-6.32… пакет 100,1 КБ 2 января 1970 г. 05:05:55

1 каталог скинов янв / 01/1970 03:00:01

2 с автоматическим сбросом до сброса.б… резервная копия 78,1 КБ 27 июля 2015 г. 18:50:44

3 каталог пабов 2 января 1970 г. 03:06:19

4 точки доступа-6.32.1-mips… пакет 184,1 КБ 2 января 1970 г. 05:07:44

5 system-6.32.1-mipsb… package 6.8MiB 02.01.1970 05:08:01

6 ekzorchik-20151218-… резервная копия 49,0 КБ 17 дек 2015 21:48:50

7 пакет dhcp-6.32.1-mipsbe.npk 168,1 КБ 2 января 1970 г. 05:07:35

8 autosupout.rif .rif файл 491,7 КБ 27 января 2016 г. 14:16:47

посредством этой возможности можно сделать хоть и корявый но как на первый шаг сгодится скрипт, который будет делать бекап устройство, забирать / отправлять по почте / ftp бекап на доверенное хранилище.

А теперь если нужно забрать устройство Mikrotik к примеру конфигурационный файл устройства со всеми настройками или же просто бекап, то сделать это можно следующим образом:

[ekzorchik @ ekzorchik]> имя сохранения резервной копии системы = резервная копия

Сохранение конфигурации системы

Резервная копия конфигурации сохранена

[ekzorchik @ ekzorchik]> распечатать файл

# ИМЯ ТИП РАЗМЕР ВРЕМЯ СОЗДАНИЯ

0 каталог скинов янв / 01/1970 07:00:02

1 диск 4 диска 15 декабря 2015 г. 18:30:44

2 Микротик_27012015.б… резервная копия 13,0 КБ 27 января 2016 г. 20:17:52

3 backup.backup резервная копия 13,0 КБ 27 января 2016 г. 20:19:56

ekzorchik @ navy: ~ $ sftp [email protected]: backup.backup

Подключен к 192.168.1.9.

Получение / резервное копирование. Резервное копирование в резервное копирование

/backup.backup 100% 13 КБ 13,0 КБ / с 00:00

ekzorchik @ navy: ~ $ dir -sh backup.backup & file backup.backup

[1] 30479

16K бэкап.резервный

backup.backup: данные

[1] + Готово dir -sh backup.backup

А если сделать маленький скрипт в системе Ubuntu посредством которого уже сделаем бекап на устройстве с генерирования текущей даты и времени и скопируем его себе на рабочую станцию:

экзорчик @ navy: ~ $ nano backup_192_168_1_9

#! / Bin / bash

bfile = $ (дата +% d% m% y_% H_% M)

ssh admin @ 192.168.1.9 имя сохранения резервной копии системы = Backup192_168_1_9_ $ bfile

sftp [email protected]: Backup192_168_1_9_ $ bfile.backup

экзорчик @ navy: ~ $ chmod + x backup_192_168_1_9

Запускаю данный скрипт:

Экзорчик @ флот: ~ $ ./backup_192_168_1_9

Резервная копия конфигурации сохранена

Подключен к 192.168.1.9.

Получение / Резервное копирование192_168_1_9_270116_17_03. Резервное копирование в Резервное копирование192_168_1_9_270116_17_03.резервный

/Backup192_168_1_9_270116_17_03.backup 100% 13KB 13.0KB / s 00:00

Экзорчик @ navy: ~ $ dir -sh Backup192_168_1_9_270116_17_03.backup && file $ _

16K резервное копирование192_168_1_9_270116_17_03.backup

Резервное копирование192_168_1_9_270116_17_03.backup: данные

Отлично - это полный бекап, а теперь нужно добавить еще в скрипт экспорт всех настроек в виде скрипта, выполнив который при восстановлении работоспособности до рабочего уровня вдруг что-то произошло (вышло из строя / неосторожная настройка и т.д.)

#! / Bin / bash

bfile = $ (дата +% d% m% y_% H_% M)

efile = $ (дата +% d% m% y_% H_% M)

ssh [email protected] имя сохранения резервной копии системы = Backup192_168_1_9_ $ bfile

ssh [email protected] экспортный файл = Export192_168_1_9_ $ efile.rsc

sftp [email protected]: Backup192_168_1_9_ $ bfile.backup

sftp [email protected]: Экспорт192_168_1_9_ $ efile.rsc

Экзорчик @ флот: ~ $./ backup_192_168_1_9

Резервная копия конфигурации сохранена

Подключен к 192.168.1.9.

Получение / Резервное копирование192_168_1_9_270116_17_12. резервное копирование в Резервное копирование192_168_1_9_270116_17_12. резервное копирование

/Backup192_168_1_9_270116_17_12.backup 100% 16KB 15.9KB / s 00:00

Подключен к 192.168.1.9.

Получение /Export192_168_1_9_270116_17_12.rsc в Export192_168_1_9_270116_17_12.rsc

/Export192_168_1_9_270116_17_12.rsc 100% 244 0,2 КБ / с 00:00

ekzorchik @ navy: ~ $ dir -sh Export192_168_1_9_270116_17_12.rsc && файл $ _

4.0K Экспорт 192_168_1_9_270116_17_12.rsc

Export192_168_1_9_270116_17_12.rsc: текст ASCII с терминаторами строки CRLF

Mikrotik посредством публичного ключа с доверенного хоста провожу, делаю бекап и экспорт всех команд посредством использования настроенного оборудования (используемого в целях изучения, а). как сделать ту или иную настройку не через Winbox или же Web -интерфейс, а задействовать командную команду - так более продуктивно и приобретается опыт), как на устройстве так и на локальной системе Ubuntu 12.04.5 Настольный amd64

Ну а что теперь, я считаю, что эта заметка завершенная, автор в дальнейшем на основе я рассмотрю еще более интересную и практическую, а пока собственно все - с уважением блога, ekzorchik .

.

Бекапим Mikrotik с помощью SSH и SCP / Хабр

Если заглянуть назад в прошлое, когда еще не было Ansible или других систем удаленного администрирования linux, мы пользовались только своими подручными скриптами, позволяя им подключаться к системам по ssh с помощью ключей. Думаю и по сей день многие использую свои скрипты взамен системам централизованного управления.

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

Логика работы выстроилась сразу. Зайти на хост по ssh, выполнить некоторые команды для подготовки бекапов и забрать готовые файлы с помощью scp.

Первым делом нужно создать пользователя будет иметь доступ к данным с необходимыми правами. Тут я думаю каждый сам сможет разобраться в какую группу определить пользователя. Главное помнить:

1. Имя пользователя для работы без пароля должно быть одинаково на всех хостах или для каждого хоста указывать свою логин что не есть удобно;
2. Пользователь должен иметь доступ к хосту без пароля (ssh-keygen в помощь);
3. Пользователь должен иметь доступ к файлам которые необходимо забрать.

тут можно выполнить сбор данных через удаленный оболочку для сбора необходимых данных через хосте и командовать 2) настроить cron на хосте и выполнить команду сбора а уже потом, когда нибудь, заходить на хост и забирать готовые пирожки бекапы. Конечно мы пойдем по первому пути

Имеем такую ​​конфигурацию -
10 хостов (Mikrotik), с которых необходимо получить два типа бекапов - бинарный (для восстановления с нуля) и конфигурацию без паролей и сертификатов для заливки на работающий конфиг.Так же в нашем полном распоряжении имеется машина с debian 8 на борту назовем ее сервер (и не важно что это контейнер, важно что это дебиан) ну и конечно куда без него - zabbix-server.

• IP Mikrotik - 10.10.0.1, 10.10.1.1, 10.10.2.1, 10.10.3.1, 10.10.4.1, 10.10.5.1, 10.10.6.1, 10.10.7.1, 10.10.8.1, 10.10.9.1;
• IP Zabbix-сервер - 10.10.10.10;

Для упрощения задачи zabbix-hostname будет в формате mik (третий октет в десятичном формате).host таким образом получаем -

• Zabbix имена хостов - mik0.host, mik1.host, mik2.host, mik3.host, mik4.host, mik5.host, mik6.host, mik7.host, mik8.host, mik9. хост

Если кто не помнит - zabbix hostname мы указываем в файле настроек zabbix-agent (агент тут не нужен, но все же) и на сервере zabbix в web-ui.


Первым делом создаем на нашем сервере ключ RSA. Почему RSA - да вообщем то по привычке кстати, старые версии RB шаблон только DSA, а все что свежее 6.35 уже работает с RSA и DSA, потому что смотрите по обстановке, можно и обновиться, как сделал я 🙂 , если у вас уже есть готовый ключ - пропускайте этот шаг.

ssh-keygen -t RSA

Переносим содержимое файла $ HOME / .ssh / id_rsa.pub с сервера на наши хосты. Я ленивый и для Mikrotik использовал winbox.

Для линукс можно сделать проще, создать скрипт sh и запустить его от имени пользователя мы будем ходить на хостах за бекапами ( на хостах пользователь уже должен быть ) такого содержания -
Если у вас ключ DSA, то измените id_rsa.pub на id_dsa.pub

  #! / usr / bin / env bash

хосты = (10.10.0.1 10.10.1.1 10.10.2.1 10.10.3.1 10.10.4.1 10.10.5.1 10.10.6.1 10.10.7.1 10.10.8.1 10.10.9.1)
username = 'пользователь'
для хоста в $ {hosts [*]}
        делать
                кот $ HOME / .ssh / id_rsa.pub | ssh -o "StrictHostKeyChecking no" $ {user} @ $ {host} 'cat >> ~ / .ssh / authorized_keys'
        сделанный
  

Запускаем его и вводим поочередно пароли для всех 10 серверов.

В скрипте есть подвох - специально не стал проверкой, а то совсем забуду как клавиши нажимать -) если вы все прочитали то подвох не сработает.

Тааак, что там дальше, а, точно, мы уже умеем ходить без пароля на все хосты под заданным пользователем.
Мы же хотим получить конфиги Mikrotik. Собственно приступим.

Создаем на сервере вот такой вот скрипт -

  #! / Usr / bin / env bash

хосты = (10.10.0.1_mik0.host_22 \
       10.10.1.1_mik1.host_22 \
       10.10.2.1_mik2.host_22 \
       10.10.3.1_mik3.host_22 \
       10.10.4.1_mik4.host_22 \
       10.10.5.1_mik5.host_22 \
       10.10.6.1_mik6.host_22 \
       10.10.7.1_mik7.host_22 \
       10.10.8.1_mik8.host_22 \
       10.10.9.1_mik9.host_22)
# bash массив значений. Все значения тоже массивы, после удаления разделителя "_".
# Содержимое подмассива IP_ZABBIX-HOSTNAME_SSH-DAEMON-PORT
cdate = `date +% d-% m-% Y` # Системная дата =) Hi Max
dir = "/ mik_backup /" # Хранилище для резервных копий
cmd = "/ system backup save name = backup; export file = backup.rsc hide-sensitive" # команда, выполняющая подготовку резервной копии
username = "user" # пользователь SSH
zabbix_hp = (10.10.10.10 10051) # IP, затем ПОРТ
age = "30" # удалить все резервные копии старше 30 дней
itemname = "backup" # элемент zabbix
error_value = "1" # значение ошибки для триггера
value = "0" # хорошее значение =)

для хоста в $ {hosts [*]} # Получить значения из основного списка
делать
hostname = ($ (echo $ {host} | tr "_" "")) # Получить значения из подсписка
ssh $ {username} @ $ {hostname [0]} -o "StrictHostKeyChecking no" -p $ {hostname [2]} "$ {cmd}"
new_dir = "$ {HOME} $ {dir} $ {hostname [1]} / $ {cdate}"
mkdir -p $ {новый_директор}
scp -P $ {hostname [2]} $ {username} @ $ {hostname [0]}: резервное копирование.резервная копия $ {new_dir}
scp -P $ {имя хоста [2]} $ {имя пользователя} @ $ {имя хоста [0]}: backup.rsc $ {новый_директор}
check = `find $ {new_dir} -type f -name backup. *`
если ["$ {check}" == ""]
тогда
zabbix_sender -z $ {zabbix_hp [0]} -p $ {zabbix_hp [1]} -s $ {hostname [1]} -k $ {itemname} -o $ {error_value}
еще
zabbix_sender -z $ {zabbix_hp [0]} -p $ {zabbix_hp [1]} -s $ {hostname [1]} -k $ {itemname} -o $ {value}
фи
сделанный
найти $ {HOME} $ {dir} -mindepth 2 -mtime $ {age} -type d -exec rm -rf {} \; #clear dirs
  

Постарался максимально прокомментировать все что происходит в скрипте.Давайте разберем, что же тут такое делается.

Тут мы говорим каким интерпретатором будем выполнять код

  #! / Usr / bin / env bash
  

Тут создаем массив с необходимыми нам данными для подключения к хостам и отправке данных в zabbix

  hosts = (10.10.0.1_mik0.host_22 \
       10.10.1.1_mik1.host_22 \
       10.10.2.1_mik2.host_22 \
       10.10.3.1_mik3.host_22 \
       10.10.4.1_mik4.host_22 \
       10.10.5.1_mik5.host_22 \
       10.10.6.1_mik6.host_22 \
       10.10.7.1_mik7.host_22 \
       10.10.8.1_mik8.host_22 \
       10.10.9.1_mik9.host_22)
  

Тут думаю только одна переменная нуждается в объяснении - $ cmd. Это две команды выполняются на Mikrotik последовательно. Первая создает бинарный бекап
вторая скрипт с настройками без выгрузки паролей и ключей шифрования.

  cdate = `date +% d-% m-% Y` # Системная дата =) Hi Max
dir = "/ mik_backup /" # Хранилище для резервных копий
cmd = "/ system backup имя сохранения = резервная копия; файл экспорта = резервная копия.rsc hide-sensitive "# команда для подготовки резервной копии
username = "user" # пользователь SSH
zabbix_hp = (10.10.10.10 10051) # IP, затем ПОРТ
age = "30" # удалить все резервные копии старше 30 дней
itemname = "backup" # элемент zabbix
error_value = "1" # значение ошибки для триггера
value = "0" # хорошее значение =)
  

Основное тело программы. На входе в цикл мы имеем массив массився в переменных $ hosts. Цикл работает так - берем первый элемент массива, у нас он равен 10.10.0.1_mik0.host_22 и начинаем с ним работать.Первым же мы мы заносим в переменную $ hostname массив созданный из первого элемента $ hosts. Делаем мы это с помощью команды, по сути, как в python эмитируем действие метода строки .split (). Получается вполне сносно. Мы получаем 3 элемента в массиве $ hostname. Первый элемент - ip хоста. Второй элемент - zabbix-hostname. Третий элемент - ssh-порт.
Дальше мы обращаемся к этому элементу с помощью индекса, опять же python.
Далее формируем древо каталогов для хранения файлов и указываем scp какие файлы забирать.Прошу не пинать - если кто подскажет как с помощью scp в такой конструкции обращаться к файлам по маске + в карму.
После того как мы получили файлы - отправляем в zabbix сообщение об успехе.
Проверка создания конфига общего поиском файла в каталоге назначения. Можно было сделать сравнение md5 на Mikrotik и в каталоге назначения, но это уже другая история, хотя я так делал.


  для хоста в $ {hosts [*]} # Получить значения из основного списка
делать
hostname = ($ (echo $ {host} | tr "_" "")) # Получить значения из подсписка
ssh $ {username} @ $ {hostname [0]} -o "StrictHostKeyChecking no" -p $ {hostname [2]} "$ {cmd}"
new_dir = "$ {HOME} $ {dir} $ {hostname [1]} / $ {cdate}"
mkdir -p $ {новый_директор}
scp -P $ {hostname [2]} $ {username} @ $ {hostname [0]}: резервное копирование.резервная копия $ {new_dir}
scp -P $ {имя хоста [2]} $ {имя пользователя} @ $ {имя хоста [0]}: backup.rsc $ {новый_директор}
check = `find $ {new_dir} -type f -name backup. *`
если ["$ {check}" == ""]
тогда
zabbix_sender -z $ {zabbix_hp [0]} -p $ {zabbix_hp [1]} -s $ {hostname [1]} -k $ {itemname} -o $ {error_value}
еще
zabbix_sender -z $ {zabbix_hp [0]} -p $ {zabbix_hp [1]} -s $ {hostname [1]} -k $ {itemname} -o $ {value}
фи
сделанный
  

Тут чистим место. Переменная $ age поможет нам сохранить бекапы столько, сколько нам этого надо

  find $ {HOME} $ {dir} -mindepth 2 -mtime $ {age} -type d -exec rm -rf {} \; #clear dirs
  

Теперь самое тривиальное.
Создаем на сервере шаблон zabbix или просто элемент данных zabbix_trapper на наших узлах, которые мы заблаговременно добавили на мониторинг в zabbix.
Не буду выкладывать шаблон из одного элемента данных и одного триггера. Думаю сделать его сможет каждый. Главное помнить, если хосты мониторятся через zabbix-proxy, данные вы должны отправлять на zabbix-proxy. В ином случае отправляем все на zabbix-сервер.
Не важно даже какой будет IP у этих хостов в веб-интерфейсе zabbix.Важно чтобы совпадали имя хоста с данными в скрипте.

PS. На все скрипты нужно кинуть chmod + x так их можно будет запустить без вызова интерпретатора.
P.S.S передать scp список файлов для резервного копирования на linux можно сделать еще один массив и вложить его в цикл for. Можно сделать все в виде получаемых параметров. Ну вообщем можно развлечься.

.