Назад | Перейти на главную страницу

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

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

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

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

Что вы думаете? Что еще есть?

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

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

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

И т. Д. И т. Д.

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

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

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

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

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

Наконец, хотя для него не существует модуля, если вы переместили аутентификацию с открытым ключом в 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 бит по умолчанию, что больше не считается безопасным.