Разрешение только определенным пользователям входить через ssh через один порт, а другим - через другой порт

У меня есть следующий вариант использования:

• Необходимо разрешить пользователям входить из защищенной доверенной сети.
• и затем разрешить паре (только двум) мобильным пользователям удаленно войти в систему на компьютере Linux Centos.

Я могу заставить sshd работать на разных портах, например:

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

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

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

Входы оценены

Работа SSHна альтернативном порту больше не считается безопасностью. Это лишь добавляет немного неясности и добавляет сложности вашим пользователям. Это добавляет ноль препятствий для людей, которые хотят сломать вашу сеть, которые используют автоматические сканеры портов и не заботятся о том, на каком порту он работает.

Если вы хотите повысить безопасность в системе, которая разрешает удаленный входящий в систему SSH через Интернет, управляйте своими пользователями в соответствии sshd_configс указанным @Anthon, а затем также реализуйте защиту непосредственно в PAM.

Создайте две группы lusersи rusers. Добавьте удаленных мобильных пользователей в rusersгруппу. Используйте модуль PAM pam_succeed_if.so, чтобы разрешить доступ этим пользователям. Добавьте строки в ваш pam config для 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 на одном порту, что упрощает ваше собственное управление.

edit 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

AllowUsers

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