Генерация ssh ключей в Debian

Что еще я могу сделать со своей ca?

Многое! Теперь, когда у вас есть свой личный CA, вы можете настроить TSL сертификаты для

. Если вы хотите узнать побольше о CA, поставщиках, вариантах конфигурации и прочем, прочтите

Создайте учетные данные Google OAuth

В этом проекте вам потребуются

, их создание займет пару минут.

Запишите

Client IDClient Secret

, они понадобятся в следующем шаге!

Заметка: Ваш CA будет выдавать пользовательские сертификаты только тем пользователям, которые авторизованы в GSuite Organization, соответствующем вашему аккаунту Google Cloud project.

1: создание пары rsa-ключей

Для начала нужно создать пару ключей на клиентской машине (это ваш компьютер):

ssh-keygen

По умолчанию ssh-keygen создаст пару 2048-битных ключей RSA, для большинства случаев использования это достаточно надежные ключи (вы можете дополнительно передать флаг -b 4096, чтобы создать длинный 4096-битный ключ).

После ввода команды вы увидите следующий запрос:

Generating public/private rsa key pair.Enter file in which to save the key (/your_home/.ssh/id_rsa):

Нажмите Enter, чтобы сохранить пару ключей в каталог .ssh/ в домашнем каталоге, или укажите другой путь.

Если вы сгенерировали пару ключей SSH ранее, вы можете увидеть запрос:

/home/your_home/.ssh/id_rsa already exists.Overwrite (y/n)?

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

После этого вы увидите:

Enter passphrase (empty for no passphrase):

Запустите ваш Certificate Authority

Мы установим

step-caUbuntu 18.04 LTS

в инстансе AWS. Нам должно хватить бесплатного уровня инстанса AWS (t2.micro/t3.micro).

Возьмите этот скрипт запуска CA и вставьте сверху требуемые значения:

Загрузите его в виде

На борту нового аккаунта

Давайте настроим ваш первый пользовательский аккаунт. Запустите на вашем локальном устройстве следующее:

4: отключение парольной аутентификации

Если вы смогли войти в свою учетную запись без пароля, с помощью только SSH-ключей, вам лучше бы отключить механизм парольной аутентификации, чтобы защитить сервер от brute-force атак.

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

Убедившись, что ваша удаленная учетная запись имеет необходимые привилегии, войдите на свой удаленный сервер с помощью SSH-ключей (либо с правами администратора, либо через пользователя с привилегиями sudo). Затем откройте файл конфигурации демона SSH:

sudo nano /etc/ssh/sshd_config

Внутри файла найдите директиву PasswordAuthentication. Она может быть закомментирована. Раскомментируйте эту строку и установите значение «no». Это отключит возможность входа в систему через SSH с использованием паролей учетных записей:

…PasswordAuthentication no…

Сохраните и закройте файл. Чтобы обновить настройки, необходимо перезапустить сервис sshd:

sudo systemctl restart ssh

В качестве меры предосторожности откройте новое окно и проверьте работу сервиса SSH:

Single sign-on с openid connect и ssh сертификатами

Вместо использования файлов

authorized_keys

мы настроим SSH Certificate Authority и осуществим доступ по SSH через краткосрочные сертификаты, а для поддержки single sign-on мы добавим

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

Что такое SSH сертификат? SSH сертификат — это альтернатива, которая превосходит пару открытого/секретного SSH ключей. Пользователь и хост обмениваются сертификатами в ходе SSH-соединения (handshake), своего рода урезанной версии сертификата TLX X.

Ниже можно увидеть расшифрованный SSH сертификат:

Ssh авторизация по сертификатам- настраиваем подключение

Запускаем Putty, в окне Session указываем адрес сервера к которому будем подключаться с помощью сертификата

Переходим в Connection -> SSH -> Auth и нажав кнопку Browse выбираем свой только что созданный файл с закрытым ключём.

Авторизуйтесь на сервере с помощью ключей ssh

На этом этапе вы сможете войти на удаленный сервер без запроса пароля.

Чтобы проверить это, попробуйте подключиться к серверу через SSH:

ssh [email protected]_ip_address

Буду ли я отрезан от всех своих хостов при отключении моей ca?

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

Для безопасности системы не пользуйтесь SSH сертификатами для подключения напрямую к CA: это единственное место, где стоит и дальше использовать пары ключей.

Время попробовать!

Мы готовы соединиться по SSH с настроенным вами хостом. Вы можете запустить SSH командой

-v

чтобы пронаблюдать handshake. В частности, вы должны увидеть что-то такое:

Генерация ключей ssh

Загрузите новый хост

Давайте загрузим инстанс Ubuntu, который станет нашим первым

