Настройка аутентификации на основе SSH-ключей на сервере Linux | 8HOST.COM

Что такое ssh

SSH (Secure Shell) — это сетевой протокол, предназначенный для удалённого управления сервером и передачи данных по зашифрованным TCP соединениям. Большинство хостингов, даже виртуальных, сегодня предоставляет доступ как по FTP, так и по SSH. На мой взгляд, это здорово, SSH намного удобнее и безопаснее в использовании.

Установка TCP-соединения

Не буду подробно останавливаться на принципе работы стека TCP/IP, так как эта тема достаточно хорошо задокументирована в Рунете. При необходимости вы легко найдёте информацию.

На этом этапе происходит сетевое подключение клиента к серверу на TCP-порт, указанный в опции Port (по умолчанию: 22) в файле конфигурации сервера /etc/ssh/sshd_config.

Открытие защищенного канала

2.1 Обмен идентификационными данными

После установки TCP-соединения, клиент и сервер (далее по тексту – стороны) обмениваются версиями SSH-протокола и другими вспомогательными данными, необходимыми для выяснения совместимости протоколов и для выбора алгоритмов работы.

2.2 Выбор алгоритмов: обмена ключами, шифрования, сжатия и т.п.

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

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

ssh -Q kex

Список доступных в системе симметричных алгоритмов (используются для шифрования канала):

ssh -Q cipher

Список типов ключей для авторизации у клиента:

ssh -Q key-cert

Дополнено по замечанию onix74:

Все используемые в публикации команды актуальны для версии OpenSSH 7.6 из Ubuntu 18.04 LTS.

2.3 Получение сессионного ключа шифрования

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

Аутентификация клиента

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

В общих чертах, аутентификация посредством ключей происходит следующим образом:

Уровень подключения

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

На этом уровне обеспечивается: мультиплицирование каналов (возможность работы множества каналов к одному серверу за счет объединения их в один канал), туннелирование и т.п.

Fail2ban для защиты ssh сервера

Самым действенным способом защиты SSH является защита от перебора паролей. Её может обеспечить утилита fail2ban.

Авторизация ssh по ключам

Намного безопаснее, удобнее и правильнее будет настроить ssh авторизацию без пароля. Для этого будет использоваться авторизация по ключу.

Для настройки нам понадобится файловый менеджер, например, Far Manager с плагином WinSCP, и Putty

Итак, вот инструкция:

Аутентификация через ssh-ключи

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

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

Генерация с помощью ssh-keygen

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

Для большей безопасности и скорости работы рекомендуется использовать более новый формат ключей Ed25519. Открытый ключ Ed25519 компактен. Он содержит только 68 символов по сравнению с RSA 3072, который имеет 544 символа. Генерирование ключа также почти так же быстро, как и процесс подписания.

Ещё один способ ограничения доступа по ip

Можно воспользоваться следующей директивой:

Закрыть доступ по ip

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

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

1. Открываем /etc/hosts.allow и добавляем туда

   SSHD: 192.168.1.1

   где 192.168.1.1 — ваш IP. Если у вас динамический IP, определите IP с маской подсети и запишите Вашу подсеть вместо IP, например:

   SSHD: 192.168.0.0/16

2. Открываем /etc/hosts.deny и добавляем туда:

   SSHD: ALL

Теперь никто, кроме вас, не сможет авторизоваться на сервере по SSH.

Запретить авторизацию под root

PermitRootLogin no

По умолчанию no. Если yes, можно авторизовываться под рутом. Под root работать небезопасно, лучше создать своего пользователя и работать под ним.

Запретить связь по старому протоколу

Здесь мы определяем, что связь возможна только по протоколу v2

Protocol 2

Использование агента putty (pageant)

В пакете PuTTY доступна служебная программа pageant — это агент аутентификации PuTTY. Запустите утилиту и кликните на иконку в панели задач, чтобы добавить ключ. Введите пароль и все.

При подключении через агента появится подобное сообщение: «Authenticating with public key “rsa-key-20220316″ from agent».

Если подключение без пароля на срабатывает, на это может быть ряд причин:

• ключ не принят сервером (см. журнал активности PuTTY);
• файл authorized_keys или каталог ~/.ssh, хранящийся на сервере имеет неверно настроенные права доступа (chmod -R u rwX,go-rwx ~/.ssh).
• PuTTY не настроен для использования агента SSH.

