Public key что это за программа

Все, что необходимо знать о технологии HTTP Public Key Pinning (HPKP)

В ближайшие несколько лет технология привязывания ключей (key pinning) будет главной надеждой в системе безопасности протокола TLS, делая целевые атаки, связанные с Центрами Сертификации, намного более рискованными.

• Установите значение параметра max-age в несколько минут и постепенно увеличивайте до тех пор, пока не добьетесь удовлетворительных результатов.
• Используйте заголовок Public-Key-Pins-Report-Only для генерации и отправки отчетов о неудачах на адрес, содержащийся в параметре report-uri, без принудительного привязывания.
• Пробуйте различные привязки от разных Центров Сертификации.

Настройка веб-сервера

При использовании технологии HPKP не требуется специальной поддержки HTTP-сервера; нужно лишь добавить новый заголовок. Настройка для Apache:

Header set Public-Key-Pins «pin-sha256=»XXX»; pin-sha256=»YYY»; max-age=ZZZ»

【Esc】の役割とは？エスケープキーを使って簡単取り消し！

Настройка для Nginx:

add_header Public-Key-Pins ‘pin-sha256=»XXX»; pin-sha256=»YYY»; max-age=ZZZ’;

Более общую информацию о конфигурировании протоколов SSL/TLS для Apache и Nginx можно почерпнуть в других моих статьях (ссылка 1, ссылка 2).

Верификация привязанных ключей

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

Простейший способ проверки — при помощи команды chrome://net-internals/#hsts. В разделе Query domain введите адрес вашего сайта и проверьте, что сигнатуры ключей отображаются в списке под строкой dynamic_spki_hashes. Браузер Chrome будет хранить сигнатуры только в случае успешной верификации.

Отчет о неудачных проверках

В спецификации заложен механизм отправки отчетов при неудачной проверке ключа. Отчеты отправляются по адресу, указанному в директиве report-uri. Эта возможность полезна не только на этапе отладки, но и при детектировании MITM-атак против ваших пользователей. На самом деле, только само присутствие этой возможности делает технологию Public Key Pinning устойчивой к MITM-атакам.

Отчеты отправляются через HTTP POST следующего JSON-сообщения:

«date-time»: date-time,
«hostname»: hostname,
«port»: port,
«effective-expiration-date»: expiration-date,
«include-subdomains»: include-subdomains,
«noted-hostname»: noted-hostname,
«served-certificate-chain»: [
pem1, . pemN
],
«validated-certificate-chain»: [
pem1, . pemN
],
«known-pins»: [
known-pin1, . known-pinN
]
>

Поддержка браузеров

Telnet, SSH, консоль и терминал — что это и зачем нужно?

Технология HPKP поддерживается браузерами Chrome 38, Firefox 35 (и более поздних версиях).

Недостатки HPKP

Хотя у технологии HPKP есть несколько недостатков, в целом я рекомендую ее к использованию. Самая главная уязвимость заключается в том, что HPKP – это механизм вида trust-on-first-use (доверие при первом использовании). Иными словами, пользователь не сможет узнать о MITM-атаке при первом подключении к сайту.

С другой стороны, для повторной MITM-атаки злоумышленнику нужно перехватить все соединения к веб-сайту. Учитывая характер сегодняшних угроз, технология HPKP является вполне приемлемой защитой. Примечательно, что злоумышленник перед тем, как осуществить MITM-атаку, обязан знать, хранятся ли на целевой машине привязанные ключи. Иначе в браузере пользователя появится грозное предупреждение (и, возможно, отправится отчет администратору сайта) об ошибке при верификации.

Мир сходит с ума, но еще не поздно все исправить. Подпишись на канал SecLabnews и внеси свой вклад в предотвращение киберапокалипсиса!

Источник: www.securitylab.ru

Записки IT специалиста

Аpt-key is deprecated или управление ключами в современных выпусках Debian и Ubuntu

Многие базовые действия в дистрибутивах Linux не меняются множество лет и для многих стали уже привычкой. А привычки — вещь такая: привыкнуть легко, сложно переучиться. Поэтому изменения базовых вещей многими воспринимается в штыки и вызывает крайне негативные эмоции. Apt-key — утилита командной строки для управления ключами пакетного менеджера APT и когда ее объявили устаревшей, то многим это не понравилось. Однако на то были свои причины, а новая система управления ключами во многом даже проще и удобнее, нужно лишь разобраться и привыкнуть.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

