Вопросы Теги

Ограничение SSHd на пользовательское основание

В то время как да, это заняло бы время для обновления, И в том же поместье, это заняло бы время, чтобы восстановить, если бы что-то пошло не так, как надо, Каким количеством боли/страдания это было бы, если бы данные по той системе были удалены посредством использования / взлом?

По большей части обновления из репозиториев основы CentOS безопасно установить, единственное время, у меня были проблемы обновления с CentOS, - когда я запускаю / или должен был использовать внешний репозиторий (DAG, RPMForge, ect Ect..)

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

8
задан 4 March 2010 в 23:40
4 ответа

То, что я сделал бы, должно установить /etc/sshd/sshd_config таким образом, что:

PermitRootLogin without-password

только для дополнительной безопасности и постараться не блокировать пароль root (это только позволило бы корню входить в систему с помощью ключа),

Я вместо этого использовал бы AllowGroups вместо AllowUser, что касается меня было бы более удобно добавить пользователей к группе, а не к sshd_config но это могло зависеть от Ваших персональных предпочтений.

1
ответ дан 2 December 2019 в 22:52

Настроенный ssh следующим образом:

nano /etc/ssh/sshd_config

AllowUsers username1 username2 username3

Перезапуск SSH

Затем предоставьте ключи тем, которые требуется избегать использования паролей.

ssh-keygen используется для генерации той пары ключей для Вас. Вот сессия, где Ваша собственная персональная частная/с открытым ключом пара создается:

#ssh-keygen -t rsa

Команда ssh-keygen-t rsa инициировала создание пары ключей.

Я не ввел пароль для своей установки (клавиша Enter была нажата вместо этого).

Закрытый ключ был сохранен в .ssh/id_rsa. Этот файл только для чтения и только для Вас. Никто больше не должен видеть содержание того файла, поскольку это используется для дешифрования всей корреспонденции, зашифрованной с открытым ключом.

Открытый ключ является сохранением в .ssh/id_rsa.pub.

Его содержание затем копируется в файле .ssh/authorized_keys системы, к которой Вы желаете к SSH, не будучи предложенным пароль. 

#scp id_rsa.pub remote system:~/.ssh/authorized_keys

Наконец заблокируйте учетную запись (Ключевая аутентификация все еще будет возможна.)

# passwd -l username1
2
ответ дан 2 December 2019 в 22:52
  • 1
    that' s не, что i' m поиск. let' s говорят, что я хочу, чтобы корень был зарегистрирован с помощью ключей только, и другие пользователи могут быть зарегистрированы с ключом или паролем –  alexus 4 March 2010 в 23:39
  • 2
    затем don' t блокируют учетную запись с passwd-l username1 –  Patrick R 5 March 2010 в 02:24

Я думаю, что Вы хотите, "Пользователь Соответствия". Вы используете его для соответствия имени пользователя, затем располагаете ряд с отступом настроек конфигурации, которые применяются конкретно к тому пользователю.

Match User Joe
  PasswordAuthentication no

Match User Jane
  PasswordAuthentication yes

Я использую это для установки chroot доступа только для SFTP иногда для клиентов.

11
ответ дан 2 December 2019 в 22:52

Все вышеперечисленное прекрасно и работает, и, если позволите, немного подвяжу. Я использую стандартный sshd_config для большого количества серверов и разновидностей, что делает настройку преднамеренным мыслительным процессом, и это то, что я использую.

Мой вариант использования:

  • Корневой доступ ограничен ключом только с 2 определенных IP-адресов
  • Пользователи автоматизации (например, ansible) ограничены ключом только с определенных серверов (например, RunDeck, Jenkins и т. д.)
  • Приложение пользователи могут вообще не входить в систему с помощью ssh
  • Администраторы и пользователи могут использовать ключ или пароль

Во-первых, я в основном использую Allow_Groups, так проще управлять несколькими ящиками с множеством разных пользователей. Для пользователей, общих для всех ящиков (например, автоматизация или мониторинг), allow_Users также хорошо работает, но я все же предпочитаю использовать группы.

Теперь перейдем к фактическим конфигурациям /etc/ssh/sshd_config:

Во-первых, доступ SSH только к определенной группе (или пользователям):

AllowGroups sshusr

По сути, это означает, что пользователи должны быть член группы sshusr, чтобы иметь возможность использовать SSH. Чтобы пользователи приложений не могли получить доступ по ssh, просто убедитесь, что они не являются членами группы sshusr.ПРИМЕЧАНИЕ. Сюда входит root, поэтому вам нужно добавить root в группу sshusr!

Для корневого доступа используйте только ключ:

PermitRootLogin without-password

Для ограничения групп на использование аутентификации только с ключом:

Match Group ansible,monitor
  PasswordAuthentication no

По умолчанию я отключаю такие вещи, как переадресация портов и переадресация X11 и т. д., но для определенных групп вы можете включить его и разрешить аутентификацию по паролю (обычно вкл по умолчанию, но для безопасных сред вы можете отключить выкл для создания ключей по умолчанию)

Match Group sysadmin,dbadmin
  PasswordAuthentication yes
  AllowTcpForwarding yes
  PermitTunnel yes
  X11Forwarding yes

Тогда у вас есть особые случаи, такие как sftp только пользователи:

Match Group sftp
  ForceCommand internal-sftp
  PermitTTY no
  MaxSessions 5

Теперь для ограничения ключей, чтобы разрешить доступ только с определенных IP-адресов. Это работает и для полных доменных имен, но я не использовал его здесь. В файле ~/.ssh/authorized_keys добавьте ограничение from= к применимому ключу(ам)

from="10.1.1.1,10.2.2.2,10.3.3.0/24" ssh-rsa AAAAB3NTheRestOfMyKeyxyz

. Это позволит использовать ключ только с этих конкретных IP-адресов.

Надеюсь, это поможет вам и, возможно, многим другим.

0
ответ дан 1 September 2021 в 12:57

Теги

Похожие вопросы