Comments 5
Существуют аппаратные модули (HSM), специально предназначенные для выполнения криптографических операций. Они гарантируют, что никто и никогда не сможет добраться до закрытого ключа. Проблема в том, что HSM недостаточно быстры для обработки миллионов запросов, с которым работает Github.
Те, кто не хочет покупать HSM, и не стремится конкурировать по посещаемости с Github, могут хранить приватный ключ в TPM (рассматривается ситуация с точки зрения хранения приватного ключа клиента, но, думаю, это должно работать и в обратную сторону, т.е. применимо и для сервера).
OpenSSH вообще очень странная штука.
У меня были ситуации с ним, например, не принимает конкретный ключ в authorized_keys. Или автоматически первым пунктом зовёт auth=none, но так, что pam_unix видит проверку с пустым паролем для акаунта с реальным паролем и тормозит процесс на пару секунд, а sshd решает, что раз была задержка, надо её усилить, и добавляет ещё две секунды. Или из проб приватных ключей берёт только первые 4, а остальные пропускает (ну вот надо было в конфиге по умолчанию много ключей вписать). Код написан местами вредительски.
А то, что все ключи надо собирать в один файл и свойства к ним писать в потенциально опасном формате? (там где no-agent-forwarding, forced_command и всё такое)
Я бы даже сказал, что основная проблема с ним это безальтернативность. Есть, фактически, одна реализация на всех. Dropbear есть, но ограничен по свойствам. LSH по сути умер. Реализация от ssh.fi зохавана корпорастами.
Почему, в отличие от 100500 других средств, нет альтернативных реализаций, например, от GNU или Apache?
Чтобы были альтернативные реализации, надо чтобы кто-то ими пользовался и отлавливал все баги. Спрашивается, где найти желающих рисковать в таком чувствительном деле как управление сервером?
У обычного человека вполне понятное отношение к таким вещам: чем больше цена ошибки, тем меньше желание экспериментировать и рисковать.
Спрашивается, где найти желающих рисковать в таком чувствительном деле как управление сервером?
Неее, не проходит такая логика. Потому что тогда была бы единственная система управления стартом/стопом (да, systemd занимает сейчас бо́льшую часть, но есть много возможностей ставить без него), единственный пакетный менеджер (а сейчас rpm+yum, rpm+dnf, deb+apt, pacman, и ещё десяток)...
Или что, компиляция не ответственное дело? По-моему, более ответственное даже. Имеем GCC, Clang+LLVM, ICC, Open64 в двух клонах, и ещё парочку простейших, пригодных для контроля корректности компиляции.
Или управление сетью — тоже критично для "управления сервером": даже не вспоминая облачные средства — на NetworkManager свет клином не сошёлся.
Нет, тут что-то другое.
Хорошая статья. По части безопасности можно эффективно использовать на своих серверах 12+ значные пароли, а так же fail2ban для защиты от брутфорса. Пароли просто необходимо менять раз в полгода и всё.
Как защищать свои ключи SSH. Почему не сертификаты?