Для того, чтобы система могла использовать ключ его нужно установить в системное хранилище, которое располагается в /etc/apt/trusted.gpg, для чего использовалась команда:

apt-key add repo_signing.key

Однако если вы выполните команду в последних версиях Debian, Ubuntu и других основанных на них дистрибутивах, то получите предупреждение:

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

Ключ при этом добавится и, в принципе, вы можете продолжать пользоваться старым способом не обращая внимание на предупреждения.

Но разработчики не просто так объявили apt-key устаревшим, на это есть серьезные причины. Дело в том, что APT безоговорочно доверяет любому ключу в trusted.gpg для любого репозитория, что дает возможность загрузить из стороннего репозитория пакеты, подписанные ключом другого репозитория и заменить таким образом любой пакет в системе.

Чтобы устранить потенциальную брешь в безопасности была введена новая система, когда каждый репозиторий доверяет только собственному ключу, а сами ключи помещаются в специальное хранилище, к которому имеет доступ только суперпользователь. В настоящее время это директория /usr/share/keyrings, согласно документации там следует размещать ключи, дальнейшее управление которыми предполагается с помощью APT или DPKG. Для ключей управляемых локально предназначена директория /etc/apt/keyrings. В системах до Debian 12 и Ubuntu 22.04 ее следует создать самостоятельно с разрешением 755.

Ключ должен быть в двоичной форме (без ASCII-Armor) и иметь имя:

repo-archive-keyring.gpg

Где repo — короткая часть имени репозитория.

Допускается также иметь рядом текстовую версию ключа (с ASCII-Armor) с именем:

repo-archive-keyring.asc

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

deb [signed-by=/usr/share/keyrings/repo-archive-keyring.gpg] .

На практике очень часто требование снять ASCII-Armor не соблюдается и в /usr/share/keyrings кладется текстовая версия ключа. Однако в документации Debian крайне не советуется так делать.

Далее мы рассмотрим на практике приемы работы с ключами в современных операционных системах.

Определение типа ключа

Выше мы говорили, что ключ может быть двух типов: бинарный и текстовый, т.е. с ASCII-Armor или без. Пусть вас не смущает новый непонятный термин, ASCII-Armor — это привычный всем текстовый формат ключей в кодировке Base64.

Знакомо, не правда ли? Это и есть ключ с ASCII-Armor. Такие ключи наиболее распространены, так как текстовый формат более удобен при передаче в сетях связи. Убедиться, что перед вами ключ в ASCII формате можно просто прочитав файл, например, командой cat:

cat repo_signing.key

Или при помощи команды:

file repo_signing.key

В случае текстового формата вы увидите:

PGP public key block Public-Key (old)

Если это бинарный ключ:

OpenPGP Public Key Version 4

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

Удаление старых ключей

Перед тем, как устанавливать ключ в новое хранилище нам нужно удалить его из старого хранилища /etc/apt/trusted.gpg. Для этого сначала получим список ключей командой:

apt-key list

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

Находим и копируем идентификатор нужного ключа, затем удаляем его командой:

apt-key del «KEY-ID»

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

apt-key del D58C0CED

Кстати, именно эти две команды являются на сегодняшний день допустимыми для использования с apt-key.

Получение и установка текстовых ключей OpenPGP (c ASCII-Armor)

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

wget https://example.com/key/repo_signing.key

Или curl:

curl -O https://example.com/key/repo_signing.key

Затем его следует преобразовать в бинарный формат и поместить в хранилище, эту команду следует выполнять с правами суперпользователя:

gpg —dearmor < repo_signing.key >/usr/share/keyrings/repo-archive-keyring.gpg

Можно ли упростить этот процесс, можно, для этого используем конвейер:

wget -O- https://example.com/key/repo_signing.key | gpg —dearmor > /usr/share/keyrings/repo-archive-keyring.gpg
curl https://example.com/key/repo_signing.key | gpg —dearmor > /usr/share/keyrings/repo-archive-keyring.gpg

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

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

Обе команды должны быть запущены под root, если же вы предпочитаете sudo, то следует сделать так:

wget -O- https://example.com/key/repo_signing.key | gpg —dearmor | sudo tee /usr/share/keyrings/repo-archive-keyring.gpg >/dev/null
curl https://example.com/key/repo_signing.key | gpg —dearmor | sudo tee /usr/share/keyrings/repo-archive-keyring.gpg >/dev/null

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