Использование утилиты ssh-agent из пакета openssh

Если вы используете Linux или Unix-подобные системы, наиболее вероятно, что в вашей системе используется OpenSSH. В рамках OpenSSH есть утилита ssh-agent, которая предназначена для кэширования расшифрованных ключей.

Для начала работы запустите ssh-agent:

Как ограничить доступ по ssh

Все изменения вносятся в /etc/ssh/sshd_config
Чтобы изменения вступили в силу, необходимо перезагрузить SSH

Как перезагрузить fail2ban

service fail2ban restart

Как перезагрузить ssh

service sshd restart

или

/etc/init.d/ssh restart

Как проверить fail2ban

Чтобы проверить, верно ли работает fail2ban, можно запустить клиента и проверить статус sshd:

fail2ban-client status sshd

Если всё верно сделано, увидите надпись:

Status for the jail: sshd

Если что-то не так, то:

fail2ban                [1284]: ERROR   NOK: ('ssh',)
Sorry but the jail 'ssh' does not exist

В таком случае, вернитесь выше и перепроверьте шаги настроек

Как работают ssh-ключи?

Существует несколько различных способов входа в SSH-сервер. В этом руководстве мы рассмотрим настройку аутентификации на основе ключей SSH. Ключи SSH – это простой, но чрезвычайно безопасный способ входа на ваш сервер.

Хотя пароли отправляются на сервер безопасным путем, как правило, они не достаточно сложные или слишком короткие, а потому в ходе повторяющейся атаки подбора их можно взломать. Современная вычислительная мощность в сочетании с автоматизированными сценариями позволяет взламывать аккаунты путем brute force атак.

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

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

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

Открытый ключ загружается на удаленный сервер, на котором нужно настроить аутентификацию по ключам SSH. Ключ добавляется в специальный файл ~/.ssh/authorized_keys в учетной записи пользователя, с помощью которого нужно войти на сервер.

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

Как сбросить бан fail2ban

Сбрасывает все баны всех IP всех служб:

fail2ban-client unban --all

Если нужно сбросить конкретную службу, например SSH, и конкретный IP 1.2.3.4:

fail2ban-client set sshd unbanip 1.2.3.4

или все IP:

fail2ban-client set sshd unbanip --all

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

Ключевая пара

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

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

Конвертация ключей

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

Представьте простую и вполне реальную ситуацию. Вы сгенерировали ключевую пару и хотели бы распространить ее на других своих устройствах. Проблемой может стать желание перенести ключевую пару на Linux, которая была сгенерирована при помощи PuTTYgen под Windows.

К сожалению, если скопировать такой ключ и попытаться произвести вход на SSH сервер, мы скорее всего получим ошибку: Load key «/root/.ssh/id_rsa»: invalid format, либо подобные.

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

Самый просто способ — запустить PuTTYgen, загрузить сохраненную закрытую часть ключа при помощи кнопки Load.

Перейти в раздел Conversions и выбрать меню Export OpenSSH key.

Инструмент позволит нам сохранить закрытую часть в формате (PEM), который генерирует ssh-keygen.

Точно таким же методом мы можем производить обратное преобразование из PEM в формат PuTTY. Таким образом, нет необходимости создавать разные сущности ключей, мы сможем использовать одну.

Конфигурация сервера. разрешение аутентификации по ключу и добавление ключей на windows.

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

Для этого запустим PowerShell от имени администратора и выполним команду:

((Get-Content -path C:ProgramDatasshsshd_config -Raw) `
-replace '#PubkeyAuthentication yes','PubkeyAuthentication yes' `
-replace '#PasswordAuthentication yes','PasswordAuthentication no')`
 | Set-Content -Path C:ProgramDatasshsshd_config; Restart-Service sshd

Добавляем открытую часть ключа для аутентификации. Создаем папку .ssh в профиле пользователя а также, вместо ssh-rsa, записываем в файл authorized_keys открытую частью ключа.

Конфигурация сервера. установка openssh на linux

Для установки OpenSSH сервера на CentOS выполним следующую команду:

sudo yum install openssh-server -y

Итогом должна быть установка, обновление или сообщение об актуальности версии OpenSSH. В моем случае установлена актуальная версия инструмента.

Для установки OpenSSH сервера на Ubuntu выполним следующие команды:

sudo apt-get update
sudo apt-get install openssh-server -y

Результатом также будут установка, обновление или сообщение об актуальности версии OpenSSH.

Запустим службу sshd выполнив команду:

sudo systemctl start sshd
sudo systemctl enable sshd

Конфигурация сервера. установка openssh на windows

Компонент OpenSSH Server доступен в Windows из коробки начиная с версии Windows 10 1809 и Windows Server 2022. Для быстрой установки откроем Powershell от имени администратора и введем команду:

Get-WindowsCapability -Online | ? Name -like 'OpenSSH*' | Add-WindowsCapability -Online

Будет запущен процесс установки компонента OpenSSH Server.

В дополнение к вышеуказанной команде выполним еще пару команд. Запустим службу sshd и выберем тип запуска — Автоматический.

Start-Service sshd; Set-Service -Name sshd -StartupType 'Automatic'

Создадим разрешающее правило в Firewall Windows.

New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True `
-Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

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

