Как я могу повысить безопасность SSH? Могу ли я потребовать ключ и пароль?

У меня небольшая сеть серверов, и я хотел бы повысить общую безопасность. У меня недостаточно времени / денег / паранойи для настройки VPN - как можно повысить безопасность моей системы?

Одной из причин может быть требование, чтобы пользователи отправляли свой ключ и вводили пароль. Это довольно сложно для Google, потому что все, что касается "ssh key password" - это sshing без пароля. :-)

Одна схема, с которой я всегда хотел поиграть, - требовать, чтобы входящие соединения исходили только из белого списка IP-адресов dyndns. Я знаю, что некоторые руководители службы безопасности рвались бы при мысли об этой идее, но в том-то и дело, что это значительно усложнит использование коробки.

Как вы думаете? Что еще там?

Логин с паролем и ключом такой же, как «просто с ключом». Во время создания ключа вам предлагается ввести кодовую фразу. Если вы оставите это поле пустым, пароль не будет запрашиваться. Если вы введете какую-нибудь фразу-пароль, вас будут спрашивать каждый раз, когда вы захотите войти в систему.

Если вы беспокоитесь о безопасности, рассмотрите некоторые из этих советов, упомянутых триллион раз на этом форуме:

• Отключить логин ssh для пользователя root
• Разрешить доступ по SSH только с определенных IP-адресов (iptables, hosts.allow, ...)
• Переместить порт ssh на другой порт (больше неясности, чем безопасности, но это работает)
• Отслеживайте попытки входа в систему за рубежом и реагируйте соответственно
• Поддерживайте свою систему в актуальном состоянии

И т. Д.

Обновление: пожалуйста, обратитесь к ответу здесь, чтобы узнать, как запрашивать открытый ключ и пароль локальной системы для сервера OpenSSH.

Одна идея, которая показалась мне интересной, - это стук портов - в основном, чтобы установить ssh-соединение, сначала нужно проверить последовательность других портов, прежде чем ssh-сервер подтвердит запрос на соединение. Если правильная последовательность портов не используется, ответ отсутствует, поэтому он выглядит так, будто сервер ssh не запущен. Последовательность портов настраивается и может использоваться совместно с вашими пользователями; все остальные фактически не смогут подключиться.

Я не пробовал это сам, но из того, что я слышал (что не так много, на самом деле), издержки незначительны, и это сильно снижает ваш профиль видимости.

Патчи, связанные с включением непосредственно в SSH, и множество актуальных обсуждений:

• https://bugzilla.mindrot.org/show_bug.cgi?id=983

Это также можно сделать без изменений, используя скрипт проверки пароля в сочетании с использованием параметра ForceCommandконфигурации.

• http://www.tuxz.net/blog/archives/2010/03/17/how_to_quickly_setup_two-factor_ssh_authentication/

Наконец, хотя для него не существует модуля, если вы переместили аутентификацию с открытым ключом в PAM, то вам потребуется выполнить оба шага, прежде чем PAM сочтет аутентификацию успешной.

Просто используйте

RequiredAuthentications publickey, password

в , sshd_configесли вы используете SSHd от ssh.com. Эта функция недоступна в OpenSSH.

Вы также можете использовать одноразовые пароли для повышения безопасности. Это позволит пользователям входить в систему с небезопасного терминала, который может иметь кейлоггер, если они ранее сгенерировали следующий пароль. Также есть генераторы паролей, которые можно установить даже на старые телефоны Java MIDP, которые вы всегда носите с собой.

Я бы порекомендовал вам никогда не запускать sshd, rdp или подобные сервисы управления без ограничения IP. На самом деле, я бы предложил ограничить доступ к таким сервисам администраторам, подключающимся через VPN.

Что касается вашего первоначального вопроса о требовании и ключа, и пароля, если вы используете RHEL или CentOS 6.3, это теперь возможно. В примечаниях к выпуску RHEL 6.3 описывают его, это дело Добавляя это в sshd_config

RequiredAuthentications2 publickey,password

Я полностью согласен с 3моло. OpenSSH является SSH-сервером по умолчанию для Linux и Unix. У нас нет причин менять это, особенно в целях безопасности. VPN должно быть лучшим решением, которое может зашифровать наш трафик и обеспечить двухэтапную авторизацию пароля.

Не знаю, почему никто не упомянул об этом, но вы должны убедиться, что вы генерируете ключи длиннее 1024 бит по умолчанию, которые больше не считаются безопасными