Получение и установка бинарных ключей OpenPGP (без ASCII-Armor)

Мы бы хотели привести пример, но не можем припомнить чтобы в каком-то репозитории применялись бинарные ключи. Но случаи бывают разные. Для этого вам понадобятся права суперпользователя или sudo:

wget -O /usr/share/keyrings/repo-archive-keyring.gpg https://example.com/key/repo_signing.key
curl -o /usr/share/keyrings/repo-archive-keyring.gpg https://example.com/key/repo_signing.key

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

Получение ключей OpenPGP с сервера ключей

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

gpg —keyserver keyserver.ubuntu.com —recv «KEY-ID»

Также вы можете использовать ID ключа целиком, если он содержит пробелы, то оберните его в двойные кавычки.

После выполнения данной операции в домашней директории пользователя будет создано локальное хранилище в скрытой директории .gnupg/trustdb.gpg.

Теперь нам нужно экспортировать оттуда ключ в хранилище, команда должна выполняться под тем же самым пользователем, который получил ключ в предыдущей команде, если это root:

gpg —export «KEY-ID» > /usr/share/keyrings/repo-archive-keyring.gpg

А если нужно получить текстовый ключ:

gpg —export —armor «KEY-ID» > /usr/share/keyrings/repo-archive-keyring.asc

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

gpg —export «KEY-ID» | sudo tee /usr/share/keyrings/repo-archive-keyring.gpg >/dev/null

Можно ли сразу получить и экспортировать ключ? Можно. Если вы внимательно разобрали команды выше, то следующая не покажется вам китайским заклинанием:

gpg —no-default-keyring —keyring /usr/share/keyrings/repo-archive-keyring.gpg —keyserver keyserver.ubuntu.com —recv «KEY-ID»

Данную команду следует выполнять от имени суперпользователя, ключ —no-default-keyring предписывает не использовать локальное хранилище в домашней директории пользователя, оттуда не будет ничего считываться и не будет ничего записано.

Удаление ключей из хранилища

Для удаления ключа достаточно удалить соответствующий ему файл, для этого вам потребуются права root:

rm -f /usr/share/keyrings/repo-archive-keyring.gpg

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник: interface31.ru

Linux. Авторизация по SSH ключу. Приватный и публичный SSH ключ.

SSH или Secure Shell — это зашифрованный протокол, который часто используется для взаимодействия и удаленного управления серверами. Если вы захотите что-либо сделать на удаленном сервере, скорее всего, вам придется воспользоваться SSH и работать через терминал.

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

Как работает протокол SSH

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

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

Публичный ключ используется для шифрования сообщений (он не является секретным), которые можно расшифровать только приватным ключом. Это свойство и используется для аутентификации с помощью пары ключей. Публичный ключ загружается на удаленный сервер, к которому необходимо получить доступ. Его нужно добавить в специальный файл ~/.ssh/authorized_keys.

Проверка подлинности ключей

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

Как создать ключи SSH?

Для генерации пары ключей используется программа ssh-keygen, она включена в пакет ssh и если SSH у вас уже настроен, то дополнительно устанавливать ничего не нужно.

По умолчанию ключи располагаются в папке ~/.ssh/. И лучше расположение этой папки не менять, чтобы все работало по умолчанию и ключи автоматически подхватывались. Приватный ключ будет называться id_rsa, а публичный id_rsa.pub.

Сгенерим ключ через команду:

$ ssh-keygen -t rsa

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

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

В результате будет создано два файла: ~/.ssh/id_rsa и ~/.ssh/id_rsa.pub

Первый файл id_rsa (это приватный ключ) всегда нужно хранить в секрете. Второй файл id_rsa.pub (это публичный ключ) нужно добавить на удалённый компьютер, где запущен сервер SSH.

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

На удалённой машине нам нужно создать каталог .ssh. Далее нам нужно скопировать содержимое файла публичного ключа id_rsa.pub на удалённую машину в файл ~/.ssh/authorized_keys.

Обратите внимание, права на файл не должны давать возможность писать в этот файл посторонним пользователям, иначе SSH его не примет.

В публичном ключе последнее есть поле — [email protected] Оно не имеет никакого отношения к авторизации и служит только для удобства определения где чей ключ. Заметим, это поле может быть поменяно (или даже удалено) без нарушения структуры ключа.