ssh

target хостом.

Заметка: Ваш CA будет выдавать сертификаты хоста только инстансам на его аккаунте AWS.

Импортируем закрытый ключ в putty

PuTTY – прекрасный и наверное самый лучший SSH клиент для масдая. Который работает без нареканий и обладает всем необходимым функционалом. Бесплатный. Всё в нём хорошо. Но именно на этом поприще они решили отличиться и добавить чуть-чуть геморроя в процесс.

Вместе с PuTTY поставляется утилита PuTTYgen (PuTTY Key Generator).

Как мне добавить поддержку sudo?

Воспользуйтесь agent forwarding и

Как мне зарегистрировать в ca уже существующий хост?

Для хостов Ubuntu 18.04 LTS этот процесс аналогичен загрузке нового хоста, достаточно запустить

под рутом. Для других платформ вам потребуется портировать скрипт под ваши нужды.

После того как вы запустите и настроите все ваши хосты, у вас может возникнуть желание подправить настройки instanceAge вашего поставщика AWS для CA. Эти настройки хранятся в /etc/step-ca/config/ca.json. Инстанс любого возраста может запустить сам себя по умолчанию.

Заметка: Созданный скриптом Instance Identity токен — это одноразовый токен. Вы не можете перерегистрировать хост, вы можете лишь обновить его сертификат. Почему? Потому что любой пользователь на хосте может в любой момент получить доступ к IID, и мы не хотим, чтобы пользователи могли получить сертификат хоста от CA.

Как не следует пользоваться ssh

Еще в далеком 2004 году кто-то научил меня копипастить открытый ключ в файл

authorized_keys

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

chmod

Лишь однажды, когда в 2021 году OpenSSH объявил мой тип ключа устаревшим, я с неохотой заменил свой ключ. Теперь, за давностью лет, остается только гадать, на каких серверах мой открытый ключ все еще лежит. Может, у старых стартапов, с которыми я когда-то работал? У клиентов с фриланса? На криптоферме моей племянницы?

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

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

Копирование открытого ключа вручную

Если у вас нет парольного доступа, вам придется выполнить весь описанный выше процесс вручную.

Вам нужно будет вручную вставить содержимое файла id_rsa.pub в файл ~/.ssh/authorized_keys на удаленной машине.

Чтобы отобразить содержимое id_rsa.pub, на локальной машине введите:

cat ~/.ssh/id_rsa.pub

Вы увидите такой ключ:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44 tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q bqgZ8SeeM8wzytsY dVGcBxF6N4JS zVk5eMcV385gG3Y6ON3EG112n6d SMXY0OEBIcO6x PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77 xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66 PujOO xt/2FWYepz6ZlN70bRly57Q06J ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv Ow9gI0x8GvaQ== demo@test

Любым доступным способом подключитесь к вашему удаленному хосту.

Затем убедитесь, что каталог ~/.ssh существует. Эта команда при необходимости создаст каталог (и не сделает ничего, если он уже существует):

mkdir -p ~/.ssh

Теперь в этом каталоге вы можете создать или изменить файл authorized_keys. Вы можете добавить содержимое id_rsa.pub в конец файла authorized_keys с помощью этой команды:

Копирование открытого ключа по ssh

Если у вас нет ssh-copy-id, но есть пароль SSH для доступа к учетной записи на сервере, вы можете загрузить свои ключи с помощью обычного подключения SSH.

Сделать это можно при помощи команды cat, которая читает содержимое файла открытого SSH-ключа на локальном компьютере, и конвейера, который передаст ключ через SSH-соединение. После этого нужно убедиться, что каталог ~/.ssh существует в удаленной учетной записи, а затем проверить его содержимое.

Используйте символ перенаправления >>, чтобы добавить данные в файл, а не перезаписывать файл. Это позволит вам добавлять в файл ключи, не удаляя ранее добавленные данные.

Команда выглядит так:

Могу я изменить срок действия ssh сертификата?

Да. По умолчанию они действительны 16 часов, и в файле конфигурации CA (

ca.json

) под объектом

claims

, у вашего поставщика OIDC, вы можете внести изменения в соответствующих строчках, например:

Могу я использовать хост-бастион (инсталляционный сервер)?

Можете. Сначала выдайте всем своим хостам сертификаты, а затем добавьте в

known_hosts

на вашем бастионе CA ключ хоста:

Могу я использовать хосты на нескольких aws аккаунтах?

Конечно. Для этого достаточно добавить ID аккаунта в файл конфигурации CA (

/etc/step-ca/config/ca.json

) и перезапустить сервер CA.

Могу я пользоваться gcp или azure вместо aws?

