Отключить удаленный вход в систему, но разрешить su для того же пользователя
Моя компания стремится защитить наши серверы Ubuntu 14.04 LTS, и мы хотели запретить отдельным пользователям возможность удаленного входа, но все же позволяли людям переходить на эту учетную запись пользователя с помощью SU, если это необходимо для поддержки. Я нашел ответ на запрет входа в SSH здесь:
Как отключить удаленный вход в SSH как root с сервера?
Не помешает ли использование SU для перехода на пользователь, которому запрещен удаленный вход в SSH?
Конкретный пример: мы не хотим, чтобы люди входили через SSH, используя учетную запись «specadmin», но пользователю «mary» может потребоваться войти в систему, а SU - «specadmin» для Возможно ли выполнить несколько специальных функций поддержки через соединение SSH (хотя я уверен, что это не лучшая модель). У нас нет локального доступа к серверам, потому что они размещены в облаке.
2 ответа
Нет, отключая доступ SSH в sshd_config файл не будет влиять на способность войти в систему локально или с помощью su команда.
Хотя можно ограничить учетные записи, позволенные соединяться с SSH, как описано в ответе, на который ссылаются (т.е. путем установки также DenyUsers specadmin или AllowUsers mary в /etc/ssh/sshd_config файл), это все еще было бы менее безопасно, чем, что считают обычной практикой для SSH.
Вы не должны идти тем путем и вместо этого переключаться на основанную на ключе аутентификацию.
При конфигурировании его впервые это могло бы казаться громоздким, но поскольку Вы используете облачные сервисы, можно легко добавить новый сервер и выполнить тестовые прогоны (btw, облачные сервисы обычно дают Вам веб-доступ к консоли при блокировании себя).
Сначала необходимо установить (или удостовериться, что следующие опции установлены в sshd_config):
PubkeyAuthentication yes
Затем необходимо генерировать пару ключей на клиентской машине (ssh-keygen команда на машинах Linux), и добавляют открытый ключ к следующему файлу (для mary):
/home/mary/.ssh/authorized_keys
любой путем копирования вручную (ключ является строкой символов), или использование ssh-copy-id mary@<destination_server> команда, которая загрузит ключ автоматически.
Необходимо смочь соединиться с использованием сервера ssh mary@<destination_server> использование ключа. Если Вы устанавливаете пароль во время ssh-keygen, который Вы должны, Вы должными быть ввести его, но это не будет передано между клиентом и сервером. Чтобы быть действительно уверенными, Вы делаете, вещи правильно устанавливают пароль на файл ключей, отличающийся от пароля на целевом сервере.
Если можно успешно войти в использование ключевой аутентификации (и пароль), можно продолжить двигаться к отключению пароля, базирующегося один путем добавления/обеспечения следующих настроек в sshd_config:
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
IgnoreRhosts yes
IgnoreUserKnownHosts yes
HostbasedAuthentication no
После изменений в sshd_config необходимо, конечно, перезапустить демона SSH (sudo service ssh restart) на сервере.
Для душевного спокойствия Вы могли бы также хотеть запретить доступ через SSH для корневой учетной записи в sshd_config (хотя при выполнении вышеупомянутого корень не сможет войти в систему по умолчанию):
PermitRootLogin no
Это - точный вариант использования для DenyUsers и AllowUsers строки в файле /etc/ssh/sshd_config. Можно войти в систему как разрешенный пользователь и su привилегированному пользователю при необходимости.
кроме того, если Вы хотите увеличить свои меры безопасности, необходимо изучить использование защищенной основанной на сертификате аутентификации пароля для входа в систему как обычные пользователи (такие как Mary). Это довольно просто настроить и добавляет дополнительный уровень безопасности к Вашей системе.