- Реализуем IOS версию приложения
- Создание собственного самоподписанного доверенного сертификата.
- Реализуем Android версию приложения
- 2 Создание клиентского закрытого ключа и запроса на сертификат (CSR).
- Настройка веб сервера Apache
- Fingerprinf – проверка отпечатка
- Php обработчик формы авторизации пользователя
- Public key – публичный ключ
- Scp – безопасное копирование
- Ssh авторизация по сертификатам – отключаем вход по паролю
- Безопасный метод авторизации на php
- Вход по ssh ключу для локальных администраторов windows
- Генерация сертификата
- Импортируем закрытый ключ в putty
- Использование putty для windows
- Использование туннеля через другой шелл
- Ключевая пара
- Конвертация ключей
- Конфигурация клиента. формирование ключевой пары на linux (ssh-keygen)
- Конфигурация сервера. разрешение аутентификации по ключу и добавление ключей на linux.
- Конфигурация сервера. разрешение аутентификации по ключу и добавление ключей на windows.
- Конфигурация сервера. установка openssh на linux
- Конфигурация сервера. установка openssh на windows
- Настраиваем авторизацию в iis по сертификатам используя onetoone
- Настройка подключения putty с использованием ssh сертификата
- Общая схема аутентификации по сертификатам
- Отключить авторизацию ssh по паролю
- Отладка
- Отладка multi-hop ssh tunnel
- Подготовка папок
- Подключение двух клиентов, сидящих за nat
- Подключение к рабочему столу, расположенному за nat
- Подключение к серверу ssh по открытой части ключа на linux.
- Подключение к серверу ssh по открытой части ключа на windows.
- Получение private key из хранилища средствами c#
- Предварительная настройка сервера
- Применение на практике
- Пример автоматического подключения из windows через putty и puttygen
- Примечание
- Проверка sftp через filezilla
- Прямой форвардинг на шлюз
- Работа с сертификатами в php
- Симметричное и асимметричное шифрование
- Смотреть видеоурок
- Создание ssh-ключей
- Создание ssh-ключей в linux на примере centos
- Создание ssh-ключей на windows с puttygen
- Создание защищенного ssh туннеля
- Устанавливаем ключи с помощью ssh-copy-id
- Установка сертификата
- Форвардинг портов netbios и удаленного рабочего стола
- Форма регистрации
- Логон смарт-картой или pkinit
- Заключение.
Реализуем IOS версию приложения
Необходимо подключить к Вашему проекту Security.Framework
Для осуществления запроса нам необходимо извлечеть из PKCS#12 цифровой сертификат и ассоциированный с ним приватный ключ (SecIdentityRef). Наличие данного объекта позволит нам получить соответствующий NSURLCredential.
Итак реализуем функецию extractIdentityAndTrust.
OSStatus extractIdentityAndTrust(CFDataRef inP12data, SecIdentityRef *identity)
{
OSStatus securityError = errSecSuccess;
CFStringRef password = CFSTR("");
const void *keys[] = { kSecImportExportPassphrase };
const void *values[] = { password };
CFDictionaryRef options = CFDictionaryCreate(NULL, keys, values, 1, NULL, NULL);
CFArrayRef items = CFArrayCreate(NULL, 0, 0, NULL);
securityError = SecPKCS12Import(inP12data, options, &items);
if (securityError == 0) {
CFDictionaryRef myIdentityAndTrust = CFArrayGetValueAtIndex(items, 0);
const void *tempIdentity = NULL;
tempIdentity = CFDictionaryGetValue(myIdentityAndTrust, kSecImportItemIdentity);
*identity = (SecIdentityRef)tempIdentity;
}
if (options) {
CFRelease(options);
}
return securityError;
}
Производим извлечение при помощи функции SecPKCS12Import, незабываем указать пароль к серитификату.
Далее реализуем делегат canAuthenticateAgainstProtectionSpace, вызов данного делегата позволяет нам определить свойства сервера, а именно протокол, механизм авторизации. У нас реализация этого делегата будет простой, укажем, что обрабатываем любой способ аутентификации представленный сервером.
- (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace
{
return YES;
}
Обработаем возможные ошибки:
Создание собственного самоподписанного доверенного сертификата.
Собственный доверенный сертификат (Certificate Authority – далее CA) необходим для подписи клиентских сертификатов и для их проверки при вторизации клиента веб-сервером.
openssl req -new -newkey rsa:1024 -nodes -keyout ca.key -x509 -days 5000 -subj /C=RU/ST=Msk/L=Msk/O=My Inc/OU=Sale/CN=bla/emailAddress=usr@dom.ru -out ca.crt
Описание аргументов:
–req
Запрос на создание нового сертификата.
-new
Создание запроса на сертификат (Certificate Signing Request –
далее CSR).
-newkey rsa:1024
Автоматически будет создан новый закрытый RSA ключ длиной 1024
бита. Длину ключа можете настроить по своему усмотрению.
-nodes
Не шифровать закрытый ключ (См. примечание выше).
-keyout ca.key
Закрытый ключ сохранить в файл ca.key.
-x509
Вместо создания CSR (см. опцию -new) создать самоподписанный
сертификат.
-days 5000
Срок действия сертификата 5000 дней. Размер периода действия
можете настроить по своему усмотрению. Не рекомендуется вводить
маленькие значения, так как этим сертификатом вы будете
подписывать клиентские сертификаты.
-subj /C=RU/ST=Msk/L=Msk/O=My
Inc/OU=Sale/CN=bla/emailAddress=usr@dom.ru
Данные сертификата, пары параметр=значение, перечисляются через
‘/’. Символы в значении параметра могут быть “подсечены” с
помощью обратного слэша “”, например “O=My Inc”. Также можно
взять значение аргумента в кавычки, например, -subj
“/xx/xx/xx”.
Описание параметров:
С – Двухсимвольный код страны (Country). Необязательный
параметр.
ST – Название региона/области/края/республики/… (State
Name). Необязательный параметр.
L – Название города/поселка/… (Locality Name).
Необязательный параметр.
O – Название организации (Organization Name).
Необязательный параметр.
OU – Название отдела (Organization Unit). Необязательный
параметр.
CN – Имя сертификата, при создании серверных сертификатов
используется доменное имя сайта, для клиентских
сертификатов может быть использовано что угодно (Common
Name). Обязательный параметр. Максимальная длина 64
символа.
emailAddress – почтовый адрес (E-mail address).
Необязательный параметр. Максимальная длина 40 символов.
Необязательные параметры могут быть пропущены, например,
/C=RU/CN=blabla/emailAddress=user@domain.ru.
-out ca.crt
Сертификат сохранить в файл ca.crt.
В результате выполнения команды появятся два файлаca.key и ca.crt.
Просмотреть данные закрытого ключа и сертификата вы можете с помощью
команд:
# openssl rsa -noout -text -in ca.key (для ключа)
# openssl x509 -noout -text -in ca.crt (для сертификата)
Реализуем Android версию приложения
Начну сразу с кода:
2 Создание клиентского закрытого ключа и запроса на сертификат (CSR).
Для создания подписанного клиентского сертификата предварительнонеобходимо создать запрос на сертификат, для его последующей подписи.Аргументы команды полностью аналогичны аргументам использовавшимся присоздании самоподписанного доверенного сертификата (см. $1), ноотсутсвует параметр -x509.
Настройка веб сервера Apache
получаем с помощью команды:
Fingerprinf – проверка отпечатка
При первом подключении,
ssh
проверит, если хост с данным отпечатком неизвестен, будет запрошено подтверждение
yes/no
, если ответ будет
yes
, хост будет добавлен в файл
~/.ssh/known_hosts
и при следующих подключениях будет сразу запрошен пароль для подключения, если ответ будет
no
, соединение будет разорвано.
# ssh test_host The authenticity of host 'test_host (192.168.16.54)' can't be established. DSA key fingerprint is 14:4a:aa:d9:73:25:46:6d:0a:48:35:c7:f4:16:d4:ee. Are you sure you want to continue connecting (yes/no)? yes
Получить отпечаток можно командой
ssh-keygen -l
на сервере:
# ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub # Для RSA ключа 2048 61:33:be:9b:ae:6c:36:31:fd:83:98:b7:99:2d:9f:cd /etc/ssh/ssh_host_rsa_key.pub # ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub # Для DSA ключа (по-умолчанию) 2048 14:4a:aa:d9:73:25:46:6d:0a:48:35:c7:f4:16:d4:ee /etc/ssh/ssh_host_dsa_key.pub
Php обработчик формы авторизации пользователя
Все переменные, которые возвращаются по методу POST – мы присваиваем переменной $data.
Public key – публичный ключ
При
, очень удобно использовать авторизацию по паре ключей, что-бы не вводить пароль при каждом соединении с удаленной машиной.
Для соединения с удаленным хостом без ввода пароля, можно использовать так называемый
Public keyпубличный ключ
). Нужно добавить запись о публичном ключе в файл
~/.ssh/authorized_keys
на удаленном SSH сервере. В данном случае для подключения используются ключи сгенерированные на стороне клиента. В
cygwin
создать директорию
/home.csh
в ней, можно с помощью
Scp – безопасное копирование
Пара простых команд:
# scp file.txt remote_host:/tmp # scp joe@remote_host:/www/*.html /www/tmp # scp -r joe@remote_host:/www /www/tmp
Еще пара примеров использования SCP
# scp -P 2525 ./file_to_copy root@remote_host:/tmp/copied_file
В данном случае, у нас
SSH, сидит на нестандартном порту, поэтому с помощью опции
-P
, указываем на какой порт подключаемся. Не путайте с ключем
-p
у программы
ssh
, для указания порта, для
scp
, опция
-p
, означает “Сохранить время модификации, время последнего доступа, и режимы, оригинального файла”. В случае, если у пользователя, под которым вы пытаетесь подключится для копирования, установлен пароль ( что собственно и должно быть ),
SCP
попросит его ввести, выглядит это примерно так.
Ssh авторизация по сертификатам – отключаем вход по паролю
Если вы 10 раз всё проверили и убедились что вас пускает по сертификату, остаётся отключить возможность авторизации на сервере с помощью пароля. Открываем на редактирование конфиг sshd
sudo nano /etc/ssh/sshd_config
Раскомментируем строку PasswordAuthentication установив значение на no
PasswordAuthentication no
Перезапускаем ssh и sshd
systemctl restart ssh sshd
Безопасный метод авторизации на php
Давайте посмотрим вокруг: форумы, интернет магазины, гостевые книги и т.д. используют регистрацию и последующую авторизацию пользователей. Можно даже сказать, что это почти необходимая функция каждого сайта (только если это не домашняя страничка Васи Пупкина или не визитная карточка, какой-нибудь небольшой компании). Сегодня я хочу поделиться со всеми новичками информацией, о том, как лучше это все реализовать.
1. Модель (клиент)
Регистрация
— логин (a-z0-9)
— пароль
Вход
— логин
— пароль
Cookie
— уникальный идентификатор юзера
— хэш
Модель (сервер)
MySQL
Таблица users
user_id (int(11))
user_login (Varchar(30))
user_password (varchar(32))
user_hash (varchar(32))
user_ip (int(10)) по умолчанию 0
При регистрации в базу данных записываеться логин пользователя и пароль(в двойном md5 шифровании)
При авторизация, сравниваеться логин и пароль, если они верны, то генерируеться случайная строка, которая хешируеться и добавляеться в БД в строку user_hash. Также записываеться IP адрес пользователя(но это у нас будет опциональным, так как кто-то сидит через Proxy, а у кого-то IP динамический… тут уже пользователь сам будет выбирать безопасность или удобство). В куки пользователя мы записываем его уникальный индетификатор и сгенерированный hash.
Почему надо хранить в куках хеш случайно сгенерированной строки, а не хеш пароля?
1. Из-за невнимательности программиста, во всей системе могут быть дырки, воспользовавшийсь этими дырками, злоумышленик может вытащить хеш пароля из БД и подставить его в свои куки, тем самым получить доступ к закрытым данным. В нашем же случае, двойной хеш пароля не чем не сможет помочь хакеру, так как расшифровать он его не сможет(теоретически это возможно, но на это он потратит не один месяц, а может быть и год) а воспользоваться этим хешем ему негде, ведь у нас при авторизации свой уникальный хеш прикрепленный к IP пользователя.
2. Если злоумышленик вытащит трояном у пользователя уникальный хеш, воспользовать им он также не сможет(разве если только, пользователь решил принебречь своей безопастностью и выключил привязку к IP при авторизации).
2. Практика-- <br>
-- Структура таблицы `users` <br>
-- <br>
CREATE TABLE `users` ( <br>
`user_id` int(11) unsigned NOT NULL auto_increment, <br>
`user_login` varchar(30) NOT NULL, <br>
`user_password` varchar(32) NOT NULL, <br>
`user_hash` varchar(32) NOT NULL, <br>
`user_ip` int(10) unsigned NOT NULL default '0', <br>
PRIMARY KEY (`user_id`) <br>
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=1 ; <br>
register.php
<?
// Страница регситрации нового пользователя
# Соединямся с БД
mysql_connect(“localhost”, “myhost”, “myhost”);
mysql_select_db(“testtable”);
if(isset($_POST[‘submit’]))
{
$err = array();
# проверям логин
if(!preg_match(“/^[a-zA-Z0-9] $/”,$_POST[‘login’]))
{
$err[] = “Логин может состоять только из букв английского алфавита и цифр”;
}
if(strlen($_POST[‘login’]) < 3 or strlen($_POST[‘login’]) > 30)
{
$err[] = “Логин должен быть не меньше 3-х символов и не больше 30”;
}
# проверяем, не сущестует ли пользователя с таким именем
$query = mysql_query(“SELECT COUNT(user_id) FROM users WHERE user_login='”.mysql_real_escape_string($_POST[‘login’]).“‘”);
if(mysql_result($query, 0) > 0)
{
$err[] = “Пользователь с таким логином уже существует в базе данных”;
}
# Если нет ошибок, то добавляем в БД нового пользователя
if(count($err) == 0)
{
$login = $_POST[‘login’];
# Убераем лишние пробелы и делаем двойное шифрование
$password = md5(md5(trim($_POST[‘password’])));
mysql_query(“INSERT INTO users SET user_login='”.$login.“‘, user_password='”.$password.“‘”);
header(“Location: login.php”); exit();
}
else
{
print “<b>При регистрации произошли следующие ошибки:</b><br>”;
foreach($err AS $error)
{
print $error.“<br>”;
}
}
}
?>
<form method=”POST”>
Логин <input name=”login” type=”text”><br>
Пароль <input name=”password” type=”password”><br>
<input name=”submit” type=”submit” value=”Зарегистрироваться”>
</form>
login.php
<?
// Страница авторизации
# Функция для генерации случайной строки
function generateCode($length=6) {
$chars = “abcdefghijklmnopqrstuvwxyzABCDEFGHI JKLMNOPRQSTUVWXYZ0123456789”;
$code = “”;
$clen = strlen($chars) – 1;
while (strlen($code) < $length) {
$code .= $chars[mt_rand(0,$clen)];
}
return $code;
}
# Соединямся с БД
mysql_connect(“localhost”, “myhost”, “myhost”);
mysql_select_db(“testtable”);
if(isset($_POST[‘submit’]))
{
# Вытаскиваем из БД запись, у которой логин равняеться введенному
$query = mysql_query(“SELECT user_id, user_password FROM users WHERE user_login='”.mysql_real_escape_string($_POST[‘login’]).“‘ LIMIT 1”);
$data = mysql_fetch_assoc($query);
# Соавниваем пароли
if($data[‘user_password’] === md5(md5($_POST[‘password’])))
{
# Генерируем случайное число и шифруем его
$hash = md5(generateCode(10));
if(!@$_POST[‘not_attach_ip’])
{
# Если пользователя выбрал привязку к IP
# Переводим IP в строку
$insip = “, user_ip=INET_ATON(‘”.$_SERVER[‘REMOTE_ADDR’].“‘)”;
}
# Записываем в БД новый хеш авторизации и IP
mysql_query(“UPDATE users SET user_hash='”.$hash.“‘ “.$insip.” WHERE user_id='”.$data[‘user_id’].“‘”);
# Ставим куки
setcookie(“id”, $data[‘user_id’], time() 60*60*24*30);
setcookie(“hash”, $hash, time() 60*60*24*30);
# Переадресовываем браузер на страницу проверки нашего скрипта
header(“Location: check.php”); exit();
}
else
{
print “Вы ввели неправильный логин/пароль”;
}
}
?>
<form method=”POST”>
Логин <input name=”login” type=”text”><br>
Пароль <input name=”password” type=”password”><br>
Не прикреплять к IP(не безопасно) <input type=”checkbox” name=”not_attach_ip”><br>
<input name=”submit” type=”submit” value=”Войти”>
</form>
check.php
<?
// Скрипт проверки
# Соединямся с БД
mysql_connect(“localhost”, “myhost”, “myhost”);
mysql_select_db(“testtable”);
if (isset($_COOKIE[‘id’]) and isset($_COOKIE[‘hash’]))
{
$query = mysql_query(“SELECT *,INET_NTOA(user_ip) FROM users WHERE user_id = ‘”.intval($_COOKIE[‘id’]).“‘ LIMIT 1”);
$userdata = mysql_fetch_assoc($query);
if(($userdata[‘user_hash’] !== $_COOKIE[‘hash’]) or ($userdata[‘user_id’] !== $_COOKIE[‘id’])<br> or (($userdata[‘user_ip’] !== $_SERVER[‘REMOTE_ADDR’]) and ($userdata[‘user_ip’] !== “0”)))
{
setcookie(“id”, “”, time() – 3600*24*30*12, “/”);
setcookie(“hash”, “”, time() – 3600*24*30*12, “/”);
print “Хм, что-то не получилось”;
}
else
{
print “Привет, “.$userdata[‘user_login’].“. Всё работает!”;
}
}
else
{
print “Включите куки”;
}
?>
Для защиты формы логина от перебора, можно использовать <a href=«captcha.ru target=»_blank”>капчу.
Хочу отметить, что здесь я рассматривал авторизацию основоную на cookies, не стоит в комментариях кричать, что сессии лучше/удобнее и т.д. Спасибо.
Вход по ssh ключу для локальных администраторов windows
В OpenSSH используются особые настройки доступа по ключам для пользователей с правами локального администратора Windows.
Генерация сертификата
Первое что нужно сделать, это собственно получить сертификат, с которым можно будет работать. Если у вас уже есть готовый сертификат, можете переходить к следующему разделу.
Импортируем закрытый ключ в putty
PuTTY – прекрасный и наверное самый лучший SSH клиент для масдая. Который работает без нареканий и обладает всем необходимым функционалом. Бесплатный. Всё в нём хорошо. Но именно на этом поприще они решили отличиться и добавить чуть-чуть геморроя в процесс.
Вместе с PuTTY поставляется утилита PuTTYgen (PuTTY Key Generator).
Использование putty для windows
, отличный бесплатный клиент под Windows.
Использование туннеля через другой шелл
клиент -> сервер использующий туннель 5678
Клиент># ssh -L5678:localhost:5678 host1 # 5678 произвольный порт для туннеля хост_1># ssh -L5678:localhost:5678 host2 # звено 5678 с хохта1 на хост2 хост_2># ssh -L5678:localhost:22 server # и тцннель на порт 22 сервера
Ключевая пара
Одним из фундаментальных терминов в асимметричном шифровании является термин ключевой пары. Фактически он представляет собой совокупность открытой и закрытой частей ключа. Эти части математически связаны между собой таким образом, что открытой частью можно зашифровывать информацию, а закрытой частью расшифровывать.
Обратите внимание, что мы можем передавать открытую часть ключа по незащищенным каналам связи, не боясь компрометации закрытой части. При этом из открытой части нет возможности получить закрытую часть. В этом и заключается его функция и главное отличие от симметричного ключа, получение которого третьими лицами означает возможность доступа к зашифрованной информации.
Конвертация ключей
В статье использовалась небольшая хитрость, которая может пригодиться в рабочей деятельности.
Представьте простую и вполне реальную ситуацию. Вы сгенерировали ключевую пару и хотели бы распространить ее на других своих устройствах. Проблемой может стать желание перенести ключевую пару на Linux, которая была сгенерирована при помощи PuTTYgen под Windows.
К сожалению, если скопировать такой ключ и попытаться произвести вход на SSH сервер, мы скорее всего получим ошибку: Load key «/root/.ssh/id_rsa»: invalid format, либо подобные.
Это связано с тем, что закрытая часть ключа, генерируемая разными инструментами, будет сформирована в разных форматах. Сама структура файла будет отличаться и для решения проблемы потребуется процедура конвертации.
Самый просто способ — запустить PuTTYgen, загрузить сохраненную закрытую часть ключа при помощи кнопки Load.
Перейти в раздел Conversions и выбрать меню Export OpenSSH key.
Инструмент позволит нам сохранить закрытую часть в формате (PEM), который генерирует ssh-keygen.
Точно таким же методом мы можем производить обратное преобразование из PEM в формат PuTTY. Таким образом, нет необходимости создавать разные сущности ключей, мы сможем использовать одну.
Конфигурация клиента. формирование ключевой пары на linux (ssh-keygen)
Теперь попробуем сгенерировать ключевую пару из под Linux при помощи инструмента ssh-keygen. Для теста воспользуемся Ubuntu.
Выполним команду ssh-keygen. Мастер сообщит нам о начале процедуры генерации ключевой пары. Инструмент также спросит о том, где разместить ключ и будем ли мы использовать ключевую фразу. Оставим все значения по умолчанию и продолжим.
В итоге в папке ~/.ssh должны появиться две части ключа. id_rsa — закрытая часть, id_rsa.pub — открытая часть.
Нам необходимо позаботиться о том, чтобы никто не имел прав доступа кроме нас самих к этим ключам. Для этого выполним команду:
chmod 600 ~/.ssh/id*
Скопируем открытую часть ключа себе в буфер обмена, т.к нам понадобится добавить эту информацию на сервер в следующем этапе. Для этого выполним команду:
cat ~/.ssh/id_rsa.pub
Конфигурация сервера. разрешение аутентификации по ключу и добавление ключей на linux.
Возвращаемся на наш сервер. На этом этапе нам необходимо добавить открытую часть ключа для аутентификации пользователя и разрешить аутентификацию по ключу.
Конфигурация сервера. разрешение аутентификации по ключу и добавление ключей на 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 2021. Для быстрой установки откроем 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
Настраиваем авторизацию в iis по сертификатам используя onetoone
Всем доброго времени суток. Так уж получилось, на работе необходимо было настроить сервер с IIS, да не просто настроить, но повесить авторизацию на разные сервисы с использованием только определенного сервису сертификата. Данная проблема может быть решена использованием нескольких центров генерации, но не будем все усложнять и приступим к настройке «ОдинКОдному» нашего IIS.
Генерация необходимых ключей очень подробно описана в интернете(статья на хабре) и не должна вызвать особых проблем, поэтому эту часть я опущу.
Переходим к делу:
1) Устанавливаем IIS и необходимые компоненты. Обязательно отмечаем «Проверка подлинности с сопоставлением сертификата клиента IIS».
2) Для привязки нам понадобится клиентский сертификат в кодировке base64, его очень просто экспортировать из остнастки (certmgr.msc) «Сертификаты» или из «Свойства обозревателя».
3) Полученный сертификат открываем в текстовом редакторе и выстаиваем в одну линию, предварительно удалив строчки «BEGIN CERTIFICATE» и «END CERTIFICATE».
С подготовкой закончили переходим к серверу.
4) Запускаем остнастку (inetmgr) «Диспетчер служб IIS», и устанавливаем сертификат сервера. В моём случае CN сертификата Localhost.
5) После этого мы можем привязать этот сертификат к сервисам. Идем в привязки и выбрав Https указываем необходимый порт и сертификат.
6) В параметрах SSL отмечаем «Требовать SSL» и сертификат клиента «требовать».
7) Теперь любой сертификат выпущенный нашим УЦ подойдет для авторизации, но цель данной статьи как раз показать следующий шаг когда клиентов с сертификатами необходимо разделить. Идем в «Редактор конфигураций» по адресу: «system.webServer/security/authentication/iisClientCertificateMappingAuthentication».
8) Здесь предстоит сделать выбор или мы пускаем по конкретным сертификатам или по определенному полю в сертификате (например уникальный OID).
9) Рассмотрим параметр «oneToOneCertificateMappingsEnabled». Установив его значении в «True» мы сможем привязать конкретный сертификат к пользователю.
10) Полученный на втором пункте сертификат вставляем в поле «certificate». Поля «userName» и «password» заполняем учетной записью, которую предварительно создали.
11) Теперь при предъявлении занесенного клиентского сертификата мы получим доступ с правами указанной учетной записи. Однако все остальные сертификаты продолжат преспокойно работать и получать анонимный доступ, что бы этого избежать необходимо в iis, отключить анонимную проверку подлинности.
На этом этапе авторизация должна проходить только по заданному сертификату.
Код для appcmd:
appcmd.exe set config "Default Web Site" -section:system.webServer/security/authentication/iisClientCertificateMappingAuthentication /enabled:"True" /oneToOneCertificateMappingsEnabled:"True" /commit:apphost
appcmd.exe set config "Default Web Site" -section:system.webServer/security/authentication/iisClientCertificateMappingAuthentication / "oneToOneMappings.[userName='22',password='22',certificate='текст сертификата в кодировке base64']" /commit:apphost
appcmd.exe set config "Default Web Site" -section:system.webServer/security/access /sslFlags:"Ssl, SslNegotiateCert, SslRequireCert" /commit:apphost
Настройка подключения putty с использованием ssh сертификата
Добавьте приватный сертификат в подключение:
Connection > SSH > Auth > Private key file for authentication
При успешном подключении после ввода имени пользователя, выйдет запрос ключевой фразы сертификата, после чего вход на сервер должен быть успешно выполнен.
💡 Если при входе на сервер вы получаете сообщение SSH Server refused our key, проверьте правильность прав на папку .ssh и файл authorized_keys, а так же что вы входите под тем именем пользователя, в authorized_keys которого добавлен ваш ключ.
Общая схема аутентификации по сертификатам
Когда пользователь аутентифицируется при помощи сертификата на веб-сайте, происходит примерно следующий процесс:
- Пользователь запрашивает доступ к некоторой сетевой службе;
- По запросу сервер посылает клиенту свой серверный сертификат (сертификат SSL). Клиент проверяет его на валидность. Если проверка провалилась, на этом всё заканчивается;
- Если проверка прошла успешно, клиент запрашивает доступ к ресурсам службы;
- Служба сконфигурирована на обязательную аутентификацию пользователя и отправляет клиенту доступные (на сервере) методы аутентификации. В нашем случае это требование клиентского сертификата;
- Клиент посылает на сервер публичную часть своего сертификата и некоторый объём подписанных клиентским сертификатом данных. Сервер проверяет клиентский сертификат на валидность. Если сертификат не прошёл проверку — разговор клиента и сервера на этом завершается. Если сертификат прошёл проверку, сервер пытается сопоставить (или ассоциировать) сертификат с учётной записью пользователя. Если сопоставление не удалось — разговор завершается.
- Если учётная запись найдена и сертификат удалось сопоставить с ней, сервер начинает установку защищённого канала. После установки этого канала, сервер предоставляет пользователю ресурсы в том объёме, в котором это позволяют списки доступа (ACL, например).
Я посчитал нужным немного развернуть последний пункт, чтобы вы понимали общее устройство этого канала (поскольку, у людей есть некоторые заблуждения на этот счёт):
- Клиент запрашивает установку безопасного канала;
- Сервер отвечает согласием и пересылает клиенту список поддерживаемых симметричных протоколов шифрования;
- Клиент посылает на сервер свой список протоколов симметричного шифрования;
- Клиент и сервер договариваются и выбирают наиболее подходящий протокол. Например, — Я умею DES и 3DES, а что умеешь ты? — А я умею только 3DES и AES. — Отлично, давай тогда использовать 3DES;
- Клиент на своей стороне генерирует сессионный симметричный ключ шифрования и шифрует его открытым ключом сертификата сервера. Этот процесс называется Key exchange. Как мы знаем, прочитать этот ключ сможет только веб сервер, т.к. только он владеет закрытым ключом, который ассоциирован с конкретным сертификатом SSL;
- После этого, все передаваемые данные шифруются именно этим сессионным ключом. Помните, что при передаче данных сертификаты уже не используются (а многие считают, что все данные шифруются открытыми ключами сертификатов). Сертификаты используются только при обновлении сессионного ключа (который периодически меняется).
Немного другой процесс происходит при интерактивном логоне или логоне на сервер терминалов посредством Remote Desktop при помощи смарт-карты.
Отключить авторизацию ssh по паролю
Если Вам удалось подключится к серверу SSH посредством ключа, то наверное не плохим решением будет полное отключение авторизации по паролю, хотя я предпочитаю оставить запасной вход обычно. Для этого на сервере необходимо открыть файл /etc/ssh/sshd_config и изменить следующую строку:
на вот такую:
И не забудьте перезапустить сервер Open-SSH
На этом все. Можете «слить» созданные вами ключи на флешку и использовать их для авторизации по ssh без ввода пароля.
Отладка
Если что-то не работает:
Отладка multi-hop ssh tunnel
Предположим, вы не можете получить прямой доступ к
ssh
, только через промежуточные хосты(например из-за проблем с маршрутизацией), но получить соединение клиент-сервер вам необходимо, к примеру что-бы скопировать файлы через
SCP
или пробросить порт для
SMB
.. Сделать это можно, организовав туннель из цепочки хостов.
Допустим нам нужно перебросить
ssh
порт клиента к серверу, в два скачка. Когда туннель будет создан, будет возможно прямое подключение клиент – сервер.
Создание туннеля в одной оболочке:
клиент -> хост1 -> хост2 -> сервер and dig tunnel 5678
Клиент># ssh -L5678:localhost:5678 host1 # 5678 произвольный порт для туннеляхост_1># ssh -L5678:localhost:5678 host2 # звено 5678 с хохта1 на хост2хост_2># ssh -L5678:localhost:22 server # и тцннель на порт 22 сервера
Подготовка папок
Выполняем подготовку папок и файла ключа на сервере.
Важный момент при настройке авторизации SSH по ключам — это указать правильные Права доступа на папку и файл ключа.
Выполните:
mkdir ~/.ssh
chmod 0700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 0644 ~/.ssh/authorized_keys
Подключение двух клиентов, сидящих за nat
Есть две машины, находящиеся за NAT шлюзом, клиенту
Подключение к рабочему столу, расположенному за nat
Предположим нужно получить доступ к Windows клиенту с
VNC
слушающем на
5900
порту.
От клмента
cliwin
на шлюз:
Подключение к серверу ssh по открытой части ключа на linux.
Выполним подключение к серверу SSH. Для этого запустим на исполнение команду:
ssh vagrant@127.0.0.1 -p 2222
По итогу мы пройдем процедуру аутентификации без указания пароля для учетной записи пользователя.
Результат ssh аутентификации по ключу на сервере CentOS или Ubuntu.
Результат ssh аутентификации по ключу на сервере Windows.
Подключение к серверу ssh по открытой части ключа на windows.
Запустим PuTTY и введем адрес подключения к SSH серверу.
В разделе Connection > SSH > Auth укажем сохраненный файл закрытой части ключа и пробуем подключиться к нашему серверу.
По итогу мы пройдем процедуру аутентификации без указания пароля для учетной записи пользователя.
Результат ssh аутентификации по ключу на сервере CentOS или Ubuntu.
Результат ssh аутентификации по ключу на сервере Windows.
Получение private key из хранилища средствами c#
Для поиска сертификата в хранилище я буду использовать Thumbprint. Посмотреть его значения можно в Details разделе требуемого сертификата.
Код для поиска максимально простой и представляет из себя следующее:
var thumbprint = "170af897569602508cc81d65c18b983ab0ad8cff"; X509Store store = new X509Store(StoreName.My, StoreLocation.LocalMachine); store.Open(OpenFlags.ReadOnly); var certificates = store.Certificates.Find(X509FindType.FindByThumbprint, thumbprint, false); store.Close();
Фактически, в данном случае ищутся все сертификаты, содержащие данный thumbprint, в том числе не валидные. Если установить true в четвёртой строке, тогда не валидные сертификаты будут проигнорированы. Дальше получаем private key и соединяемся с SFTP сервером:
Предварительная настройка сервера
Разрешим вход с использованием публичного сертификата SHH на сервер и укажем путь до сертификата в настройках SSH, файл sshd_config.
nano /etc/ssh/sshd_config
Раскомментируйте или добавьте значения:
PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys
Применение на практике
Теперь, после небольшой теории, давайте попробуем применить полученную информацию на более реальных задачах. Для возможности аутентификации по открытому ключу нам будет необходимо сгенерировать ключевую пару о которой мы говорили чуть ранее на стороне клиента.
Также нам будет необходимо установить и сконфигурировать SSH сервер. В качестве примера мы возьмем популярный проект — OpenSSH Server, который доступен для установки на различных операционных системах в т.ч — Windows и Linux.
Пример автоматического подключения из windows через putty и puttygen
Для начала скачаем с официального сайта обе утилиты отсюда.
еперь утилитой PuTTYgen сгенерируем публичный и приватный ключ. Открываем утилиту и нажимаем Generate:
После нажатия, необходимо произвольно водить мышкой для заполнения массива случайных чисел, примерно в квадрате под полосой загрузки:
По окончании процесса генерации, утилита предоставит Вам сгенерированный приватный и публичный ключ. Публичный, который обведен красным прямоугольником, нужно занести в файл authorized_keys, который находится в папке .
ssh корне Вашего аккаунта на сервере, а приватный ключ сохраняем себе на компьютер. Для этого нажимаем на кнопку Save private key. Учтите, что приватный ключ нельзя ни показывать, ни передавать, иначе смысл безопасного подключения теряется.
Сейчас скопируем публичный ключ в файл .ssh/authorized_keys находящийся на Вашем аккаунте. Для этого открываем утилиту Putty:
Примечание
В случае, если Центр Идентификации не сможет извлечь клиентский сертификат из запроса и корректно аутентифицировать пользователя, Пользователю будет предложена интерактивная аутентификация в Веб-Интерфейсе ЦИ.
Для запрета интерактивного взаимодействия с Веб-Интерфейсом ЦИ необходимо передать в запросе дополнительный параметр prompt=none. В этом случае при невозможности аутентификации пользователя по сертификату ЦИ вернет ошибку.
Проверка sftp через filezilla
Если у вас не получается установить соединения с SFTP сервером, попробуйте сперва проверить корректность работы самого сервера и имеющихся сертификатов. Сделать это можно через FileZilla клиент.
Выбрать File – Site Manager. Добавить новый сайт, заполнить данные, в качестве Logon Type выбрать “Key file”, указать сам .ppk ключ и нажать Connect
Если все данные верны, тогда вы соединитесь с вашим SFTP сервером.
На этом всё, надеюсь информация будет полезной.
Приятного программирования.
Прямой форвардинг на шлюз
Предположим, нам нужно получить доступ к
CVS
(порт
2401
) и
Работа с сертификатами в php
День добрый, люди добрые!
Первый раз приходится работать с сертификатами в PHP.
Задача у меня такое: авторизацию через сертификаты, на сайте конечно же.
Сертификат в закрытом виде , то есть расширение в виде *.p12.
Как я понял это #PKCS12 = cer private_key.
В сети есть примеры, как прочитать с помощью библиотеки open SSL(openssl_pkcs12_read).
Но оно выдает ошибку :
error:0D06B08E:asn1 encoding routines:ASN1_D2I_READ_BIO:not enough data
Сам код выглядит так:
<?php
print 'OpenSSl Certificate Test!';
$filename = 'rai.p12';
$password = '123456';
$results = array();
$worked = openssl_pkcs12_read($filename, $results, $password);
if($worked) {
echo '<pre>', print_r($results, true), '</pre>';
} else {
echo openssl_error_string();
}
?>
PS: хотелось бы узнать подробнее, как работают сертификаты , как пользоваться с функциями openssl, буду рад к любым советам/комментам/ссылкам.
Симметричное и асимметричное шифрование
Мы начнем наше знакомство с понятия симметричного шифрования. Подобный тип появился очень давно. В его основе лежит главный принцип — информация шифруется и расшифровывается одним и тем же ключем.
Асимметричное шифрование противопоставляется симметричному. Этот тип появился в 70-х годах и позволил применять новые подходы, при которых процедуры шифрования и дешифровки информации производятся разными, но взаимосвязанными ключами. Именно на принципе использования разных частей ключей основана аутентификация по открытому ключу.
Смотреть видеоурок
Статья была написана на основе видеоурока Хауди Хо, который Вы можете посмотреть ниже. Скрипт из видео был немного доработан (добавлена капча function captcha_show).
Создание ssh-ключей
По умолчанию в корневой директории пользователя находится директория .ssh, если по какой то причине её нет, то создаём её командой:
1) Cоздаем открытый и закрытый ключ нашей локальной системы:
$ ssh-keygen -t rsa -q -N '' -f ~/.ssh/id_rsaПодробнее о ключах можете посмотреть с помощью команды:
2) Если в системе есть программа ssh-copy-id, то настраиваем удаленную систему на то, чтобы она авторизовывала SSH по открытому ключу:
переходим к шагу 4
3) Если ssh-copy-id нет, то можно сделать это вручную.
Вот последовательность действий:
3.1) копируем открытый ключ на удаленную систему:
3.2) Авторизуемся на удаленном сервере:
3.3) Заносим открытый ключ нашей локальный системы в авторизованные ключи удаленной системы, устанавливаем правильные права и “убираем за собой мусор”:
remote$ [ -d ~/.ssh ] || (mkdir ~/.ssh; chmod 711 ~/.ssh) # создаем директорию и даём права
remote$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys # добавляем открытый ключ
remote$ chmod 600 ~/.ssh/authorized_keys # делаем правильные права
remote$ rm ~/id_rsa.pub # удаляем не нужное4) Проверяем, что все работает, запускаем на локальном компьютере:
Создание ssh-ключей в linux на примере centos
На клиентской стороне должен быть установлен пакет ssh (openssh). На серверах FirstVDS с шаблонами по умолчанию необходимое ПО уже установлено.
yum -y install openssh-server openssh-clients
На клиентском компьютере в командной строке выполните команду генерации ключей:
ssh-keygen
Введите путь файла, в который будут помещены ключи. Каталог по умолчанию указан в скобках, в примере /домашний_каталог/.ssh/id_rsa. Если хотите оставить расположение по умолчанию, нажмите Enter.
Пароль (passphrase) используется для ограничения доступа к закрытому ключу. Пароль усложнит использование ключа третьими лицами в случае утраты. Если не хотите использовать секретную фразу, нажмите Enter без заполнения строки.
Успешно сгенерировав пару ключей, вы увидите уведомление:
Открытый ключ хранится в файле /домашний_каталог/.ssh/id_rsa.pub, закрытый — /домашний_каталог/.ssh/id_rsa.
Скопируйте открытый ключ на сервер в файл /домашний_каталог/.ssh/authorized_keys. Одной строкой:
cat ~/.ssh/id_rsa.pub | ssh root@ip-адрес-сервера 'cat >> ~/.ssh/authorized_keys'
Или откройте этот файл на сервере редактором vi и вставьте строку с открытым ключом после ssh-rsa.
Создание ssh-ключей на windows с puttygen
Если вы используете ОС Windows, то подключиться по SSH к вашему (Linux) серверу можно через PuTTY или OpenSSH. Генерация ключей в этом случае выполняется также при помощи этих программ. В примере мы используем клиент PuTTY.
Запустите приложение PuTTYgen, которое устанавливается вместе с PuTTY.
Выберите тип ключа SSH2-RSA и нажмите Generate.
В процессе генерации ключей несколько раз произвольно проведите мышкой по экрану приложения для создания случайных величин, используемых для ключей.
После завершения создания ключей открытый ключ выводится на экран, закрытый хранится в памяти приложения. Чтобы сохранить эти ключи нажмите Save public key и Save private key. Укажите расположение файлов с ключами.
При сохранении закрытого ключа, если не заполнено поле Key passphrase, появится запрос «Хотите ли вы сохранить ключ без секретной фразы?»
Теперь открытый ключ необходимо скопировать на сервер в файл authorized_keys. Используйте WinSCP или другой клиент для работы с файлами на удалённом Linux-сервере. Вы можете скопировать файл с открытым ключом целиком на сервер, чтоб его копия хранилась в папке .ssh
Откройте файл authorized_keys через WinSCP и файл, в который вы сохранили открытый ключ (public), на локальном компьютере текстовым редактором. Скопируйте значение ключа, сохраните и закройте файл в WinSCP.
При запуске PuTTY укажите путь к закрытому ключу на локальном компьютере. Для этого во вкладке Connections → Auth выберите необходимый путь.
Теперь можно отключить на сервере аутентификацию по паролю и использовать только SSH-ключи.
Создание защищенного ssh туннеля
SSH
туннелирование позволяет делать форвардинг портов (перенаправление) через
SSH
туннель, обеспечивая прохождение трафика через заблокированые порты (работает только с протоколом
TCPSSH
Туннель создается из слушающего сокета на определенном порту
localhost
. Затем все принятые на локальном хосте/порту соединения перенаправляются через
SSH
на удаленный хост/порт.
Устанавливаем ключи с помощью ssh-copy-id
Утилита используемая для доставки ключей на удалённые хосты. Можно применить её на текущий хост указав localhost вместо имени или адреса сервера к которому подключаемся
Установка сертификата
Для работы с private кодом, мы можем хранить его где-то в ресурсах приложения, что не очень правильно с точки зрения безопасности, либо если это возможно, использовать хранилище. Я покажу как работать со вторым вариантом.
Выполним установку сертификата:
В качестве места хранения выберем Local Machine
Укажем текущий пароль от сертификата, а также установим опцию «Mark this key as exportable. This will allow you to back up or transport your keys at a later time.» В таком виде ваш сертификат будет содержать private ключ после установки, который можно будет использовать из вашего приложения.
После завершения установки можно проверить корректность размещения:
В данном случае сертификат установился корректно и готов к использованию.
Форвардинг портов netbios и удаленного рабочего стола
Имеем Windows SMB сервер за шлюзом, и отсутствие
ssh
. Необходимо получить доступ к расшаренным
SMB
папкам и удаленному рабочему столу.
Форма регистрации
В файле signup.php находится обработчик и сама форма регистрации. Для таких форм рекомендуется использовать метод запроса POST, при котором веб-сервер принимает данные, заключённые в тело сообщения, для хранения.
Логон смарт-картой или pkinit
Интерактивная аутентификация в Active Directory по сертификату не является самостоятельным механизмом. Как и всегда, основной протокол аутентификации в домене — Kerberos. Чтобы обеспечить взаимодействие между аутентификацией по смарт-карте и Керберосом, применяется нехитрый протокол PKINIT.
Примечание: если у пользователя уже есть соответствующий сервисный тикет (TGS), выполняются только шаги 5 и 6.
Заключение.
Мы рассмотрели как производить авторизацию по SSL с использованием клиентского сертификата.
Полезная информация: Certificate, Key, and Trust Services Tasks for iOSОписание PKCS12 Creating .NET web service with client certificate authenticationCertificate Authentication in asp.netJava 2-way TLS/SSL (Client Certificates) and PKCS12 vs JKS KeyStores
Спасибо за внимание!