Да! У

step-ca

есть поставщики для всех трех, вам только нужно будет внести правки в конфигурацию CA и скрипт загрузки хоста. Более подробно об этом можно почитать в

step-ca

Настройка ssh сертификатов на сервере

Выполним генерацию ключей SSH.

ssh-keygen -a 1000 -b 4096 -o -t rsa

Укажем путь хранения ключа и его имя

/root/.ssh/id_rsa

💡 В моем случае при создании сертификата для root оказалось важным указать жесткий путь /root/.ssh/, вместо относительного ~/.ssh/ чтобы избежать ошибки SSH Server refused our key.

Система так же создаст публичный ключ по данному пути.

Указываем ключевую фразу для доступа к приватному ключу.

Добавляем содержимое файла публичного ключа к файлу сертификата авторизации SSH.

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Перезапускаем SSH

sudo service ssh restart 

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

Добавьте приватный сертификат в подключение:

Connection > SSH > Auth > Private key file for authentication

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

💡 Если при входе на сервер вы получаете сообщение SSH Server refused our key, проверьте правильность прав на папку .ssh и файл authorized_keys, а так же укажите прямой путь до папки с ключами при.

Но я не хочу пользоваться certificate authority!

Возможно, вы думаете, что это сложно и страшно. Такую репутацию Certificate Authorities заработали из-за загадочных подробностей сертификатов TLS X.509, одного только числа акронимов в мире ИОК (инфраструктуры открытых ключей, PKI), и сложности таких инструментов, как

openssl.

Кроме того, у больших CA, например Let’s Encrypt, есть огромное число ответственностей по обеспечению безопасности интернета.

Мы не будем пользоваться Let’s Encrypt.

SSH сертификаты проще, чем TLS сертификаты. SSH CA попросту позволяет нам делегировать часть ответственностей в области аутентификации и авторизации множества хостов одному централизованному сервису.

В этом проекте мы настроим CA с тремя поставщиками — тремя методами выдачи сертификатов:

Приступим?

Подготовка папок

Выполняем подготовку папок и файла ключа на сервере.

Важный момент при настройке авторизации SSH по ключам — это указать правильные Права доступа на папку и файл ключа.

Выполните:

mkdir ~/.ssh

chmod 0700 ~/.ssh

touch ~/.ssh/authorized_keys

chmod 0644 ~/.ssh/authorized_keys

Предварительная настройка сервера

Разрешим вход с использованием публичного сертификата SHH на сервер и укажем путь до сертификата в настройках SSH, файл sshd_config.

nano /etc/ssh/sshd_config

Раскомментируйте или добавьте значения:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Преобразуем приватный ключ в формат ключа putty

💡 При попытке использовать скопированный ключ, PuTTY покажет ошибку: Unable to use key file (OpenSSH SSH-2 private key (new format)).

1. Скопируйте приватный ключ id_rsa (или содержимое ключа в файл) на локальный компьютер;
2. Запустите программу puttygen (из папки PuTTY);
3. Нажмите кнопку Load и выберите файл приватного ключа;
4. Введите пароль на приватный сертификат;
5. Нажмите Save private key для сохранения приватного ключа в нужном формате (вы можете изменить Key comment, это не повлияет на работу ключа).

Скопируйте открытый ключ на сервер

Теперь, когда у вас есть пара ключей SSH, следующий шаг – скопировать открытый ключ на сервер, которым вы хотите управлять.

Самый простой и рекомендуемый способ скопировать открытый ключ на удаленный сервер – использовать инструмент ssh-copy-id .

На терминале вашего локального компьютера настройте следующую команду:

ssh-copy-id [email protected]_ip_address

Устанавливаем ключи с помощью ssh-copy-id

Утилита используемая для доставки ключей на удалённые хосты. Можно применить её на текущий хост указав localhost вместо имени или адреса сервера к которому подключаемся

Финальная настройка сервера

Последний шаг настройки SSH — отключение возможности входа на сервер по паролю, в файле конфигурации.

nano /etc/ssh/sshd_config

Раскомментируйте или добавьте значениe:

PasswordAuthentication no

После чего перезапустите службу SSH.

sudo service ssh restart

Настройка авторизации по сертификату SSH — завершена!

Заключение

Теперь на вашем сервере настроена аутентификация на основе SSH-ключей, позволяющая войти в систему без пароля от учетной записи.

Подведение итогов

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

Вывод

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

Мы также показали, как отключить аутентификацию по паролю SSH и добавить дополнительный уровень безопасности на ваш сервер.

По умолчанию SSH прослушивает порт 22. Изменение порта SSH по умолчанию снижает риск автоматических атак.

Debian SSH Security