Теперь можно выполнять подключение с помощью клиента SSH на удаленный сервер. Для это выполним команду:

Первый раз, когда вы заходите на сервер,SSH вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да — ключ сохраняется в файл ~/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо считается что это небезопасно).

Если ключ сервера поменялся (например, сервер переустановили), SSH вопит от подделке ключа. Обратите внимание, если сервер не трогали, а SSH вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов).

• Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Их можно:
  скопировать со старого сервера на новый.
• сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.

Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.

Как получить публичный SSH-ключ из приватного

Чтобы из файла с закрытым SSH-ключем сгенерировать и вывести на экран открытый ключ, воспользуйтесь следующей командой:

В качестве примера сгенерируем открытый SSH-ключ из закрытого ключа ~/.ssh/id_rsa и сохраним его в файл ~/.ssh/id_rsa.pub:

$ ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub

Как отключить проверку (требование) пароля при авторизации по SSH

Если пароль больше не будет использоваться, то для увеличения безопасности системы лучше его вовсе отключить. Но убедитесь, что ключ надежно сохранен и вы его не потеряете, потому что по паролю вы больше не войдете. Авторизуйтесь на сервере, затем откройте конфигурационный файл /etc/ssh/sshd_config и найдите там директиву PasswordAuthenticatin. Нужно установить ее значение в No:

$ sudo vi /etc/ssh/sshd_config

Теперь сохраните файл и перезапустите службу ssh:

$ sudo service ssh restart

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

Еще по теме

Источник: blog-programmista.ru

Доступ по ключам к SSH серверу Windows 10

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

Евгений Боздаганян

Read more posts by this author.

Евгений Боздаганян

9 авг. 2020 • 8 min read

SSH • Windows • Конфигурирование • OpenSSH • Компьютерные истории • Истории

Введение

Начиная с верcии 1803 , в Windows 10 доступны SSH клиент и SSH сервер, причём, SSH клиент установлен и готов к использованию, как говорится, прямо из коробки, а SSH сервер надо устанавливать, но делается это буквально в пару-тройку кликов мышкой [1] . Что это означает? С точки зрения клиента можно говорить о том, что сторонние программы, такие как PuTTY , вроде как больше не нужны. С точки зрения сервера — не надо устанавливать никакие сторонние серверы, если есть решение интегрированное.

В работе что клиент, что сервер, практически не отличаются от того ПО, к которому я привык в Debian . Но, как ни крути, есть некоторые отличия, и вот об одном из них попробую сейчас рассказать. Речь пойдет о подключении к SSH серверу, работающему на Windows , с клиента, в моем случае, работающего на Debian Jessie , причем, без использования пароля, то есть, задействуя ключи.

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

Про генерацию ключей

Итак, если ключей нет и вы работаете на системе под управлением Linux , то вот эта команда поможет вам их сгенерировать:

ssh-keygen -t rsa

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

• Если вы работаете под Windows 10 и включили возможность использовать встроенный SSH клиент, то смело используйте команду ssh-keygen — должно сработать.
• Если вы работаете под Windows 10 и включили возможность использовать WSL, то можете воспользоваться возможностями этой подсистемы, то есть, использовать в ней. всё ту же команду ssh-keygen .
• Если вы работаете под Windows 10 и у вас не установлен встроенный SSH клиент и не включена возможность использования WSL , или же у вас более ранняя версия Windows , то придется использовать стороннее ПО, тот же PuTTY с его генератором PuTTYgen — для этого случая есть достаточно подробная документация.

Если пара ключей успешно сгенерирована, или уже была у вас, то необходимо «доставить» публичный ключ на сервер и там сделать его доступным для использования SSH сервером. И вот тут то и начинаются отличия от обычного — для мира Linux — процесса.

Доставка публичного ключа на сервер Linux

Что я делал, когда мне надо было «доставить» ключ на SSH сервер, работающий на Linux ? Всё очень просто — запуск следующей команды на клиентской машине решал все вопросы:

где user_name — имя пользователя, ключ которого передаётся на сервер, а server_name_or_ip — имя или адрес хоста с сервером SSH , к которому есть желание подключаться без ввода пароля (от имени пользователя с ключом). Иногда команда не работала и приходилось явно указывать файл (при помощи параметра командной строки -i ), в котором хранился публичный ключ, но это, в большей степени, зависело от устройства, на котором выполнялась эта команда, вернее, от версии ОС, ну и от реализации и версии криптографического ПО, конечно.