Следующий шаг — копирование ключа в удаленную систему. Самый простой путь — использовать утилиту ssh-copy-id. Укажите в команде удаленный хост, к которому нужно подключиться, и аккаунт пользователя сервера. В этот аккаунт утилита скопирует открытый ключ.

ssh-copy-id [email protected]
...

ssh [email protected]
...

Другой вариант — сделать это вручную, добавив ключ через копирование и вставку прямо в в текстовом редакторе при редактировании ~/.ssh/authorized_keys. Теперь попробуйте войти в систему и посмотрите, работает ли аутентификация по ключу.

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

Теперь нужно выгрузить открытый ключ на удаленный сервер.

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

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

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

Мы вручную добавим содержимое вашего файла 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 на ваш удалённый сервер, мы можете загрузить свой ключ вручную.

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

Кроме этого, нам потребуется убедиться, что директория ~/.ssh существует, а также имеет корректные права доступа для используемого нами аккаунта пользователя.

Далее мы сможем отправить содержимое файла ключа в файл authorized_keys внутри этой директории. Мы будем использовать синтаксис >> для добавление данных в конец файла вместо перезаписи содержимого файла. Это позволит нам добавить ключ без удаления ранее добавленных ключей.

Команда выглядит следующим образом:

Логирование ssh подключений по сертификату

Мне необходимо знать, когда и какой сертификат подключался к серверу. По-умолчанию такой информации чаще всего в логах не остается. Исключение я заметил только в CentOS 7. Там с дефолтными настройками ssh и уровнем логирования INFO отображается отпечаток ключа в логе:

# cat /var/log/secure

Настройка fail2ban

Удаляем дефолтный файл настроек fail2ban для Debian

cat /dev/null >/etc/fail2ban/jail.d/defaults-debian.conf

Затем, запускаем создание собственного файла настроек

nano /etc/fail2ban/jail.d/sshd.conf

Открывается редактор, туда вписываем следующее:127.0.0.1/8 — меняете на свой IP (или диапазон, если IP динамический). Чтобы добавить несколько IP или диапазонов, указываем их через пробел.

[sshd]
enabled   = true
port      = 9724
filter    = sshd
ignoreip  = 127.0.0.1/8
logpath   = /var/log/auth.log
findtime  = 300 
maxretry  = 3
bantime   = 3600

• port — по какому порту банить IP, попавший на bantime. Если на сервере нестандартный порт SSH, укажите его здесь
• ignoreip — белый список IP, меняем на свои значения
• findtime — время, в течение которого можно ошибиться не более maxretry раз
• maxretry — максимальное число попыток авторизоваться по SSH в течение findtime
• bantime — время бана

Ещё можно добавить нижеследующий код в дополнение к вышеуказанному, он поможет от активного брутфорса пароля SSH ботнетами:

[sshlongterm]
enabled   = true
filter    = sshd
logpath   = %(sshd_log)s
banaction = iptables-allports
findtime  = 1d
maxretry  = 21
bantime   = 1w

• banaction — как банить. Чтобы банить по всем портам, указываем iptables-allports, в таком случае, указывать port не обязательно

После внесения изменений нужно перезагрузить fail2ban

Настройка ssh

Настройка будет происходить под выделенный сервер, VDS, VPS на Debian, Ubuntu. Конфигурационный файл располагается тут: /etc/ssh/sshd_config.
Если у вас обычный хостинг, всё и так должно быть настроено как надо, переходите к разделу авторизации по ключам.

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

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

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

