Назад | Перейти на главную страницу

Настройка сервера компании - безопасность и ssh

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

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

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

В настоящее время я сталкиваюсь с тем, как безопасно настроить SSH. Моя текущая настройка совсем небезопасна, работает на порту по умолчанию, с системными паролями в виде обычного текста, даже для пользователей root, моя учетная запись - единственная, у которой есть pubkey.

То, что я хочу настроить на сервере, - это более высокая мера безопасности, поскольку всем пользователям потребуется ключ публикации для подключения, однако я хочу, чтобы все ключи публикации имели связанную с ними парольную фразу, чтобы в случае, если ключ становится скомпрометированным, если они решат перенести его на несколько систем, перед заменой ключа все равно останется тонкая линия защиты.

Есть ли способ принудительно использовать зашифрованный ключ безопасности с парольной фразой в ключах RSA? Будет ли плохой практикой генерировать публичные / закрытые ключи на сервере и распространять их среди моих сотрудников? Что было бы здесь лучшим средством безопасности?

Я собираюсь настроить разрешения, чтобы у каждого пользователя был только ограниченный доступ к серверу, однако я все же хотел бы сохранить все это как можно более безопасным, поскольку являясь компанией-разработчиком программного обеспечения, скомпрометированный ключ pub может привести к несанкционированному доступу наших репозиториев git и всего, что помогает нам в бизнесе. Или я просто параноик?

Мы очень ценим любые предложения.

Вы можете посмотреть на различные формы двухфакторной аутентификации.

Я бегло посмотрел на Google Authenticator, и я купил yubikey много лет назад, но так и не дошел до того, чтобы попробовать его дальше, поэтому не могу предложить вам никакого практического опыта с любым из них.

Вы не можете заставить SSH-ключ иметь пароль. Независимо от того, генерируете ли вы ключ от имени пользователя или пользователь сам генерирует ключ, вам так или иначе придется передать ключ в руки пользователя ... и они также должны будут знать парольную фразу, чтобы уметь его использовать. Если у них есть ключ и кодовая фраза, они могут удалить парольную фразу, если захотят.

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

1) Настройте его так, чтобы вам потребовались оба пароль И закрытый ключ для входа в систему, так как вы не можете принудительно привязать кодовую фразу к закрытому ключу.

Как настроить ssh с закрытым ключом и паролем?

2) Использование двухфакторная аутентификация. Есть несколько вариантов 2 фактора. Вы могли бы использовать Юбикей, или используйте аутентификация google. Я уверен, что есть и другие, но те, которые я пробовал раньше, работают хорошо.

Наконец, все безопасные ssh-серверы, которые открыты для мира и специально не настроены для разрешения только известных IP-адресов, должны иметь что-то вроде fail2ban установлены. Это гарантирует, что неправильный вход в систему будет заблокирован (заблокирован), что еще больше повысит безопасность. Он довольно гибок в отношении количества неудачных попыток входа в систему, и вы все равно можете добавить свой IP-адрес из белого списка (или IP-адреса, которые нужно игнорировать).

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