Доставка публичного ключа на сервер Windows

Но, в случае, когда в качестве сервера выступает машина с Windows , этот приём не прокатывает — ключ не передаётся на нужный хост и всё. Не знаю, эксперименты эти я проводил довольно давно, может, в новых версиях Windows эту «особенность» исправили, а может и нет. В любом случае, тогда мне пришлось искать обходной путь.

Собственно, сам этот путь очевиден — раз не получается сделать передачу ключа автоматом, надо всё выполнить вручную. А для этого необходимо знать, где и как Windows хранит публичные ключи, используемые SSH сервером для аутентификации клиентов. К счастью, в документации Microsoft есть необходимая информация и её надо просто использовать. Давайте её детально разберём, при том держа в уме, что документация предполагает работу с клиентской машины под управлением Windows с заранее настроенным доступом по SSH к необходимому серверу.

Создание каталога для хранения ключей

Итак, из документации становится очевидно, что Windows хранит пользовательские ключи, используя тот же принцип, что и Linux : на сервере в файле authorized_keys в подкаталоге .ssh домашнего каталога пользователя (а это, как правило, c:Usersuser_name , где user_name — имя пользователя), от имени которого вы хотите работать в установившемся SSH сеансе. Если этого каталога нет, его надо создать, для чего предлагается использовать команду:

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

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

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

где public_key_file_name.pub — имя файла публичного ключа, например, id_ed25519.pub или id_rsa.pub (далее в примерах я буду использовать для простоты id_rsa.pub ).

На этом моменте хотелось бы остановиться подробнее. Обычно вы работаете на своём компьютере (или виртуалке) под своим собственным пользователем. Когда вы подключаетесь к удалённой машине по SSH , вы можете подключаться под именем своего текущего пользователя локальной машины, или использовать имя какого-либо пользователя удалённого компьютера, или же — доменное имя. Конечно, в любом случае на удалённом хосте должен существовать соответствующий пользователь (или разрешено использовать доменное имя), даже если его имя будет совпадать с именем пользователя, под которым вы работаете на своём локальном хосте. Так вот, совсем не обязательно, что вы единственный подключаетесь к удалённому хосту под определенным пользователем, вполне возможно, что с других хостов другие люди (или вы сами?) также подключаются по SSH , используя ту же самую учётную запись.

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

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

Естественно, возникает вопрос, как это можно сделать. И на этот вопрос существует множество ответов. Например, если у вас есть доступ к удалённому хосту по RDP , то можно отредактировать на нём файл authorized_keys с помощью того же notepad -а, добавив содержимое своего файла с публичным ключом. Или же, можно скопировать свой файл с публичным ключом на нужный сервер и объединить его с существующим файлом, а затем — удалить (конечно, при этом у вас, вернее, у вашего пользователя на удалённом компьютере, должны быть права на редактирование файла authorized_keys ):

Обратите внимание на использование символов ‘/’ в команде scp и » в командах ssh — так как мы работаем на Debian , то в команду scp можно передать путь на хосте с Windows с использованием нестандартного для Windows разделителя ‘/’, а вот в команды, выполняемые при помощи ssh на том же удалённом компьютере, следует передавать символы »,то есть, стандартный для Windows разделитель » с предшествующим символом », так называемый «escaped backslash», иначе Windows не найдёт нужные файлы.

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

Вот мы и подошли к последнему шагу — предоставлению прав доступа к файлу authorized_keys . Именно этим занимается команда:

Основную смысловую нагрузку в этой составной команде несёт функция Repair-AuthorizedKeyPermission из модуля OpenSSHUtils для PowerShell (да, именно PowerShell используется в качестве командной оболочки в этот раз). Этот модуль надо устанавливать отдельно, например, так (выполнять эту команду надо, естественно, из PowerShell ):

Install-Module -Force OpenSSHUtils -Scope AllUsers

Так вот, когда я запустил эту команду, ответом мне стало сообщение об ошибке:

Совпадения для указанных условий поиска и имени пакета «OpenSSHUtils» не найдены.

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

Суть в том, что Windows 10 предъявляет определённые требования к безопасности файла authorized_keys (на самом деле, к безопасности публичных ключей). Причины, по которым это происходит, наверное, не надо объяснять. Так вот, в документации Microsoft указывается, что при использовании Windows 10 доступ может быть предоставлен только администаторам и специальному пользователю SYSTEM . Там же советуется использовать модуль OpenSSHUtils , который должен оказать помощь при установке нужных прав. Собственно, при использовании предложенного в документации подхода я и наткнулся на ошибку. Но кроме документации от Microsoft я нашёл довольно много информации о проблемах, вызванных использованием этого модуля. Если попробовать кратко изложить содержимое ответов на возникающие у пользователей вопросы и проблемы, то получится что-то типа:

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

Вот честно, не знаю, так это, или нет, но проверять расхотелось, тем более, что совсем не трудно задать нужные права самостоятельно. После некоторого изучения вопроса — я не большой специалист в PowerShell — получился вот такой вот набор команд [2] (я приведу их полностью, потом разберу для чего нужна каждая из них):

$acl = Get-Acl C:Usersuser_name.sshauthorized_keys $acl.SetAccessRuleProtection($true, $false) $adminsRule = New-Object system.security.accesscontrol.filesystemaccessrule(«Администраторы»,»FullControl»,»Allow») $sysRule = New-Object system.security.accesscontrol.filesystemaccessrule(«SYSTEM»,»FullControl»,»Allow») $acl.SetAccessRule($adminsRule) $acl.SetAccessRule($sysRule) Set-Acl -Path C:Usersuser_name.sshauthorized_keys -AclObject $acl

Теперь, как и обещал, небольшие пояснения по командам. Итак, для начала, при помощи cmdlet -а Get-Acl получаем дескриптор безопасности, содержащий ACL (Access Control List) нужного нам объекта файловой системы (параметр командной строки Path можно опустить) и сохраняем результат в переменной $acl . Далее, используя метод SetAccessRuleProtection полученного объекта, запрещаем наследование прав ( true в первом параметре) и отказываемся от сохранения унаследованных ранее прав ( false во втором параметре). Затем создаём два объекта, описывающих правила доступа к объектам файловой системы: один (сохраняется в переменной $adminsRule ) — для Администраторов, второй (сохраняется в переменной $sysRule ) — для специального пользователя SYSTEM . Теперь, при помощи метода SetAccessRule, добавляем только что соданные ACL к дескриптору безопасности нашего файла, хранящегося в переменной $acl . После чего, всё, что нам остаётся сделать — применить полученный дескриптор, для чего используем cmdlet Set-Acl.

Ну вот, теперь, когда мы выполнили все шаги, всё должно заработать. Но, в моём случае, не заработало. Очередная неудача заставила меня вновь полезть в документацию, что обогатило меня новыми знаниями. Рассказываю.

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

Причиной того, что при соединении с SSH сервером мне, несмотря на все предыдущие мытарства, продолжало выводиться требование ввести пароль, было то, что я пытался подключиться под пользователем, который входил в группу локальных Администраторов. У Windows 10 в этом случае есть требование — публичные ключи должны храниться в файле %programdata%/ssh/administrators_authorized_keys , то есть, обычно, в C:ProgramDatasshadministrators_authorized_keys .

Что ж, для того, чтобы решить проблему, можно воспользоваться двумя путями. Первый путь — воспользоваться процедурой добавления публичного ключа, рассмотренной нами выше. Да-да, все эти шаги: копирование, добавление, предоставление прав, только применяем их не к authorized_keys , а к administrators_authorized_keys . Я напишу, на всякий случай, полную последовательность команд, чтобы удобно было воспользоваться, но не забудьте подставить свои значения для пользователя, домена и хоста.

Второй путь чуть более радикальный — изменить настройки SSH сервиса. Настройки эти хранятся в файле %programdata%/ssh/sshd_config . Как оказалось, именно там определяется, где должны храниться публичные ключи тех пользователей, которые подключаются к SSH серверу от имени пользователей, входящих в группу администраторов. Вот, собственно, эти строки:

. Match Group administrators AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys .

Так вот, эти строки надо закомментировать или удалить, после чего SSH сервер надо перезапустить.

Какой путь использовать — решать вам. Я же, пожалуй, закончу — пост получился и так слишком длинным.

