Авторизация по ключу SSH
Как работают ключи SSH?
Каждая пара ключей состоит из открытого и закрытого ключа. Секретный ключ сохраняется на стороне клиента и не должен быть доступен кому-либо еще. Утечка ключа позволит злоумышленнику войти на сервер, если не была настроена дополнительная аутентификация по паролю.
Открытый ключ используется для шифрования сообщений, которые можно расшифровать только закрытым ключом. Это свойство и используется для аутентификации с помощью пары ключей. Открытый ключ загружается на удаленный сервер, к которому необходимо получить доступ. Его нужно добавить в специальный файл
Как создать ключи SSH?
Сначала необходимо создать ключи ssh для аутентификации на локальном сервере. Для этого существует специальная утилита ssh-keygen, которая входит в набор утилит OpenSSH. По умолчанию она создает пару 2048 битных RSA ключей, которая подойдет не только для SSH, но и для большинства других ситуаций.
И так, генерация ключей ssh выполняется командой:
Утилита предложит вам выбрать расположение ключей. По умолчанию ключи располагаются в папке
/.ssh/. Лучше ничего не менять, чтобы все работало по умолчанию и ключи автоматически подхватывались. Секретный ключ будет называться id_rsa, а публичный id_rsa.pub.
Но все же, это необязательное дополнение и если не хотите, то вы можете просто нажать Enter. Тогда доступ по ключу ssh будет выполняться автоматически и вам не нужно будет что-либо вводить.
Теперь у вас есть открытый и закрытый ключи SSH и вы можете использовать их для проверки подлинности. Дальше нам осталось разместить открытый ключ на удаленном сервере.
Загрузка ключа на сервер
Когда генерация ключей завершена, нам осталось только загрузить ключ на сервер. Для загрузки ключа можно использовать несколько способов. В некоторых случаях вы можете указать ключ в панели управления сервером, например, сPanel или любой другой. Но мы такой способ рассматривать не будем. Мы рассмотрим ручные способы.
При первом подключении к серверу система может его не распознать, поэтому вам нужно ввести yes. Затем введите ваш пароль пользователя на удаленном сервере. Утилита подключится к удаленному серверу, а затем использует содержимое ключа id.rsa.pub для загрузки его на сервер в файл
/.ssh/authorized_keys. Дальше вы можете выполнять аутентификацию с помощью этого ключа.
Если такой способ по какой-либо причине для вас не работает, вы можете скопировать ключ по ssh вручную. Мы создадим каталог
/.ssh, а затем поместим наш ключ в файл authorized_keys с помощью символа >>, это позволит не перезаписывать существующие ключи:
Здесь вам тоже нужно набрать yes, если вы подключаетесь к новому серверу, а затем ввести пароль. Теперь вы можете использовать созданный ключ для аутентификации на сервере:
Если вы не захотели создать ssh ключ с доступом по паролю, то вы сразу же будете авторизованы, что очень удобно. Иначе, сначала вам придется ввести фразу-пароль для расшифровки ключа.
Отключение проверки пароля
Если пароль больше не будет использоваться, то для увеличения безопасности системы лучше его вовсе отключить. Но убедитесь, что ключ надежно сохранен и вы его не потеряете, потому что по паролю вы больше не войдете. Авторизуйтесь на сервере, затем откройте конфигурационный файл /etc/ssh/sshd_config и найдите там директиву PasswordAuthenticatin. Нужно установить ее значение в No:
sudo vi /etc/ssh/sshd_config
Теперь сохраните файл и перезапустите службу ssh:
sudo service ssh restart
Дальше будет возможно только подключение по ключу ssh, пароль не будет приниматься.
Выводы
В этой статье мы рассмотрели как выполняется авторизация по ключу ssh, настройка ключей ssh и добавить ssh ключ. Теперь вы можете войти на сервер без ввода пароля. Если у вас остались вопросы, спрашивайте в комментариях!
Установка и настройка SSH на сервере с Ubuntu
В этой статье мы создадим виртуальную машину с Ubuntu 18.04 LTS 64-bit и выполним настройки для безопасного взаимодействия с сервером.
SSH (Secure Shell) — протокол с шифрованием для безопасного обмена данными между элементами ИТ-инфраструктуры. Чаще всего SSH используется для управления серверами с операционными системами семейства Linux и различным сетевым оборудованием.
Чтобы создать сервер, откроем панель управления Selectel и перейдем в меню Облачная платформа, затем выберем подходящий дата-центр и создадим нужный сервер.
В нашем примере используется виртуальный сервер с фиксированной конфигурацией в виде 1 ядра CPU, 1 Гб оперативной памяти, 10 Гб пространства на жестком диске и операционной системой Ubuntu 18.04 LTS 64-bit.
Далее нажимаем Создать и уже через несколько минут сервер готов к работе. Для удобства доступа к серверу, также был заказан плавающий внешний IP-адрес.
После успешного создания сервера, можно запускать консоль и настроить подключение по SSH. В Ubuntu за это отвечает утилита OpenSSH. В статье мы рассмотрим настройку доступа по ключам, настройку firewall, отключение аутентификации по паролю и проделаем некоторые другие вещи.
Как установить OpenSSH
OpenSSH — это бесплатный SSH-сервер, дающий возможность интерактивного управления сервером. Для установки SSH на сервер воспользуемся встроенным в Ubuntu пакетным менеджером apt:
В большинстве дистрибутивов OpenSSH-сервер уже присутствует в системе и его установка не требуется. В случае отсутствия OpenSSH, вышеуказанная команда выполнит установку.
Теперь добавим SSH-сервер в автозагрузку. При следующем запуске сервера, операционная система выполнит автоматический запуск SSH-сервера. Как и в случае с другими сервисами systemd позволяет управлять параметрами запуска, автозагрузки и рестарта демона OpenSSH. Включим автозапуск:
В результате получим:
Проверим работоспособность утилиты:
И убедимся, что всё корректно работает:
Как настроить SSH
Настройка SSH на Ubuntu необходима для улучшения защищенности системы. Например, можно отключить возможность входа от имени пользователя root или изменить порт подключения со стандартного 22 на произвольный. Лучше использовать порты из верхнего диапазона (50000-65000). Напомним, что в стеке протоколов TCP/IP доступно 65536 портов.
Настройка выполняется выполняется в конфигурационном файле. Перед его модификацией, создадим резервную копию.
Вот теперь можно менять порт. Все изменения конфигурации SSH выполняются в файле /etc/ssh/sshd_config. Откроем его на редактирование:
Раскомментируем строку Port 22 и изменим значение на 55555. Но мы должны вас предостеречь, боты прежде всего сканируют порты с одинаковыми цифрами, поэтому в промышленных средах лучше использовать номер порта с отличными друг от друга цифрами.
Далее нужно отключить возможность входа на сервер учетной записи суперпользователя (root) и добавить возможность входить через ключи. Для этого изменим значения параметров PermitRootLogin на no и PubkeyAuthentication на yes:
После этого следует перезагрузить демон SSH. Соединение при этом будет разорвано и подключиться можно будет через новый порт и пользовательскую учетную запись (она должны быть предварительно создана).
Переподключимся от обычной учетной записи и по другому порту:
После успешного подключения можно продолжать работу с сервером.
Как создать пару ключей RSA
Еще один способ аутентификации на сервере — пара ключей RSA: открытый и закрытый. Открытый хранится на сервере, к которому будет выполняться подключение, а закрытый на удаленном компьютере (или другом сервере) откуда выполняется подключение.
На схеме ниже иллюстрация безопасного обмена ключами между Алисой и Бобом. Злоумышленник Ева может читать сообщения, если они не зашифрованы. Здесь Алиса или Боб шифруют сообщение при помощи открытого ключа принимающей стороны, которая его дешифрует при помощи своего закрытого ключа.
Чтобы сгенерировать такую пару ключей, достаточно выполнить команду:
Команду нужно выполнять на своей рабочей станции от имени пользователя, который будет в дальнейшем подключаться к удаленному компьютеру. Путь к хранению ключей можно оставить по умолчанию:
Ключи созданы, можно переходить к следующему шагу — копированию открытого ключа на удаленный сервер. Предварительно убедитесь, что на том сервере создана учетная запись, от имени которой вы будете подключаться.
Как скопировать открытый ключ на сервер
Чтобы скопировать ключ на удаленный сервер, выполним следующую команду:
В этом примере 95.213.154.235 — это IP-адрес удаленного сервера. После ввода пароля, ключ копируется папку .ssh домашней директории пользователя.
Вывод обеих команд на скриншоте ниже.
Как пройти аутентификацию на сервере через созданный ключ
Сразу же после выполнения копирования, проверим доступ при помощи созданной пары ключей:
Если подключение по SSH будет успешным — все настройки были выполнены корректно.
Как выполнить отключение аутентификации по паролю
Для отключения возможности входа по паролю необходимо в файле /etc/ssh/sshd_config отредактировать значение PasswordAuthentication и присвоить no.
После изменения настроек перезагружаем службу SSH:
Теперь при попытке подключения пользователем, для которого не определена пара ключей, будет выдаваться ошибка подключения.
При этом подключение при помощи ключа будет успешным.
Отключение доступа паролю — верная стратегия повышения безопасности сервера. Особенно в публичных облаках. Однако, если ключ будет утерян, это станет серьезной проблемой. Поэтому важно его хранить в надежном месте или пользоваться специализированными инструментами, например, аппаратным устройством Yubikey.
Как настроить стандартный firewall
В Ubuntu есть встроенный фаервол Netfilter, который может управляться как непосредственно вызовом утилиты iptables с параметрами так и специальной утилитой UFW (Uncomplicated Firewall). Мы разберем оба варианта.
Iptables на нашем демо-стенде уже установлен, но если в вашем дистрибутиве его нет — можно воспользоваться пакетным менеджером apt:
При работе с iptables можно настроить три типа правил: INPUT — для входящих соединений, OUTPUT — для исходящих и forward для транзитных (используется для маршрутизаторов). Для сервера актуальны первые два.
При обработке пакетов возможно выполнение следующих действий: ACCEPT — разрешить прием пакета, DROP — удалить пакет, REJECT — отклонить пакет и отправил уведомление об отклонении отправителю, LOG — записать пакет в лог и QUEUE — отправить пакет приложению.
В iptables доступны следующие функции управления:
Например, чтобы посмотреть настроенные правила можно выполнить команду
Теперь попробуем заблокировать все пакеты от узла 10.10.10.10:
При помощи комбинаций перечисленных выше опций можно настроить любую требуемую логику работы с сетевыми пакетами.
Если перечисленные выше опции показались сложными, можно упростить задачу настройки фаервола и воспользоваться утилитой ufw. Перед началом работы, установим ее при помощи пакетного менеджера apt:
После установки можно начинать работать с правилами. Разрешим все исходящие соединения и запретим все входящие:
В примерах выше мы меняли порт для доступа по SSH на 55555. Создадим правило для доступа по этому порту:
Теперь включим сам фаервол.
Обратите внимание на предупреждение системы об отключении SSH-подключений, если вдруг вы забыли добавить соответствующее правило. Но мы его добавили, поэтому смело включаем фаервол.
После включения фаервола, проверим его настройки командой:
Дополнительно можно настроить доступ с определенного IP-адреса (или диапазона адресов), на определенный порт.
При помощи правил UFW можно также применять правила к определенным сетевым интерфейсам сервера.
Как настройки подключения по SSH влияют на безопасность
В этом разделе разберем основные настройки для повышения уровня безопасности SSH. Все настройки выполняются в уже известном конфигурационном файле /etc/ssh/sshd_config.
Первая настройка — проверка соответствия DNS-имени IP-адресу клиента. За это отвечает параметр UseDNS.
Следующий шаг к безопасности — запрет пустых паролей. Задается в параметре PermitEmptyPasswords.
Дополнительно можно ограничить количество неудачных попыток подключения:
Еще один подход к ограничению несанкционированных подключений — задание пользователей и групп, которым разрешен доступ по SSH. Они перечисляются в параметрах AllowUsers и AllowGroups.
Дополнительно, можно задать время, в течении которого система ожидает от пользователя ввода пароля. По умолчанию это две минуты, но лучше уменьшить до 30 секунд.
Отключение пользователя при бездействии позволит предотвратить доступ злоумышленника, если пользователь вдруг отлучился от своего рабочего места. Значение задается в секундах
Мы перечислили основные параметры для повышения безопасности SSH-соединений, однако, можно выполнять и более тонкую настройку. Полный список команд можно найти в официальной документации.
Нельзя не упомянуть про эффективный инструмент борьбы с попытками аутентификации — утилите fail2ban. Это сервис, который читает лог безопасности и блокирует злоумышленников по IP. Штатно устанавливается при помощи apt:
После установки появляются два конфигурационных файла: /etc/fail2ban/fail2ban.conf и /etc/fail2ban/jail.conf. Первый отвечает за настройки запуска fail2ban, а второй за настройки защиты конкретных сервисов.
Заключение
Мы рассказали об основных настройках протокола SSH, которые помогут уберечь Ubuntu-сервер от несанкционированного доступа. Особенно важно их использовать при расположении сервера в публичных облаках с публичным IP-адресом. На скриншоте ниже вы видите журнал безопасности системы, на которой мы проводили перечисленные в этой статье настройки. В нем видно, что попытки авторизаций под разными пользователями (root, system и другими) происходят регулярно.
Перечисленных в этой статье настроек достаточно для обеспечения базовой безопасности сервера и предотвращения его вовлечения в бот-сети.
Dreamcatcher.ru
Аутентификация на SSH сервере с использованием ключей
Автор: Brian Hatch
Перевод: Сгибнев Михаил
OpenSSH кроме паролей поддерживает еще несколько методов аутентификации. Он может быть сконфигурирован на использование методов PAM (Pluggable authentication modules), протокола Challenge/Response, Kerberos, аутентификации по доверенным хостам и такая экзотика как ключи X509. Но самым популярным является метод Identity/Pubkey.
Целью использования идентификации Identity/Pubkey является исключение использования статических паролей. Вместо того, чтобы каждый раз набирать пароли, которые могут быть перехвачены кейлоггером или просто подсмотрены, у нас на диске имеется пара ключей, которые и используются для проверки подлинности. Ваша учетная запись на сервере SSH имеет список Identities/Pubkeys, которому можно доверять и если Вы сможете доказать, что у вас есть и публичный и приватный ключ, то доступ будет предоставлен без запроса пароля.
Вот некоторые из положительных моментов этого типа аутентификации:
В этой статье мы рассмотрим методу создания ключей и конфигурирование учетной записи.
Создание Identity/Pubkey
В оригинальной реализации SSHv1 Вы могли создать Identity, которое было парой RSA публичного и приватного ключей. В SSHv2 формат этих ключей был изменен, стали поддерживаться ключи RSA и DSA, и эта аутентификация была переименована в Pubkey. В контексте данной статьи эти обозначения будут использоваться взаимозаменяемо, так как реализуют идентичные функции.
mydesktop$ cat id_rsa
——BEGIN RSA PRIVATE KEY——
MIICWgIBAAKBgQCc+1oixZ/g84gpZH0NeI+CvVoY5O0FOCSpFCbhUGJigQ6VeKI5
gpOlDztpJ1Rc+KmfZ2qMaftwwnLmefhk1wPcvfZvvLjfdmHY5/LFgDujLuL2Pv+F
7tBjlyX9e9JfXZau2o8uhBkMbb3ZqYlbUuuoCAnUtL5uZUiiHM0BAtnGAd6epAYE
gBHw1xnqsy+mzbuWdLEVF7crlUSsctwGapb6/SEQgEXFm0RITQ3jCY808NjRS3hW
Z+uCCO8GGUsn2bZpcGXa5vZzACvZL8epJoMgQ4D0T50rAkEA0AvK4PsMF02Rzi4E
mXgzd1yCa030LYR/AkApG1KT//9gju6QCXlWL6ckZg/QoyglW5myHmfPR8tbz+54
/lj06BtBA9iag5+x+caV7qKth1NPBbbUF8Sbs/WI5NYweNoG8dNY2e0JRzLamAUk
jK2TIwbHtE7GoP/Za3NTZJm2Ozviz8+PHPIEyyt9/kzT0+yo3KmgsstlqwIBIwKB
XdBh42izEWsWpXf9t4So0upV1DEcjq8CQQDEKGAzNdgzOoIozE3Z3thIjrmkimXM
J/Y3xQJBAMEqZ6syYX/+uRt+any1LADRebCq6UA076Sv1dmQ5HMfPbPuU9d3yOqV
j0Fn2H68bX8KkGBzGhhuLmbrgRqr3+SPM/frUj3UyYxns5rnGspRkGB3AkALCbzH
9EAV8Uxn+Jhe5cgAC/hTPPdiwTJD7MpkNCpPuKRwrohytmNAmtIpKipAf0LS61np
wtq59ssjBG/a4ZXNn32n78DO0i6zVV5vwf8rv2sf
——END RSA PRIVATE KEY——
mydesktop$ cat id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAcMJy5nn4ZNcD3L32b7y433Zh2IEAnPt
aIsWf4POIKWR9DXiPgr1aGOTtBTgkqRQm4VBiYoEOlXiiOYKTpQ87aSdUXPipn
2dqjGn7OfyxYA7oy7i9j7/hYytkyMGx7ROxqD/2WtzU2SZtjs74s/PjxzyBMsr
ff5M09PsqNypoLLLZas= xahria@mydesktop
Обратите внимание, что ‘ssh-rsa…xahria@mydesktop’ это одна строка, а не несколько.
Как Вы могли убедиться, ssh-keygen создал два файла: id_rsa и id_rsa.pub. В первом файле хранится приватный ключ, защищенный кодовой фразой, введенной Вами при создании, НИКОМУ не давайте копаться в этом файле. Второй файл — Ваш публичный ключ, он не содержит никаких тайн и может быть доступен любому встречному-поперечному. В случае утраты он может быть восстановлен из приватного ключа.
Типы ключей SSH
Аргумент
Имя по умолчанию
Протокол
Пример заголовка
-t rsa1
identity
SSH 1 protocol only
1024 35 118118225938285…
-t rsa
id_rsa
SSH 2 protocol only
ssh-dss AAAAB3nzaC1kc3M…
-t dsa
id_dsa
SSH 2 protocol only
ssh-rsa AAAAB3NzaC1yc2E…
Разрешение Identity/Pubkey аутентификации на сервере
После того, как мы создали ключи, необходимо разрешить данный тип аутентификации на сервере SSH. Сначала определим тип аутентификации — Pubkey или Identity, установив следующие настройки в sshd_config:
# Should we allow Identity (SSH version 1) authentication?
RSAAuthentication yes
# Should we allow Pubkey (SSH version 2) authentication?
PubkeyAuthentication yes
Проверьте наличие этих строк в файле конфигурации sshd_config (обычно он находится в каталоге /etc/ssh/), при необходимости добавьте и перезапустите сервис.
Содержимое файла authorized_keys
# Now let’s log in and create the authorized_keys file
mydesktop$ ssh ssh-server
xahria@ssh-server’s password: (enter password)
# Let’s check out the file
ssh-server$ cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAcMJy5nn4ZNcD3L32b7y433Zh2IEAnPt
aIsWf4POIKWR9DXiPgr1aGOTtBTgkqRQm4VBiYoEOlXiiOYKTpQ87aSdUXPipn
2dqjGn7OfyxYA7oy7i9j7/hYytkyMGx7ROxqD/2WtzU2SZtjs74s/PjxzyBMsr
ff5M09PsqNypoLLLZas= xahria@mydesktop
# Make sure permissions are paranoid
ssh-server$ chmod 600 authorized_keys
[ad name=»Google Adsense»]
Пришла пора проверить. что мы наваяли:
mydesktop$ ssh ssh-server
Enter passphrase for key ‘/home/xahria/.ssh/id_rsa’:
Ваш SSH клиент будет сначала пробовать пройти аутентификацию по Pubkey/Identity, в случае неудачи — идентификацию по паролю. Он будет искать три имени файлов, заданных по умолчанию, если Вы не указали файл ключа явно и передаст его серверу.
Рассмотрим процесс подключения по разделениям:
debug1: PEM_read_PrivateKey failed
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
xahria@ssh-server’s password: (Enter Unix password)
Для наглядности, в этом примере мы вводим неправильное кодовое слово для дешифровки приватного ключа. Также Вы можете заметить, что были найдены файлы identity и id_rsa, хотя они могут использоваться только с SSHv2.
Выбор ключей
Если Вы имеете один ключ для каждого типа, то вы можете использовать стандартные имена файлов и ssh-клиент самостоятельно найдет их и использует, но может так случиться, что Вы используете для аутентификации разные файлы:
/.ssh/special_ssh_key ssh-server
Enter passphrase for key ‘/home/xahria/.ssh/special_ssh_key’:
Следущая опция создаст в Вашем
/.ssh/config указание на отображение еспользуемого ключа:
mydesktop$ cat
/.ssh/config
Host ssh-server
IdentityFile
mydesktop$ ssh ssh-server
Enter passphrase for key ‘/home/xahria/.ssh/special_ssh_key’:
Обратите внимание, что переменная config всегда равна IdentityFile, независимо от того, используется Pubkey или Identity.
Безопасность кодовой фразы
Ваши приватные ключи могут и должны шифроваться кодовой фразой, так как это оберегает Ваш ключ от компрометации. Даже если Вы установили соответствующие права доступа, но не защитили ключь кодовой фразой, без всяких проблем полюбоваться Вашим ключом сможет пользователь root. Так что не спускайте на тормозах это дело.
authorized_keys2
Старые версии OpenSSH использовали два различных публичных ключа для доступа к серверу — authorized_keys для Identities (SSHv1) и authorized_keys2 для Pubkeys (SSHv2). Позже было решено, что это глупо и теперь используется один файл для ключей всех типов, но при отсутствии подходящего ключа будет проверен и authorized_keys2. Более поздние версии OpenSSH могут вполне прекратить поддерживать authorized_keys2 вовсе.
# make a hard link so they are the same file, just different
# file names.
ssh-server$ ln authorized_keys authorized_keys2
Уважайте труд автора и переводчика, не ищите дешевой славы — оставляйте ссылки и копирайты при размещении статьи на своем ресурсе!
Реклама на сайте висит не просто так! Спасибо!
