Новости

Безопасная работа с сервером с помощью SSH-ключа

Блог
Пароль учетной записи - основа безопасности.
Все мы знаем, что он должен быть достаточно сложным для усложнения подбора, регулярно меняться и ни в коем случае не попадать в открытый доступ.

Приходится иметь дело с рядом факторов:
  • хранилище паролей
их актуализацияпередача реквизитов коллегам по каналам связи
непосредственное подключение к серверам с использованием паролей

Каждый пункт из этого списка - дыра в безопасности.

Каналы связи, по которым передается информация, содержащая реквизиты доступа, не всегда надежны, а зачастую и вовсе открыты и не зашифрованы. Ваши пароли будут в открытом виде передаваться по цепочке посредников (датацентры, провайдеры, маршрутизаторы и тд), записываться в логи и ждать своего Man In The Middle.

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

Подводя итог, пароли это:
  1. Небезопасно
Неудобно
Как быть? - Работать с SSH через ключи авторизации.

Это Secure Shell, безопасная оболочка, альтернатива telnet и FTP, появившаяся в 1995 г. Ее задача - обеспечение безопасного соединения в небезопасных сетях.

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

Как и FTP, SSH поддерживает авторизацию по паролю, в этом случае трафик будет зашифрован и часть проблем с безопасностью устраняется простым переключением протокола соединения с голого FTP на SSH (SFTP). Но это не решает остальных проблем, поэтому идем дальше.

В идеале нам бы вообще избавиться от такого явления как пароль, не передавать его, не хранить, не обновлять, словом забыть про него и не подвергать сервер лишней опасности, а себя лишним телодвижениям. И здесь нам на помощь приходит SSH-авторизация.

Если вы используете Unix-системы вроде Linux, FreeBSD или macOS, то у вас уже всё необходимое есть “из-коробки”. В случае с Windows придется воспользоваться дополнительным ПО, например, PuTTY, но это совсем несложно и этот софт распространяется свободно.

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

Итак, мы под свой учетной записью, нам нужно создать свой SSH-ключ (если еще нет), на Unix-системах открываем терминал и выполняем команду ssh-keygen.

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

Если используете PuTTY, то в его составе есть утилита puttygen.exe, которая спросит всё то же самое, но в графическом виде.

Всё, у нас есть своя пара ключей! В Unix-системах они будут лежать в домашнем разделе пользователя ~/.ssh, в PuTTY вы сами укажете где хранить ключи.

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

А вот публичную часть ключа можно хоть на билбордах вывешивать!

Вот, например, мой ключ:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDG5kRJjlwFQT8TtphFLBDs/3EmV3FkSHHF9L7Qv8KPdgPV3WL+I+jZYm2HSX4isTx0J8VuFbtGvMe0KLb6BWgnqojxRt0bUdkzkuw/M7tZ/Jfn1WS1DkOSKmwbIC6/5aWkfnoIsjOme7jISpHXnSl5ijh1fZ1KjmRqz2nAc0jFb9pyXN85IWng2yr+fpREMpXXi7IavvZ6Mpnp2+vOtIKiesygXQYcUJp15hCtS8NErHXNRzHKt73Z3PaL7r0qwnX5av1SX5LxrIp26Xrv5rbbpUTPmeSvrD0JOjuL02zbiYC/rZBGZAXuXUl6a2HzEV6+/atGKI+cKfufMVr1Vu+d androsov@itgrade

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

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

В Юниксах ваши ключи будут автоматически предлагаться каждому сетевому соединению, поэтому никаких дополнительных телодвижений не требуется, в Windows нам понадобится программа-агент, которая будет выполнять эту работу. В нашем случае в составе всё того же PuTTY находим программу pagent.exe. Ей нужно передать ваш приватный ключ и чтобы каждый раз не запускать вручную, добавить ее в автозагрузку.

На стороне сервера (мы будем рассматривать Unix-сервер) в точно такой же домашней папке пользователя, должен лежать файл authorized_keys, в котором построчно вписаны все публичные ключи, которые имеют право на авторизацию.

Например, нам надо подключиться к пользователю dev, наш публичный ключ должен лежать в файле /home/dev/.ssh/authorized_keys. Там же могут друг за другом лежать ключи ваших коллег, технической поддержки, внешних систем автоматизации и тд.

Всё, теперь мы можем подключаться к серверу безопасно и без пароля, но это только первый шаг.
Давайте подумаем какие еще дивиденды нам приносят ключи:
  1. Приватный ключ можно положить на каждую рабочую машину, с которой мы будем работать и можно безопасно подключаться к серверам хоть из дома, хоть из под пальмы. Создавать для каждого рабочего места новый ключ не надо!
Однажды собрав с коллег публичные ключи, мы можем их раскладывать на нужные сервера и убирать когда доступ сотруднику нужно отозвать. Мы исключили пересылку паролей и обслуживание их зоопарка.
Мы можем запретить подключение к серверу по паролю (и это стоит сделать), убрав тем самым возможность взлома сервера подбором пароля вовсе.

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

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

SSH-авторизация - первый шаг к построению современных производственных линий.
О том, как эти линии создавать и внедрять, мы напишем в следующих статьях.