1. На самом деле, в виде beta версий эти компоненты были доступны и раньше, но и установка и стабильность работы, были, что называется, не на высоте. ↩︎
2. Честно признаюсь, очень многое я подсмотрел в документации, например, как отключить наследование прав, или предоставить Администраторам полный контроль над файлом, и лишь немного адаптировал эти примеры к собственным нуждам. ↩︎

Subscribe to Записки на полях

Get the latest posts delivered right to your inbox

Источник: blog.bozdaganian.com

PKI — инфраструктура открытых ключей

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

Public Key Infrastructure

Public Key Infrastructure, PKI — набор технических средств для координации приложений и прочих частей IT-системы ключами и сертификатами пользователей. Public Key Infastructure также называется «инфраструктурой открытых ключей» (ИОК).

Инфраструктура открытых ключей является методом проверки распознания удаленного сайта с помощью цифрового сертификата (ЦС), являющегося конструкцией данных. Применяется для соединения идентифицированного блока с предопределенным открытым ключом, который используется для верификации достоверности приложений, сервисов, пользователей. С его помощью происходит контроль доступа, то есть авторизации. Ключи выдаются и сортируются компанией, занимающейся предоставлением SSL-сертификатов. Благодаря чему PKI позволяет оперативно и с минимальными потерями реагировать на утрату доступа пользователя.

Электронная цифровая подпись

Удостоверяющий центр (УЦ) или центр сертификации — сегмент системы публичных ключей, который создает сертификат для доказательства права доступа пользователя и структур, запрашивающих вход. Полученный сертификат подписывается частным ключом. УЦ – базисная часть PKI. Документ идентичен паспорту человека. Он служит для удостоверения личности, но в электронном мире. Выдается людям, компьютерам, программным пакетам и т. д.

PKI — это система, созданная на применении структуры асимметричной шифровки и электронной цифровой подписи (ЭЦП). ЭЦП – цифровой аналог физической подписи пользователя. Существует два ее вида:

Первая это коды и пароли, с помощью которых происходит идентификация пользователя. Простую ЭЦП нельзя использовать для подписания электронных документов.

Усиленная (квалифицированная) подпись является безупречным видом электронной подписи. Она создается сертифицированными криптографическими средствами. Ее можно сравнить с личной подписью либо печатью учреждения. Электронный документ, заверенный квалифицированной ЭЦП, приобретает правовую силу.

Открытый и закрытый ключи

Для кодирования информационного потока и верификации цифровой подписи применяется открытый ключ (public key, публичный ключ), который передается по открытому каналу. Тайным ключом дешифруется информационный поток и вычисляется электронная подпись. Секретный ключ знает лишь его обладатель. Хранится он в защищенной памяти smart-карты или токена.

Согласно запросу пользователя в УЦ из отрытых и закрытых ключей создается ключевая пара. Ключи — компоненты, которые одновременно образовываются и применяются. Данные, закодированные публичным ключом, могут быть дешифрованы лишь сочетающимся закрытым ключом, также в обратном порядке.

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

Компоненты эффективности ИОК

Public Key Infrastructure — базис безопасности в сети. PKI дает возможность применять сервисы кодирования и создания ЭЦП для различных приложений, функционирующих в среде публичных ключей.

Основные составляющие:

• центр сертификации;
• центр регистрации;
• хранилище сертификатов;
• веб-архив сертификатов;
• физические пользователи.

В составе работают подсистемы:

• создания и ликвидации сертификатов,
• сохранения резервных копий и воссоздания ключей;
• шифрования данных;
• администрирования работы ключей и сертификатов.

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

Обеспечение ИОК

PKI — это структура электронных сертификатов с носителями в виде USB-ключей. Применение уникального тайного пароля и методов криптографии превращает цифровые сертификаты в полноценные электронные паспорта.

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

PKI обеспечивает безопасность:

• эл. почты (шифровка и цифровая подпись);
• общекорпоративных веб-ресурсов и порталов;
• внутренней и наружной передачи данных;
• wireless-сетей;
• сведений на персональных компьютерах.

Также ИОК гарантирует проверку подлинности пользователей общекорпоративной информационной системы, в том числе и на дистанционном доступе. Она контролирует целостность распознаваемых сведений.

РАБОТА С CLOUD NETWORKS

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

Компания Cloud Networks предоставляет полный набор функций по управлению сертификатами открытых ключей:

Источник: cloudnetworks.ru