Аутентификация на SSH-сервере FreeBSD с использованием ключей. | Администрирование и применение FreeBSD

Аутентификация на SSH-сервере FreeBSD с использованием ключей.

OpenSSH, кроме обычного входа по паролю, поддерживает еще несколько методов аутентификации. Он может быть сконфигурирован на использование методов PAM (Pluggable authentication modules), протокола Challenge/Response, Kerberos, аутентификации по доверенным хостам и по ключам X509. Самым популярным является метод Identity/Pubkey.
Целью использования идентификации Identity/Pubkey является исключение использования статических паролей. Вместо того, чтобы каждый раз набирать пароли, которые могут быть скомпроментированы (подсмотрены, перехвачены кейлоггером и т.п.), в данном методе используется пара ключей (открытый и закрытый), которые хранятся по отдельности, и используются для проверки подлинности.

Плюс этого типа аутентификации очевиден:
Никто не сможет войти на сервер с учетной записью пользователя, даже зная пароль, так как нужно обладать приватным ключом и знать кодовую фразу.
Кроме того, Вы можете использовать утилиту ssh-agent (или pageant для Windows) для временного безопасного хранения аутентификационных данных в памяти клиентской рабочей станции.

Для начала привожу общий порядок действий:

  • С помощью программы ssh-keygen (или puttygen для Windows-клиента) генерурием пару ключей: публичный (открытый) ключ (public key) и приватный (закрытый) ключ (private key)
  • Приватный ключ помещаем на клиентскую рабочую станцию и больше никому не показываем
  • Публичный ключ копируется на удаленный ssh сервер и помещается в специальный файл, известный серверу (~/.ssh/authorized_keys)
  • Настраиваем файл конфигурации сервера ssh
  • Настраиваем клиентскую рабочую станцию для работы с ssh по ключам

Некоторая начальная информация:
Системные файлы настройки OpenSSH расположены в каталоге /etc/ssh.
Файл /etc/ssh/ssh_config используется для настройки клиента, а sshd_config для сервера.
Кроме того, можно настроить дополнительные параметры ssh-демона, используя ключ sshd_flags в файле /etc/rc.conf.

Теперь все этапы настройки рассмотрим подробно.
1) Создать ключи DSA или RSA, которые будут использоваться для аутентификации.
Для примера, пусть имя пользователя будет operator, а имя сервера — server1.sample.com
Для создания и управления ключами, предназначена программа ssh-keygen, входящая в пакет программного обеспечения OpenSSH.

Основные опции этой утилиты:
-t type
RSA1 — для протокола SSH версии 1.
RSA — для протокола SSH версии 2 (самый надежный вариант)
DSA — для протокола SSH версии 2.

-b N
N: Длина ключа в битах (по умолчанию: 2048 бит)

-i
Данная опция используется для импорта ключей из другого формата ( например ключи сгенерированные программой PuTTYgen, для Windows ), в формат OpenSSH.
-l
Посмотреть отпечаток секретного ключа ( fingerprint ).
-p
Изменить секретную фразу приватного ключа.
-f filename
Задаем общую часть имени сгенерированных ключей (по умолчанию: id_rsa)

Полный список опций можно посмотреть командой man ssh-keygen.

Запускаем:

# ssh-keygen -t rsa

Generating public/private dsa key pair.
Enter file in which to save the key (/home/operator/.ssh/id_rsa):
Created directory ‘/home/operator/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/operator/.ssh/id_rsa.
Your public key has been saved in /home/operator/.ssh/id_rsa.pub.
The key fingerprint is:
44:4b:1a:5d:64:fb:0b:71:ab:58:2b:69:49:3b:3b:e2 operator@server1.sample.com

Утилита создаст пару ключей, используемых для аутентификации. Приватный ключ сохраняется в ~/.ssh/id_rsa, а публичный в ~/.ssh/id_rsa.pub (для ключей RSA).
Приватный ключ копируем на рабочую станцию, с которой будем входить на server1.sample.com по ssh-протоколу и удаляем его на сервере.
Публичный (открытый) ключ надо скопировать в файл authorized_keys, затем удалить.

cat id_rsa.pub > authorized_keys # копируем ключ в ключи для авторизации
rm id_rsa.pub # удаляем ненужный public

2) Настройка SSH сервера на аутентификацию по ключам.
Фрагмент файла /etc/ssh/sshd_config с настройками для аутентификации по ключу.

