Home » Полезные советы » Настройка SSH авторизации по ключам

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

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

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Курс стоящий, все подробности читайте по ссылке. Есть бесплатные курсы.

Введение

Пару слов о чем тут пойдет речь. Для подключения по 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)

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

Онлайн курс по Kubernetes

Онлайн-курс по Kubernetes – для разработчиков, администраторов и технических лидеров, которые хотят изучить платформу Kubernetes. Очень востребованный навык, который хорошо оплачивается. Курс не для новичков – нужно пройти вступительный тест. Для кого этот курс: Разработчиков, администраторов, СТО и техлидов:
  • Которые устали тратить время на автоматизацию;
  • Которые хотят единообразные окружения;
  • Которые хотят развиваться и использовать современные инструменты;
  • Которым небезразлична надежность инфраструктуры;
  • Которым приходится масштабировать инфраструктуру под растущие потребности бизнеса;
  • Которые хотят освободить продуктовые команды от части задач администрирования и автоматизации и сфокусировать их на развитии продукта.
Проверьте себя на вступительном тесте и смотрите программу детальнее по .

Помогла статья? Есть возможность отблагодарить автора

Автор Zerox

Zerox
Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству.

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

  1. Аватар

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

    • Zerox

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

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

  2. Аватар
    Александр

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

  3. Аватар

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

    • Zerox

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

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

  4. Аватар

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

    • Zerox

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

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

      • Аватар

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

        • Zerox

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

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

Ваш e-mail не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.