Все мы знаем, что он должен быть достаточно сложным для усложнения подбора, регулярно меняться и ни в коем случае не попадать в открытый доступ.
Приходится иметь дело с рядом факторов:
- хранилище паролей
непосредственное подключение к серверам с использованием паролей
Каждый пункт из этого списка - дыра в безопасности.
Каналы связи, по которым передается информация, содержащая реквизиты доступа, не всегда надежны, а зачастую и вовсе открыты и не зашифрованы. Ваши пароли будут в открытом виде передаваться по цепочке посредников (датацентры, провайдеры, маршрутизаторы и тд), записываться в логи и ждать своего 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 вы сами укажете где хранить ключи.
Ключ, как вы уже заметили, представляет собой две половинки - приватную и публичную. Приватную часть ключа никому и никогда нельзя передавать! Если кто-то вас попросит передать приватную часть - знайте, что вас пытаются обмануть и больше с такими людьми дел не имейте.
А вот публичную часть ключа можно хоть на билбордах вывешивать!
Вот, например, мой ключ:
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. Там же могут друг за другом лежать ключи ваших коллег, технической поддержки, внешних систем автоматизации и тд.
Всё, теперь мы можем подключаться к серверу безопасно и без пароля, но это только первый шаг.
Давайте подумаем какие еще дивиденды нам приносят ключи:
- Приватный ключ можно положить на каждую рабочую машину, с которой мы будем работать и можно безопасно подключаться к серверам хоть из дома, хоть из под пальмы. Создавать для каждого рабочего места новый ключ не надо!
Мы можем запретить подключение к серверу по паролю (и это стоит сделать), убрав тем самым возможность взлома сервера подбором пароля вовсе.
Мы можем использовать SSH-авторизацию для безопасного сообщения серверов между собой, выстраивая безопасные и удобные схемы автоматизации. Потому как пользователь на сервере это такой же пользователь как и вы на своей машине и ему доступны все те же возможности, что и вам - он тоже может сгенерировать свои ключи и подключаться к другим серверам, это оперативный простор для автоматизации.
Мы можем упростить взаимодействие со многими другими сервисами посредством SSH-ключей, например, с репозиториями нашего контроля версий. В них это один из базовых факторов работы, а контроль версий один из базовых факторов современной разработки в принципе, но об этом позже.
Итак, мы перешли на ключи вместо паролей, закрыв одним этим только массу потенциальных уязвимостей и утечек. В довесок мы получили удобное управление доступом, своим и всей команды разработки, а также получили возможность бесшовной интеграции с внешними сервисами, такими как репозитории кода и пр.
SSH-авторизация - первый шаг к построению современных производственных линий.
О том, как эти линии создавать и внедрять, мы напишем в следующих статьях.