Пароль учетной записи - основа безопасности.
Все мы знаем, что он должен быть достаточно сложным для усложнения подбора, регулярно меняться и ни в коем случае не попадать в открытый доступ.
Приходится иметь дело с рядом факторов:
хранилище паролей
их актуализацияпередача реквизитов коллегам по каналам связи
непосредственное подключение к серверам с использованием паролей
Каждый пункт из этого списка - дыра в безопасности.
Каналы связи, по которым передается информация, содержащая реквизиты доступа, не всегда надежны, а зачастую и вовсе открыты и не зашифрованы. Ваши пароли будут в открытом виде передаваться по цепочке посредников (датацентры, провайдеры, маршрутизаторы и тд), записываться в логи и ждать своего Man In The Middle.
Кроме того разрастающийся парк серверов и учетных записей будет требовать всё больших издержек на обслуживание и создавать всё больший хаос.
Подводя итог, пароли это:
Небезопасно
Неудобно
Как быть? - Работать с 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 вы сами укажете где хранить ключи.
Ключ, как вы уже заметили, представляет собой две половинки - приватную и публичную. Приватную часть ключа никому и никогда нельзя передавать! Если кто-то вас попросит передать приватную часть - знайте, что вас пытаются обмануть и больше с такими людьми дел не имейте.
А вот публичную часть ключа можно хоть на билбордах вывешивать!
Обладание публичной частью ключа не дает другому человеку ни одного шанса на авторизацию. Главное чтобы он не получил вторую часть, но это задача совсем несложная - просто надежно ее храните и никому никогда, еще раз, не передавайте.
Поэтому если вам нужно получить доступ к серверу и администратор просит вас публичный ключ - это нормальная грамотная ситуация, так и должно быть. Приватный ключ, еще и еще раз, мы никому никогда не даем.
В Юниксах ваши ключи будут автоматически предлагаться каждому сетевому соединению, поэтому никаких дополнительных телодвижений не требуется, в Windows нам понадобится программа-агент, которая будет выполнять эту работу. В нашем случае в составе всё того же PuTTY находим программу pagent.exe. Ей нужно передать ваш приватный ключ и чтобы каждый раз не запускать вручную, добавить ее в автозагрузку.
На стороне сервера (мы будем рассматривать Unix-сервер) в точно такой же домашней папке пользователя, должен лежать файл authorized_keys, в котором построчно вписаны все публичные ключи, которые имеют право на авторизацию.
Например, нам надо подключиться к пользователю dev, наш публичный ключ должен лежать в файле /home/dev/.ssh/authorized_keys. Там же могут друг за другом лежать ключи ваших коллег, технической поддержки, внешних систем автоматизации и тд.
Всё, теперь мы можем подключаться к серверу безопасно и без пароля, но это только первый шаг.
Давайте подумаем какие еще дивиденды нам приносят ключи:
Приватный ключ можно положить на каждую рабочую машину, с которой мы будем работать и можно безопасно подключаться к серверам хоть из дома, хоть из под пальмы. Создавать для каждого рабочего места новый ключ не надо!
Однажды собрав с коллег публичные ключи, мы можем их раскладывать на нужные сервера и убирать когда доступ сотруднику нужно отозвать. Мы исключили пересылку паролей и обслуживание их зоопарка.
Мы можем запретить подключение к серверу по паролю (и это стоит сделать), убрав тем самым возможность взлома сервера подбором пароля вовсе.
Мы можем использовать SSH-авторизацию для безопасного сообщения серверов между собой, выстраивая безопасные и удобные схемы автоматизации. Потому как пользователь на сервере это такой же пользователь как и вы на своей машине и ему доступны все те же возможности, что и вам - он тоже может сгенерировать свои ключи и подключаться к другим серверам, это оперативный простор для автоматизации.
Мы можем упростить взаимодействие со многими другими сервисами посредством SSH-ключей, например, с репозиториями нашего контроля версий. В них это один из базовых факторов работы, а контроль версий один из базовых факторов современной разработки в принципе, но об этом позже.
Итак, мы перешли на ключи вместо паролей, закрыв одним этим только массу потенциальных уязвимостей и утечек. В довесок мы получили удобное управление доступом, своим и всей команды разработки, а также получили возможность бесшовной интеграции с внешними сервисами, такими как репозитории кода и пр.
SSH-авторизация - первый шаг к построению современных производственных линий.
О том, как эти линии создавать и внедрять, мы напишем в следующих статьях.