Часто перед разработчиками PHP встаёт задача проверить работу веб-приложения под несколько версий интерпретатора. Решить её можно разными способами. Можно банально установить разные версии PHP на один хост, но это чревато конфликтами библиотек и другими сложностями. Вторая крайность — сделать несколько изолированных виртуальных машин с разным окружением, но здесь не обойтись без чрезмерного использования аппаратных ресурсов и излишней траты времени на разворачивание рабочего окружения. На настоящий момент наиболее просто решить данную задачу можно с помощью Docker.
(Начальное название статьи «Алгоритм работы протокола SSH» было изменено по рекомендациям Vindicar, Karroplan и других участников хабросообщества)
Периодически читая статьи, посвящённые SSH, обратил внимание, что их авторы порой не имеют понятия, как работает этот протокол. В большинстве случаев они ограничиваются рассмотрением темы генерации ключей и описанием опций основных команд. Даже опытные системные администраторы часто несут полную ахинею при обсуждении вопросов работы SSH, выдавая опусы в стиле: передаваемые данные шифруются открытым SSH-ключом клиента, а расшифровываются закрытым, или: для шифрования данных при передаче используется алгоритм RSA.
Попытаюсь внести немного ясности в работу протокола SSH, а заодно рассмотреть роль алгоритма RSA и ключей авторизации пользователя…
Microsoft Azure — одна из самых крупных облачных платформ в мире. Даже несмотря на отсутствие у меня симпатий к сделавшей её корпорации, должен признать, что платформа обладает рядом удобств по сравнению с конкурентами. Но нет бочки мёда без ложки дёгтя, и этой ложкой в Microsoft Azure являются имена компонентов системы. Если в AWS переименовать компонент — дело двух кликов, то в Azure имена намертво привязываются к компонентам, и изменить их без танцев с бубном порой невозможно. Поэтому очень важно при работе с Azure изначально создать правильную структуру.
Про установку SSL-сертификатов на веб-сервер написано достаточно много, и обычно этот вопрос не вызывает сложности у системных администраторов. Однако непосредственно перед установкой неплохо сделать несколько проверок, чтоб не созерцать в браузере досадное «The site's security certificate is not trusted!» (Сертификат безопасности сайта не является доверенным!). Особенно это актуально, когда сертификаты вы получаете не от регистратора, а от заказчика, который может, к примеру, перепутать приватные ключи или выслать сертификат в формате своего текстового редактора с добавлением мусора форматирования.
Таким образом, чтоб всё и сразу заработало, перед установкой SSL-сертификата желательно сделать несколько проверок.
В наше время одним из самых важных аспектов безопасной передачи информации является шифрование. Данные при передаче от клиента к серверу зашифровываются с помощью SSL-сертификата. Сертификат – это публичный ключ, заверенный удостоверяющим центром.
Все SSL-сертификаты, как правило, выдаются на ограниченный срок, по окончании которого они теряют силу и должны быть переизданы. Однако бывают случаи, когда сертификат может быть отозван ещё до окончания срока действия. Причин на отзыв SSL-сертификата довольно много, самые распространённые из них – закрытый ключ был утерян или скомпрометирован, изменились регистрационные данные компании и т.п.
