Авторизация по ключу ssh прежде всего нужна для автоматизации выполняемых вами задач. Это могут быть периодические задачи, выполняемые по расписанию — бэкапы данных, синхронизация данных. Управление устройствами — пример: биллинг, когда у вас есть система управления биллингом и она взаимодействует с роутером без вашего участия. Смысл сводится к одному — авторизоваться на удаленном хосте без участия пользователя и выполнить какую-нибудь команду.
Принцип простой: генерируется пара ключей — открытый и закрытый. Открытый находится удаленном хосте, закрытый хранится у вас.
Генерация пары ключей
У меня на сервере есть пользователь billing, от имени которого я хочу осуществлять подключения к роутеру и что-нибудь там делать. Для этого выполнить команду
ssh-keygen -t dsaДополнительные параметры можно не указывать, оставив все по-умолчанию. Пароль ключа я оставил пустым.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
-sh-4.1$ cd ~ -sh-4.1$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/billing/.ssh/id_dsa): Created directory '/home/billing/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/billing/.ssh/id_dsa. Your public key has been saved in /home/billing/.ssh/id_dsa.pub. The key fingerprint is: ea:fc:b0:48:94:51:44:76:fa:72:dc:75:eb:b5:2d:2a billing@webserver3 The key's randomart image is: +--[ DSA 1024]----+ | o= . | | o o | | . . . . | | o o . . . . | | o . S . . .| | . + . .o| | . o o..| | . + o E . . | | . +.. .. | +-----------------+ -sh-4.1$ |
Результатом выполнения команды будут два файла
|
1 2 3 4 |
/home/billing/.ssh/id_dsa /home/billing/.ssh/id_dsa.pub |
Где:
id_dsa — это закрытый ключ, который надо хранить как зеницу ока, а в случае его утраты генерировать новую пару ключей.
id_dsa.pub — открытый ключ, который должен быть размещен на удаленном хосте.
Убедитесь, что установлены правильные права доступа: 700 к директории .ssh и 600 к файлу закрытого ключа id_dsa. Проверить можно командой:
|
1 2 3 4 5 6 7 |
-sh-4.1$ ls -aRl drwx------ 2 billing billing 4096 Окт 15 11:44 .ssh -rw------- 1 billing billing 668 Окт 15 11:44 id_dsa |
Я удалил из результата выполнения команды все лишнее, оставив только то, что нас интересует.
Права «rwx» директории .ssh соответствуют 700, «rw» файла id_dsa соответствуют 600. Т.е. никто, кроме пользователя billing не имеет право изменять содержимое. То, что мне нужно. В противном случае SSH не позволит использовать этот файл ключей.
Если права доступа установлены некорректно, их надо установить руками:
|
1 2 3 4 5 |
-sh-4.1$ cd ~ -sh-4.1$ chmod 0700 ./.ssh -sh-4.1$ chmod 0600 ./.ssh/id_dsa |
На этом манипуляции на хосте, с которого планируется подключение, закончены.
Открытый ключ
На удаленном хосте, к которому мы будем подключаться, тоже надо выполнить некоторые действия:
- Убедиться, что авторизация по ключам разрешена.
В конфиге, который обычно лежит тут: «/etc/ssh/sshd_config«, должно присутствовать следующее:
1234PubkeyAuthentication yesAuthorizedKeysFile %h/.ssh/authorized_keys
В случае необходимости правим конфиг и перезапускаем SSH:
123service sshd restart - Копируем содержимое нашего открытого ключа
id_dsa.pubв файл
/home/[пользователь]/.ssh/authorized_keys
новой строкой (там уже могут быть авторизованные ключи).
На этом почти все. Осталось проверить. Проверяем:
|
1 2 3 |
ssh -i ./.ssh/id_dsa -p 22 192.168.33.1 |
Первый раз надо в любом случае подключиться руками, т.к. вас спросят, доверяете ли вы «фингерпринту» вашего ключа и вы должны будете утвердительно ответить, после чего удаленный хост будет добавлен в known hosts на постоянной основе.
Теперь вы сможете использовать выполнение команд на удаленных хостах в ваших скриптах с использованием авторизации по ключу без участия пользователя.
Как импортировать ключ на MikroTik, написано в статье MikroTik SSH key.
Реклама: