Настройка SSH авторизации по ключам

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

Онлайн-курс по устройству компьютерных сетей

На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Введение

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

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

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

Об одном таком нюансе я и расскажу. Мне понадобилось настроить авторизацию ssh по сертификату. Причем авторизовываться будет сразу пользователь root. Заходить будут как по паролю, так и по сертификату. Мне необходимо вести учет того, кто по какому сертификату подключился по ssh к серверу.

Создание ssh ключей для putty

Для управления серверами я использую windows машину и ssh клиент putty. В составе программного комплекса putty есть утилита для генерации ключей - puttygen. Скачивайте ее по ссылке с официального сайта - https://the.earth.li/~sgtatham/putty/latest/x86/puttygen.exe. После запуска нажимайте на кнопку Generate и двигайте мышкой, пока не сформируется пара ключей - открытый и закрытый.

Генерация ssh сертификатов

Key passphrase Можно задать пароль для приватного ключа. Ставить или нет на ваше усмотрение.
Save public key Кнопка сохранения публичного ключа. Он размещается на удаленном сервере.
Save private key Кнопка сохранения приватного ключа. Ключ хранится у клиента и используется для подключения к серверу.
SSH-2 RSA 2048 Тип ключа и его длинна. Значения по-умолчанию подходят в полной мере для нашей задачи.

Формат ключей, которые создает puttygen не подходит для openssh, который стоит на сервере, поэтому содержимое открытого ключа в нужном формате копируем из окна puttygen. Я указал этот ключ стрелочкой на скриншоте. Именно это содержание пойдет на сервер. Сохраняйте ключ в формате openssh, а так же два других с помощью кнопок Save key.

Настройка ssh на сервере для авторизации по сертификатам

Здесь все просто. Во всех известных мне дистрибутивах авторизация по сертификатам уже настроена, нужно просто добавить этот сертификат на сервер. Сделаем это.

# mkdir ~/.ssh
# chmod 0700 ~/.ssh
# touch ~/.ssh/authorized_keys
# chmod 0644 ~/.ssh/authorized_keys

В файл authorized_keys вставляйте скопированный ключ из окна puttygen. Сохраняйте и подключайтесь с помощью сертификата. В putty сертификат нужно указать в разделе Connection -> SSH -> Auth.

Подключение putty с помощью сертификата

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

Теперь можно подключаться, необходимости перезапускать службу ssh нет.

Логирование ssh подключений по сертификату

Мне необходимо знать, когда и какой сертификат подключался к серверу. По-умолчанию такой информации чаще всего в логах не остается. Исключение я заметил только в CentOS 7. Там с дефолтными настройками ssh и уровнем логирования INFO отображается отпечаток ключа в логе:

# cat /var/log/secure
Dec 4 21:32:40 server sshd[21379]: Accepted publickey for root from 10.1.3.221 port 56929 ssh2: RSA fa:7c:c6:6b:31:98:43:9f:ef:41:c5:49:80:c2:a8:16
Dec 4 21:32:41 server sshd[21379]: pam_unix(sshd:session): session opened for user root by (uid=0)

По отпечатку становится понятно, какой сертификат подключился. Для каждого сертификата отпечаток можно посмотреть в puttygen. В CentOS более ранних версий, в Ubuntu 12 и 14 в логах будет только такая информация:

# cat /var/log/auth.log
Dec 5 11:44:14 server sshd[9071]: Accepted publickey for root from 10.1.3.221 port 60170 ssh2
Dec 5 11:44:14 server sshd[9071]: pam_unix(sshd:session): session opened for user root by (uid=0)

Информации о самом ключе нет. Я так думаю, это зависит от версии OpenSSH. В первом случае 6-я версия, во втором 5-я. Специально я не проверял. Если у вас нет информации о ключе в лог файле, исправить это очень просто. В файле /etc/ssh/sshd_config меняем параметр:

LogLevel VERBOSE

и перезапускаем службу:

# service ssh restart

Пробуем снова подключиться по ssh, используя сертификат, и проверяем лог:

Dec 5 11:43:17 server sshd[8746]: Connection from 10.1.3.221 port 60162
Dec 5 11:43:19 server sshd[8746]: Found matching RSA key: fa:7c:c6:6b:31:98:43:9f:ef:41:c5:49:80:c2:a8:16
Dec 5 11:43:19 server sshd[8746]: Postponed publickey for root from 10.1.3.221 port 60162 ssh2 [preauth]
Dec 5 11:43:19 server sshd[8746]: Found matching RSA key: fa:7c:c6:6b:31:98:43:9f:ef:41:c5:49:80:c2:a8:16
Dec 5 11:43:19 server sshd[8746]: Accepted publickey for root from 10.1.3.221 port 60162 ssh2
Dec 5 11:43:19 server sshd[8746]: pam_unix(sshd:session): session opened for user root by (uid=0)

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

Углубленный онлайн-курс по MikroTik.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.

Помогла статья? Подписывайся на telegram канал автора

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

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

16 комментариев

  1. Николай

    В статье нет самого - как отказаться от этих гребаных SSH-сертификатов!!!

  2. Для подключения к Linux серверу putty кстати уже давно не обязателен, в Windows есть свой ssh клиент который прекрасно работает.

  3. Самая понятная статья из найденных. Спасибо

  4. Никита

    Владимир, спасибо за статью. Если посчитаете нужным, добавьте, пожалуйста инфо о том, как отключить аутентификацию по паролю. Т.к. пришлось искать в других источниках, а так было бы все в одном месте.
    vi /etc/ssh/sshd_config
    PasswordAuthentication no

  5. 1) Почему нельзя сразу входить под рутом ?
    Уменьшается стойкость к банальной атаке перебором, атакующему не нужно угадывать имя пользователя, можно сразу перебирать рута.
    В случае успеха он также получает не пользователя, а сразу рута.
    2) Почему сертификат лучше пароля ?
    Отметает всякий перебор начисто.

    • 1. Сейчас по дефолту все популярные дистрибутивы запрещают брут по ssh. Это даже специально настраивать не надо. Плюс, ставить простой пароль это очевидное разгильдяйство. Я иногда смотрю логи auth и secure. Я ни разу не встречал за всю свою практику реального брута. Боты так не делают. Они неторопливо перебирают по словарю. Достаточно просто сложного пароля, чтобы брут стал невозможен.
      2. Как я уже написал, при сложном пароле брут так же невозможен.

      Сам я лично и пароли и сертификаты использую, в зависимости от ситуации.

      • Эти правила были придуманы как банальная защита от дурака. А дураков меньше не становится. Особенно с учетом того, что линукс сейчас в каждой второй кофеварке. Зачастую с дефолтовым паролем.
        Так или иначе, оставляя открытым удаленный вход для рута вы сильно упрощаете атакующему жизнь. Нужно быть сильно уверенным в стойкости своего пароля. Хорошие пароли обычно долго вбивать и трудно запоминать, а люди ленивы.
        Брут - атака перебором. Неторопливый перебор по словарю это собственно и есть разновидность брута.
        Сертификаты это удобно, но тоже палка о двух концах. Получив ваш сертификат атакующий получает полный доступ ко всем серверам. А пароль еще нужно перехватить. Можно шифровать сертификаты, но удобства убавляется.
        В общем механизмы есть разные, а дальше каждый волен выбирать сам.

        • Вот да, ситуации разные бывают. Если сертификат без пароля, то я считаю его менее безопасным, чем просто сложный пароль. Сейчас просто принято однозначно советовать сертификаты. Я не считаю, что они однозначно лучше и безопаснее.

  6. Не могу понять, почему использование ключа дает большую безопасность перед паролем?
    Удобство - да.
    В случае если мой секретный ключ стал доступен другому человеку, он подключится к серверу без проблем (точно так же как и с паролем). Или даже просто откроет PUTTY в моем профиле пользователя, даже без злого умысла.
    Какой в этом смысл?

    • В плане безопасности лично я тоже не вижу разницы. Хотя если на сертификат поставить еще и пароль, то получается неплохо, но я так не делаю.

      Я использую и пароли, и сертификаты в зависимости от обстоятельств. Руководствуюсь не безопасностью, а удобством. Сложный пароль мне видится не менее безопасным способом попасть на сервер, чем сертификат.

      • Аноним

        Это отчасти потому, что вы входите сразу под рутом. Если заходить не в рута по сертификату, то для выполнения sudo потребуется пароль, то есть получается злоумышленнику потребуется и сертификат и пароль.
        Ну и кроме того при использовании авторизации по паролю проще осуществить MITM-атаку.

        • Тогда удобнее делать сертификат с паролем сразу. Я не люблю sudo, потому что на сервер захожу только для административных действий. Мне там всегда нужен root, захожу сразу в него.

  7. Александр

    Я так понимаю для одного пользователя можно сгенерировать только один приватный ключ?

  8. По поводу root логина соглашусь, а вот по авторизации по ключам нет. Настройка авторизации по ключам занимает 5 минут и затем экономит кучу времени и это супер удобно, достаточно использовать pagent и не нужно каждый раз подгружать ключ в путти. Даже когда 2-3 сервера это супер удобно, чтобы зайти в консоль любого сервера нужен только один экземпляр путти достаточно будет прописать ssh "ip-server" и окажешься на нужной консоли, а файлы настроек или чего либо таким же образом копировать одно удовольствие.
    Ума не приложу как работать без ключей, что бэкапить виртуалку, что разворачивать, хоть через dd хоть стандартным средствами, монтирование каталогов (sshfs)
    Лично мне это сильно упрощает работу ))

    • Вопрос удобства подключения к серверу решается разным софтом. Конкретно в твоем случае с putty действительно удобно. Я лично использую mRemoteNG для подключения к серверам, так что у меня такой проблемы нет. Мне что пароль один раз указать, что сертификат.

      А бэкаплю обычно на уровне гипервизора. Я все в виртуалках держу, поэтому dd или sshfs это только экзотические разовые случаи. Да и то таких не было :)

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar