Защита частных ключей SSH
У меня было изменение поведения модуля через апачские обновления. Возможно, что Вашим апачским conf директивам, возможно, понадобятся некоторые изменения для надлежащего подавания cgi. Не зная апачский conf и детали cgi и это - местоположение в файловой системе, его действительно твердое, чтобы сделать просто размышляют, больше, чем.
Также, если Вы делаете подозреваемого SELinux, попытайтесь отключить его, чтобы видеть, начинает ли апач служить CGI снова. Если это делает затем, можно начать фокусировать усилия или на корректировать политику позволить то, что Вы пытаетесь сделать или приносите свою систему в соответствие политике SELinux.
Я согласен с ErikA. Однако бывают ситуации, когда вам не нужны закрытые ключи, защищенные парольной фразой (например, для автоматического резервного копирования). В этом случае у вас и у каждого системного администратора есть закрытый ключ.
Если вам нужен общий закрытый ключ, вы можете ограничить доступ по IP: центральный сервер - это уникальное место, откуда кто-то может подключиться к другим машинам.
В зависимости от важности каждой машины у вас могут быть разные решения для каждой.
Закрытые ключи SSH никогда не должны покидать машину, на которой они были сгенерированы, если только они не будут перемещены на более безопасную платформу, такую как HSM. Точно так же они никогда не должны быть доступны никому, кроме человека, который их создал и будет использовать, например, с рабочей станции администратора или, что лучше, HSM / смарт-карты. Если вы собираетесь получать доступ к серверу с нескольких машин, сгенерируйте уникальный ключ на каждой машине и соответствующим образом разверните открытые ключи или поместите открытый ключ со смарт-карты или другого надежного аутентификатора в авторизованные ключи.
Для Для начала, я всегда рекомендую защищать закрытые ключи парольной фразой. Это снизит вероятность несанкционированного использования ключа, если он попадет в чужие руки. Более высокая мера безопасности - встроить закрытый ключ в смарт-карту, и использовать на нем криптографические функции через промежуточное ПО. Redhat упрощает все это.
Как вы защищаете свои личные ключи ssh? Я читал про ssh-agent, но я Я не уверен, как его использовать и можно ли его использовать в этой ситуации.
ssh-agent используется в сеансе терминала, чтобы кэшировать незашифрованную версию закрытого ключа, что делает ненужным ввод парольную фразу ключа каждый раз, когда она используется. Вы также можете использовать внешний аутентификатор, с помощью которого вы используете запрос / ответ аутентификации, но никогда не имеете доступа к открытому тексту. Пожалуйста, загляните на http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards , чтобы проверить как можно использовать ssh с безопасным аутентификатором.
Если системный администратор уходит и копирует все закрытые ключи ssh, то он имеет доступ ко всем серверам. Как вы справляетесь с этой ситуацией?
Это очень веский аргумент в пользу того, почему закрытые ключи никогда не должны использоваться совместно, и, конечно, почему ключи нескольких пользователей не должны никогда храниться вместе. Просто и понятно, нет никаких причин для этого. Никто другой не имеет никакого отношения к получению вашего закрытого ключа. Тем не менее, даже если бы вы оказались в ситуации, когда кто-то получил в руки кучу активных закрытых ключей, если бы они были должным образом защищены парольной фразой с помощью сильной парольной фразы, это не было бы проблемой.
Опять же, by by Удостоверяя своих пользователей с помощью надежного аутентификатора, имеющего криптографические функции, вы можете полностью избежать этой ситуации. Когда машине необходимо выполнять криптографические функции, а не хранить закрытый ключ в файловой системе, вы можете хранить его в HSM, чтобы предотвратить кражу (кражу) закрытых ключей.
Закрытые ключи SSH-ключей могут быть компонентом многофакторной системы аутентификации, например смарт-картой, или другим типом аппаратного модуля безопасности ( Форм-фактор USB, карта PCIe, fortezza, сетевой HSM и т. Д.). Сейчас это довольно стандартно для предприятий, заботящихся о безопасности, правительств и военных, просто потому, что один компромисс может привести к серьезным последствиям; пароли слишком слабые.
Смарт-карта, в зависимости от ее безопасности, может быть либо (A) непроверенной, либо (B) устройством уровня 2 FIPS 140-2, вплоть до (C) контролируемой криптографической устройство, используемое для сверхсекретной информации SCI и алгоритмов Suite B. В случае (B) уполномоченная правительством лаборатория независимо проверила криптографию, а (C) АНБ провело оценку рассматриваемого устройства. B считается эквивалентом наилучшего коммерческого уровня безопасности, а C считается уровнем безопасности военного / разведывательного сообщества. Цены на крепкие вещи растут!