Двухфакторная аутентификация
Порядок важен - перемещают Ваше vhost определение для всего остального к заголовку списка.
Фильтрация IP брандмауэра - у Кого-то должен быть определенный IP / Пароль SSH.
В Чем-то, что кто-то ИМЕЕТ, подразумевает "владение", не "требует". Это обычно относится к аппаратному ключу - как брелок SecurID от RSA или Yubikey. В частности, это подразумевает что-то, что уникально и может только находиться в собственности одним человеком за один раз. ssh пароль абсолютно не квалифицирует, так как пароль может быть поставлен под угрозу различными способами (trojaned ssh демон, клавиатурный перехватчик, визуальное наблюдение, и т.д.). Двухфакторная аутентификация обычно помещается на месте для контакта с очень настоящими проблемами, которые влияют на основанную на пароле аутентификацию.
IP-адреса не хороши для аутентификации потому что (a) их довольно легко фальсифицировать и (b) для нескольких человек возможно соединиться от того же IP-адреса. В частности, если люди соединяются с их дома на маршрутизатор, то Вы полагаетесь на безопасность их сети (действительно ли это - открытая сеть Wi-Fi? Они совместно используют со своими соседями?).
Закрытый ключ SSH (Пользователь PER) / Пароль пользователя SSH
Это Ваш "что-то, что кто-то знает". Ключи SSH предпочтительны для паролей, так как это уменьшает возможности чьего-то пароля, восстанавливаемого trojaned ssh сервер. Это действительно требует, чтобы Ваши пользователи поняли, как заботиться об их закрытых ключах (удостоверьтесь, что они всегда имеют пароль, никогда не размещают их в совместно используемую память, и т.д.).
Аутентификация телефона/SMS динамического маркера, который отправляется в число человека
Это - типичная замена выделить аппаратного ключа (предположение - то, что способность получить SMS-сообщение к данному числу требует, чтобы Вы обладали соответствующим мобильным телефоном). Google использует это для их двухфакторной аутентификации, например, и существует много продуктов там, которые позволят Вам прокрутить это самим.
Таким образом:
Ключи SSH + аппаратный ключ или аутентификация SMS являются хорошим и довольно общим решением. Пароли вместо ssh ключей также распространены, но мне нравится защищать против них, потому что пароли подвержены многим проблемам.
Я думаю, что ответ здесь "это зависит". SMS - это очень слабая система во многих отношениях. Я расскажу о некоторых из них здесь: http://www.wikidsystems.com/WiKIDBlog/fraudsters-defeat-poor-risk-management-not-two-factor-authentication . Здесь есть пара рисков. Во-первых, SMS - это настолько популярный механизм безопасности, что злоумышленник атакует службу SMS и наносит серьезный ущерб, в том числе и вам. Во-вторых, ваше приложение достаточно заманчиво, чтобы быть нацеленным на само себя, как в примере в моем сообщении.
IP-адреса легко подделать, так что это не добавляет безопасности, но, как и при изменении номера порта для SSH, вы можете уменьшить данные журнала.
Кроме того, вам понадобится специальный модуль PAM, чтобы это ? Я не знаком с модулем pam, который будет проверять ключи и OTP. Ключи обычно обрабатываются SSH, а пароли - PAM.
HTH,