Здесь все просто. Во всех известных мне дистрибутивах авторизация по сертификатам уже настроена, нужно просто добавить этот сертификат на сервер. Сделаем это.

# mkdir ~/.ssh
# chmod 0700 ~/.ssh
# touch ~/.ssh/authorized_keys
# chmod 0644 ~/.ssh/authorized_keys

В файл authorized_keys вставляйте скопированный ключ из окна puttygen. Сохраняйте и подключайтесь с помощью сертификата. В putty сертификат нужно указать в разделе Connection -> SSH -> Auth.

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

Теперь можно подключаться, необходимости перезапускать службу ssh нет.

Настройка и использование ssh [айти бубен]

root@vps:~# usermod -aGsudo remuserbak

root@vps:~# id remuserbak
uid=1000(remuserbak)gid=1000(remuserbak)groups=1000(remuserbak),27(sudo)

remuserbak@vps:~$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig
[sudo] password for remuserbak:

sudo sshd -T

remuserbak@vps:~$ sudonano/etc/ssh/sshd_config
 
# Authentication:
PermitRootLogin no # запретить удалённый доступ для root
AllowUsers user1 user2 # список пользователей, которым разрешён доступ по SSH

$ sudo systemctl restart ssh.service
или
$ sudo service sshd restart

User root from 222.187.238.57 not allowed because not listed in AllowUsers

$ ssh-keygen-b2048-t rsa -f ~/.ssh/work_key -C"Key for Work stuff"
$ ssh-keygen-b2048-t rsa -f ~/.ssh/myvps -C"Key for vps"

ssh-copy-id -i work_key.pub USER@HOST

$ touch ~/.ssh/config
$ chmod 600 ~/.ssh/config

IdentityFile ~/.ssh/work_key
IdentityFile ~/.ssh/myvps

Host *.company.org
  IdentityFile ~/.ssh/work_key
  User workusername
 
Host 127.65.43.21
  IdentityFile ~/.ssh/myvps
  User bliznezz
  Port 22322

Используемые опции:
-b bits
    Определяет число бит в ключе при его создании. Минимум это 512 бит. Как правило, 2048 бит считается достаточным.
По умолчанию используется 2048 бит. 
-c
    Запрашивает изменение комментария в файлах приватных и публичных ключей. Операция поддерживается только для RSA1-ключей.
Программа предложит указать файл содержащей приватный ключ, спросит ключевое слово, если таковое имеется, и новый комментарий. 
-е
    Эта опция позволяет прочитать приватный или публичный OpenSSH-файл ключа и распечатать его в "SECSH Public Key File Format"
в стандартный вывод. Также, данная опция позволяет экспортировать ключи для использования с некоторыми коммерческими
реализациями SSH. -f filename Определяет имя файла для файла ключа. 
-i
    Эта опция считывает не зашифрованный SSH2-совместимый приватный (или публичный) файл ключа и распечатывает OpenSSH-совместимый
приватный (или публичный) ключ в стандартный вывод. Также, ssh-keygen считывает "SECSH Public Key File Format". Данная опция
позволяет импортировать ключи из некоторых коммерческих реализаций SSH. 
-l
    Показывает распечатку указанного приватного или публичного ключа. Также поддерживаются приватные RSA1-ключи. Для RSA- и
DSA-ключей ssh-keygen предпримет попытку найти соответствующие публичные ключи и их отпечатки. 
-p
    Запрашивает изменение ключевой фразы приватного ключа вместо создания нового приватного ключа. Программа предложит
указать имя файла содержащего приватный ключ, старую ключевую фразу и, дважды, новую ключевую фразу. 
-q
    Тихий ssh-keygen. Используется в работе /etc/rc при создании нового ключа. 
-y
    Эта опция читает приватный OpenSSH-формат файла и печатает публичный ключ OpenSSH в стандартный вывод. 
-t type
    Определяет тип создаваемого ключа. Допустимыми являются значения "rsa1", для протокола версии 1, и "rsa1" или "dsa",
для протокола версии 2. 
-В
    Этот параметр отображает "bubblebabble" дайджест заданного файла публичного или приватного ключа. 
-C comment
    Обеспечивает ввод нового комментария. 
-D reader
    Копировать сохранённый публичный RSA-ключ со smartcard в устройстве reader. 
-N new_passphrase
    Обеспечивает ввод новой ключевой фразы. 
-P passphrase
    Обеспечивает ввод (старой) ключевой фразы. 