Protocol 2 # включаем 2-ую версию протокола для улучшенной безопасности
PermitRootLogin no # запрет на логин root-ом
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreRhosts yes
PasswordAuthentication no
PermitEmptyPasswords no
UseLogin no
UsePAM no # отключаем авторизацию по паролю (очень важно!)

Затем перестартуем демона sshd:

# /etc/rc.d/sshd restart

Если Вы настраиваете сервер удаленно, то, чтобы не потерять контроль над этим сервером, рекомендую не закрывать текущий ssh-сеанс. Об этом расскажу чуть позже.
3) Настройка SSH клиента.
Редактируем файл /etc/ssh/ssh_config:

RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication yes
HostbasedAuthentication no
IdentityFile ~/.ssh/id_rsa

Далее поступаем в зависимости от ОС клиентской рабочей станции.
1 вариант: для рабочей станции FreeBSD (Linux, Unix).
Копируем закрытый (приватный) ключ в каталог /usr/home/operator/.ssh (например, с помощью программы scp)
Пробуем «залогиниться» в другом окне терминала. Если Вы хотите наблюдать за фазами соединения, то используйте ключ –v.

В случае неудачи можно, на время вернуть «смешанную» аутентификацию, изменив значение параметра «UsePAM» на «yes». После этого надо перестартовать демона sshd (см.выше), и можно войти на сервер по-старому, используя пароль пользователя. В данном варианте ssh-сервер не увидит правильного ключа на стороне клиента и перейдет к аутентификации по паролю пользователя.

Рассмотрим процесс подключения по этапам:

  • Клиентская программа /usr/bin/ssh соединяется с сервером на порт SSH, отправляет серверу свой ключ, и запрашивает аутентификацию по данному ключу.
  • Сервер определяет алгоритм шифрования, проверяет файл authorized_keys на наличие и соответствие открытого ключа и, в случае успеха, посылает клиенту последовательность, зашифрованную на открытом ключе .
  • Если приватный ключ защищен кодовым словом (что делать очень настоятельно рекомендуется), то /usr/bin/ssh просит его ввести для дешифровки закрытого ключа.
  • Клиент расшифровывает посланную последовательность для подтверждения правильности публичного и приватного ключей.
    Если сообщение расшифровано, правильность публичного и приватного ключей, считается подтвержденной, и пользователю предоставляется доступ в систему без запроса пароля Unix

  • При отсутствии корректных ключей пользователю будет предложено авторизоваться с помощью авторизации Unix только в том случае, если значение директивы UsePAM равно yes в файле /etc/ssh/sshs_config

2 вариант: для рабочей станции Windows (предпочтительный)
Генерируем ключи программой puttygen из состава putty прямо на клиентской рабочей станции.
Приватный ключ *.ppk сохраняем в определенный каталог (кнопка «Save private key»)
Открытый ключ копируем через буфер обмена в файл *.pub.
В файле должна быть одна строка вида:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAl09QybJC8ahccGKBNjNOW7VNQgGrn07
xRN+hCJH125jVuowmHBgb3omdQX5lKyCofzDH1j8yWdag4GnTm2oSVAVx
09YavH32mVQBKPqdrutQMSLybyp2eKv8crbn+EmOTsLngeVE4t0nm17Ah
MeAiM2mkoknjJcCN1KXtXvmPos= rsa-key-20111006

Важно! Не надо создавать этот файл по нажатию кнопки «Save public key» (структура не для Unix OpenSSH).
Публичный ключ помещаем на сервер в файл ~/.ssh/authorized_keys командой:

# cat *.pub >> /usr/home/operator/authorized_keys

В конфигурации хоста программы putty (Connection->Data->Auto-login Username) указываем имя пользователя (operator).
В настройках ключа (SSH->Auth->Private key file for authentication) указываем путь к закрытому ключу.
Сохраняем сессию в настройках putty и пробуем зайти на ssh-сервер.

3 вариант: для рабочей станции Windows (не все форматы поддерживает)
Копируем файл приватного ключа id_dsa на рабочую станцию Windows, запускаем puttygen, загружаем этот ключ и сохраняем в формате putty (с расщирением ppk).
В остальном – по 2-му варианту.

На этом – все.
Каталог интернет-ресурсов Ленинградской области

Ваш отзыв


private jet hire cost uk 35d8986b

Вы должны войти, чтобы оставлять комментарии.