Як я можу підвищити безпеку ssh? Чи можу я вимагати і ключ, і пароль?

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

Одне може вимагати, щоб користувачі обидва надсилали свій ключ і вводили пароль. Це якось важко для google, тому що все, що стосується "пароля ssh key", - це sshing без пароля. :-)

Одна з схем, з якими я завжди хотів іграти, вимагає, щоб вхідні з'єднання надходили лише з білого списку IP-адрес dyndns. Я знаю, що деякі керівники охорони блювотні позиви при думці про ідею, але справа в тому, що це додасть дуже значної складності для використання коробки.

Що ти думаєш? Що ще там?

Логін із паролем та ключем те саме, що "просто з ключем". Під час створення ключа вас попросять ввести парольну фразу. Якщо ви залишите його порожнім, вам не запитають пароль. Якщо ви заповнюєте якусь парольну фразу, вам буде просити її кожного разу, коли ви хочете увійти.

Якщо ви стурбовані безпекою, розгляньте на цьому форумі деякі з цих порад, згадані трильйон разів:

• Вимкнути sh логін для 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.

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

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

Що стосується вашого початкового запитання про необхідність використання ключа та пароля, якщо ви користуєтесь RHEL або CentOS 6.3, це можливо. В примітках до випуску RHEL 6.3 описують його, це справа Додаючи це в sshd_config

RequiredAuthentications2 publickey,password

Я дуже погоджуюся з 3molo. OpenSSH - це сервер SSH за замовчуванням для Linux та Unix. Для нас немає жодних причин змінювати це, особливо для безпеки. VPN має бути найкращим рішенням, яке може зашифрувати наш трафік та надати двоступеневу авторизацію пароля.

Не впевнений, чому його ніхто не згадував, але - ви повинні переконатися, що генерувати ключі довше 1024 біт за замовчуванням, що вже не вважається захищеним.