GnuTLS — это программная библиотека для работы с SSL/TLS и сертификатами. Она может примерно то же, что и openssl, но разрабатывается независимо. Аналогично в составе gnutls есть набор консольных программ для работы с сертификатами, протоколами и прочими данными: certtool, gnutls-serv, gnutls-cli и т.д.
В плане работы с файлами сертификатов, ключей и CSR-запросов утилиты gnutls умеют делать практически то же самое, что и бинарник openssl. В этой статье я детально опишу типичные сценарии использования: создание ключей, сертификатов, запросов на сертификат, подписывание сертификатов.
Другие мои статьи на эту тему, но на базе openssl:
Certtool входит в состав gnutls и в debian/ubuntu ставится командой:
$ sudo apt install gnutls-bin
На макоси gnutls ставится через Homebrew:
$ brew install gnutls
С какой-то из версий freetype опять разломали отображение шрифтов и они снова стали выглядеть размыто и нечётко.
Единственный способ глобально исправить — это прописать вот такое в файл /etc/environment
:
FREETYPE_PROPERTIES="truetype:interpreter-version=35"
Это заставляет freetype использовать указанную версию интерпретатора, в этой версии шрифты рисуются нормально.
Эта статья о том, как настроить зашифрованное (SSL) RDP-подключение к виртуалкам на VirtualBox. В качестве гостевой системы используется Linux (Debian/Ubuntu). Базовая документация, на основе которой написана статья: https://www.virtualbox.org/manual/ch07.html.
У VirtualBox есть возможность подключаться к экрану запущенной виртуалки через RDP. Однако в GUI все необходимые для этого настройки отсутствуют и нужно использовать утилиту VBoxManage в командной строке.
Чего мы хотим добиться: защищённое TLS-соединение до виртуальной машины с аутентификацией по логину и паролю. Все настройки делаем целиком из командной строки.
Задача: использовать сертификаты Let's Encrypt для персонального сервера Debian/Ubuntu: вебсервер, почта, xmpp. Для операций над сертификатами используем certbot.
Серверный софт: Nginx, Prosody, Exim4.
Дальше все инструкции для моих доменов, это в точности та конфигурация, которая у меня на сервере.
Текст будет обновляться по мере возникновения новых проблем.
Что такое и зачем нужен SSH Agent¶
SSH Agent (SSH Агент) хранит в памяти компьютера закрытые SSH-ключи. Когда SSH-клиент (/usr/bin/ssh
в линуксе и макоси, например) пытается подключиться к серверу при помощи ключа, она сначала делает запрос к SSH Agent и делегирует ему криптографическую операцию с закрытым ключом, который никогда не покидает пределы агента.
Без SSH Agent SSH-клиент напрямую читает ключи с диска, в линуксе и макоси они лежат в каталоге ~/.ssh
, если ключ зашифрован, то клиент спрашивает соответствующую парольную фразу. SSH Agent импортирует ключи к себе в хранилище и требует задать новую парольную фразу для доступа к ключу. Агент запоминает, когда клиент запрашивал ключ и может потребовать ввести парольную фразу и/или показать дополнительный диалог с подтверждением.
В linux и macos по умолчанию стоит /usr/bin/ssh-agent
из openssh, однако он малофунциональный и сложный в настройке. Вместо него можно использовать агент из комплекта gnupg (gpg-agent
), он умеет не только PGP-ключами управлять, но и выполнять функцию SSH Агента. У gpg-agent есть два преимущества: он настраивается, а также позволяет задавать пароли для шифрования ключей в памяти.
Disclaimer: это краткая заметка о настройке «чистого» firefox под мои требования (штатные настройки, аддоны). Всё с учётом Firefox 97+. Аналогичная моя статья о настройках chrome.
Текст периодически актуализируется. Последнее обновление: 31 октября 2024 г.
Индекс (оглавление) очень помогает в навигации по PDF-документу. Однако в некоторых PDF-файлах его нет. Добавить его можно через командлайновую программу pdftk (она есть для всех операционных систем).
Схема простая:
- экспорт метаданных в файл;
- добавление в файл метаданных оглавления;
- обновление метаданных в исходном документе.
Внимание. Данный текст — устарел, я написал новую статью Смарт-карты и программирование (java), где в качестве языка примеров используется Java, а не C/C++. Если вы хотите просто узнать о смарт-картах, то читайте новую статью.
В новом тексте исправлены ошибки, уточнены формулировки, а также добавлены новые примеры, например, работа с контактными картами памяти SLE5542. Кроме того, там теперь есть оглавление.
Это статья о смарт-картах и о том, как писать софт для работы с ними. Никакого опыта в предметной области от вас не требуется, только знание C и C++ для понимания примеров кода, а также базовых структур данных, битов, байтов, указателей, malloc/new/free/delete и так далее. Все примеры ориентированы на unix-окружение, в первую очередь это linux и mac os x. Windows и мобильные операционные системы не рассматриваются.
Для всех примеров кода вам нужен десктопный терминал-ридер для смарт-карт. Для некоторых примеров подойдёт USB-крипто-токен — они работают через тот же интерфейс, что и смарт-карты.
Ещё в этом тексте будет очень много новых англоязычных терминов, сокращений, ссылок на международные стандарты и спецификации. Слишком глубоко в детали я вдаваться не стану, но буду ссылаться на внешние документы.
Очень желательно знать английский язык, так как все оригинальные стандарты и спецификации написаны на нём.
Первые примеры будут на С — это язык библиотеки pcsc, а затем переключусь на C++11 и собственную библиотеку-обёртку над pcsc.
Примерный план статьи:
- как подключиться к библиотеке;
- как подключиться к терминалу;
- базовые сведения об архитектуре PC/SC, терминология;
- базовые сведения о коммуникации с картой;
- несколько простейших примеров с картами;
- работа с «тупыми» бесконтактными картами памяти Mifare;
- более подробно о работе с микропроцессорными картами;
- пример работы с банковской картой.
Это древний текст, вместо него была написана более общая и систематизированная статья о многих аспектах использования SSH: Эффективная работа с SSH
Ранее я уже писал несколько раз об организации ssh-туннелей: SOCKS-прокси через SSH, Туннель через SSH-сервер. В этой статье я расскажу, как максимально безопасно организовать SOCKS-прокси через ssh-туннель.
Обычно, когда делают SOCKS-прокси-туннель, просто добавляют к команде соединения через ssh аргумент типа -D localhost:8008
. Потенциально это не очень безопасно по нескольким причинам:
- вместо аутентификации по ключу используется интерактивная аутентификация по паролю;
- на сервере может быть включен X-Forwarding, дыра;
- аутентификация происходит под обычным ssh-пользователем в интерактивной сессии.
Интерактивная сессия для туннеля не нужна, более того, если вы позволяете соединяться нескольким клиентам под одним аккаунтом, вы им фактически разрешаете выполнять любые команды на сервере.
Аутентификация по паролю также чревата последствиями. Например, если вы хотите разрешить нескольким разным людям подключения с туннелем, вам придётся создать несколько аккаунтов на сервере с разными паролями. Логин через ключи решает эту и ещё несколько других проблем.
Также для аутентификации для прокси-туннеля можно использовать отдельный ключ с простым паролем, это удобно.
За несколько месяцев активного внедрения git в компании я понял, что практически все обучающие статьи по этой теме бесполезны. Главная их проблема — они написаны для одиночек и почти полностью игнорируют аспекты командной работы именно технических специалистов. Технарям не нужно детально объяснять, как инициализировать новый репозиторий или как коммитить изменения, это всё ненужная механическая информация, которую легко найти, но вот даже базового понимания, как работает git, оно не даёт. К сожалению, в git очень много команд и очень много «непонятных» и «тупиковых» ситуаций, возникающих на ровном месте. Я специально пишу «непонятных», так как бо́льшая часть из них разруливается очень просто, нужно только понимать, что именно произошло.
Если вы хотите с разбега погрузиться во внутренности git, очень рекомендую статью Git from the inside out, в ней детально расписываются низкоуровневые механизмы работы репозитория.
А в моей статье я подробно расскажу о нюансах работы с git, на которые вы практически гарантированно наткнётесь в реальной работе, однако в обычных туториалах о них не прочитаете. Также я расскажу о типичных ошибках, заблуждения и вредных привычках. Некоторые вещи могут показаться банальными и очевидными, но поверьте, для кого-то они оказались неожиданными.
Также я старался все разделы статьи упорядочить по мере усложнения и расширения концепции. Все примеры кода должны воспроизводиться у каждого. Крайне желательно иметь linux/macos с терминалом под рукой. О совсем примитивных вещах типа установки git я тут писать не буду.
Весь текст полностью оригинален, не является переводом и базируется исключительно на официальной документации.