-D reader
    Копировать публичный RSA-ключ на smartcard в устройстве reader. 

%ssh-keygen-t dsa
Generating public/private dsa key pair.
Enter fileinwhich to save the key (/home/user/.ssh/id_dsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in/home/user/.ssh/id_dsa.
Your public key has been saved in/home/user/.ssh/id_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com

cat ~/.ssh/id_rsa.pub |ssh root@ip-адрес-сервера 'cat >> ~/.ssh/authorized_keys'

ssh-copy-id -i .ssh/id_rsa.pub remuserbak@xxx.xxx.xxx.xxx

$ ssh-keygen -N fgdfgytyityirioyroryoyuouiy -t rsa -C test4@test4 -f test4 -q

$ ssh-keygen -t rsa -N "" -C test4@test4 -f test4 -q

От теории к практике

Ну а теперь, думаю, у читателей назрел вполне закономерный вопрос: а зачем нужно знать все эти тонкости работы SSH-протокола, если для повседневной работы достаточно знаний команд создания ключей (ssh-keygen), открытия терминальной сессии (ssh), передачи файлов (scp)?

В качестве ответа, можно вспомнить тему о смене стандартного порта SSH на какой-то другой, которая постоянно становится причиной холивара на Хабре…

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

В ситуации же, когда на 22-м порту ничего нет, или порт защищён с помощью iptables (либо надстройками над ним типа fail2ban), то злоумышленник будет дропнут ещё на этапе установки TCP-соединения.

Наиболее интересно описанное выглядит в виде таблицы*

* — значения параметров (высокий, средний, низкий) носят относительный характер и служат только для сравнения показателей.

** — имеется ввиду расход ресурсов сервера (процессор, диск, сетевой канал и т.п.) на обработку лавины запросов, обычно идущих на 22-й порт.

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

**** — количество попыток авторизации ограничено, но серверу всё равно приходится обрабатывать их от большого количества злоумышленников.

Отключить авторизацию по паролю

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

PasswordAuthentication no

Подключение к серверу ssh по открытой части ключа на windows.

Запустим PuTTY и введем адрес подключения к SSH серверу.

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

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

Результат ssh аутентификации по ключу на сервере CentOS или Ubuntu.

Результат ssh аутентификации по ключу на сервере Windows.

Помогла статья? подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Применение на практике

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

Также нам будет необходимо установить и сконфигурировать SSH сервер. В качестве примера мы возьмем популярный проект — OpenSSH Server, который доступен для установки на различных операционных системах в т.ч — Windows и Linux.

Симметричное и асимметричное шифрование

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

Асимметричное шифрование противопоставляется симметричному. Этот тип появился в 70-х годах и позволил применять новые подходы, при которых процедуры шифрования и дешифровки информации производятся разными, но взаимосвязанными ключами. Именно на принципе использования разных частей ключей основана аутентификация по открытому ключу.

Сменить порт

Port 9724

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

Создание ключа

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

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

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

Уменьшить время ожидания авторизации

LoginGraceTime 30s

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

Уменьшить число попыток авторизации

MaxAuthTries 2

Количество попыток ввода пароля. По умолчанию 6. При неудачном переборе сеанс связи обрывается.

Установка fail2ban

apt update

apt install iptables -y && apt install fail2ban -y

Шаг 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):

Шаг 2 – копирование публичного ключа на сервер ubuntu

Самым быстрым способом скопировать ваш публичный ключ на машину с Ubuntu – использовать утилиту ssh-copy-id. Поскольку этот метод невероятно прост, он рекомендуется для использования в первую очередь. Если по какой либо причине использование ssh-copy-id невозможно, вы можете использовать один из двух альтернативных методов, описанных далее (копирование в входом по SSH с использованием пароля и ручное копирование ключа).

Шаг 3 – аутентификация на сервере ubuntu с использованием ключей ssh

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

Процесс входа выглядит так же:

Шаг 4 – отключение аутентификации по паролю на вашем сервере

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

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

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

sudonano /etc/ssh/sshd_config

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

...
PasswordAuthentication no
...

Сохраните и закройте файл нажав CTRL X, затем Y для подтверждения сохранения файла, а далее ENTER для выхода из текстового редактора nano. Для применения внесённых изменений нам необходимо перезапустить сервис sshd:

sudo systemctl restart ssh

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

Заключение

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