Дозволити лише конкретним користувачам входити через ssh на одному порту, а іншим - через інший порт

У мене є такий випадок використання:

• Потрібно дозволити користувачам увійти з захищеної надійної мережі
• а потім дозволити парам (лише двом) мобільним користувачам дистанційно входити в систему на машині Linux Centos.

Я можу зробити sshd працювати на різних портах, наприклад:

• зсередини це добре, щоб він працював на 22, оскільки я не хочу змушувати їх з'єднуватися на інших портах (псує сценарій).
• Для зовнішніх мобільних користувачів я запускатиму sshd на інший порт, скажімо, порт X (підвищена безпека - це невеликий офісний тип налаштування).

Для додаткової безпеки я сподівався налаштувати sshd, щоб дозволити доступ лише певним користувачам на порту X (а потім налаштувати деякі сповіщення, щоб ми могли знати, коли користувачі входять через порт X).

Однак я не можу знайти подібну конфігурацію в документації на sshd. Якщо такого рішення немає, чи можна принаймні запускати скрипт оболонки для запуску кожного разу, коли хтось завершує вхід в sshd на порт X? Я переглядав документацію на iptables, щоб перевірити, чи може вона викликати попередження, коли вхід в sshd є, але нічого не можу придумати.

Вкладені оцінки

Запуск SSHна альтернативному порту вже не вважається безпекою. Це лише додає трохи неясності та додаткового кроку складності для ваших користувачів. Це додає нульових перешкод для людей, які хочуть зламати вашу мережу, хто використовує автоматизовані сканери портів і не байдуже, який порт працює.

Якщо ви хочете підвищити безпеку в системі, яка дозволяє віддаленому sshd_configвхідному SSH на базі Інтернету, керуйте своїми користувачами як зазначено в @Anthon, а також впроваджуйте безпеку безпосередньо в PAM.

Створіть дві групи lusersта rusers. Додайте користувачів до віддалених мобільних користувачів rusers. Використовуйте PAM модуль pam_succeed_if.so, щоб дозволити доступ до цих користувачів. Додайте рядки до своєї конфігурації пам’яті для ssh:

account     sufficient  pam_succeed_if.so user ingroup lusers
account     sufficient  pam_succeed_if.so user ingroup rusers

Деякі модулі pam_succeed_if.so можуть вимагати використання трохи іншого синтаксису, наприклад group = lusers.

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

Ще одним кроком для віддалених користувачів є змусити використовувати ssh_keys з парольними фразами. Так, місцеві користувачі можуть увійти за допомогою ключів або паролів, але віддалені користувачі повинні мати ключ, і якщо ви створите для них ключі, ви можете переконатися, що в ключі є приєднані паролі фрази. Таким чином, обмежуючи доступ до місць, у яких фактично є ключ SSH та парольна фраза. А також обмеження потенційних векторів атаки, якщо пароль користувача дотримується.

В sshd_config:

змінити 2 налаштування:

ChallengeResponseAuthentication yes

і

PasswordAuthentication yes

до:

ChallengeResponseAuthentication no

і

PasswordAuthentication no

Отже, за замовчуванням тепер дозволяється лише автентифікація ключа. Тоді для місцевих користувачів ви можете скористатися matchналаштуваннями конфігурації, щоб змінити типовий для місцевих користувачів. Припустимо, що ваша локальна приватна мережа - 192.168.1.0/24, додайте до sshd_config:

Match Address 192.168.1.0/24
PasswordAuthentication yes

Тепер місцеві користувачі можуть з'єднуватися з паролями чи ключами, а віддалені користувачі змушені будуть використовувати ключі. Вам належить створити ключі з фразовими фразами.

В якості додаткової переваги вам потрібно керувати лише одним sshd_config, і вам потрібно запустити ssh лише на одному порту, що полегшує ваше власне управління.

редагувати 2017-01-21 - Обмеження використання authorized_keysфайлів.

Якщо ви хочете переконатися, що користувачі не можуть просто генерувати ключ ssh та використовувати його з authorized_keysфайлом для входу, ви можете контролювати, встановивши певне місце для sshd, шукати авторизовані ключі.

У /etc/ssh/sshd_configзміні:

AuthorizedKeysFile  %h/ssh/authorized_keys

до чогось типу:

AuthorizedKeysFile  /etc/.ssh/authorized_keys/%u

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

Ви можете додати щось подібне до свого /etc/ssh/sshd_config:

AllowUsers mobileuser1 mobileuser2 *@10.0.0.0/8

Вищезгадане передбачає, що дозволені віддалені користувачі названі mobileuser1та mobileuser2, і що ваша довірена мережа має 10.0.0.0 з маскою підмережі 255.0.0.0.

Це дозволяє двом мобільним користувачам входити з будь-якого місця, а кожен входити з надійної мережі. Будь-якому користувачеві, який не відповідає жодному з цих шаблонів (наприклад, fooвхід з віддаленого користувача), буде відмовлено у доступі.

Ви можете зробити це, запустивши два ssh-демон і два sshd_configфайли. Скопіюйте існуючий (наприклад, із /etc/ssh/sshd_config /etc/ssh/sshd_alt_configальтернативної настройки конфігурації та зі manсторінки для sshd_config:

Порт

Specifies the port number that sshd(8) listens on.  The default
is 22.  Multiple options of this type are permitted.  See also
ListenAddress

Дозволитикористувачі

This keyword can be followed by a list of user name patterns,
separated by spaces.  If specified, login is allowed only for
user names that match one of the patterns.  Only user names are
valid; a numerical user ID is not recognized.  By default, login
is allowed for all users.  If the pattern takes the form
USER@HOST then USER and HOST are separately checked, restricting
logins to particular users from particular hosts.  The
allow/deny directives are processed in the following order:
DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.

Ви, ймовірно, хочете мати альтернативний журнал ssh для іншого файлу, і, наприклад, дотримуйтесь того, що записано в цей файл, щоб помітити невдалі спроби входу.