SSH передать оригинального пользователя в среду на сервере

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

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

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

например, у пользователя John Doe есть учетная запись на central.server, он входит в свою учетную запись jdoe, пользователь jdoe теперь подключается к remote.server.1 и входит в систему как пользователь root с аутентификацией с открытым ключом.

Я хочу регистрировать команды, которые он выдает на remote.server.1, но я хочу сохранить информацию о том, что он на самом деле является jdoe на central.server

Итак, в основном я хочу иметь возможность извлечь журнал из remote.server.1 и посмотреть, какой сотрудник сделал что, когда и где

Я понимаю, что я мог бы просто добавить регистрацию в профиле или bashrc на remote.server.1 и настроить sshd с помощью PermitUserEnvironment, использовать глобальный профиль на central.server и использовать его для передачи имени пользователя в переменной окружения в remote. server.1

Интересно, есть ли лучший способ добиться этого?

Спасибо

Источник

2 ответа

Первое и лучшее решение - просто не разрешать SSH-входы в систему с учетной записью root. Как вы сами убедились, это очень трудно отследить, кто что сделал. Люди, которые должны иметь доступ к серверу, должны использовать свои собственные учетные записи, а затем использовать sudo для выполнения задач, требующих root-доступа. Это текущая лучшая практика для доступа по SSH.

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

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

Кроме того, если вы установите LogLevel в VERBOSE, sshd зарегистрирует отпечаток ключа ssh, используемого для входа в систему. Но если эти журналы не будут перенаправлены на удаленный сервер, к которому эти люди не имеют доступа, они могут быть подделаны и, следовательно, не представляют собой надежный контрольный журнал.

Источник

Невозможно сохранить возможности аудита и позволить пользователям стать пользователем root.

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

От sudoers(5) справочная страница:

 sudoers also supports logging a command's input and output streams.  I/O logging is not on by default but can be enabled using the log_input and log_output Defaults flags as well as the LOG_INPUT and LOG_OUTPUT command tags.

 log_input         If set, sudo will run the command in a pseudo tty and log all user input.  If the standard input is not connected to the user's tty, due to I/O redirection or because the command is part of a pipeline, that input is also captured and
                   stored in a separate log file.  This flag is off by default.

                   Input is logged to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that is included in the normal sudo log line, prefixed with “TSID=”.  The iolog_file option may be used to con‐
                   trol the format of the session ID.

                   Note that user input may contain sensitive information such as passwords (even if they are not echoed to the screen), which will be stored in the log file unencrypted.  In most cases, logging the command output via log_output is all
                   that is required.

 log_output        If set, sudo will run the command in a pseudo tty and log all output that is sent to the screen, similar to the script(1) command.  If the standard output or standard error is not connected to the user's tty, due to I/O redirection or
                   because the command is part of a pipeline, that output is also captured and stored in separate log files.  This flag is off by default.

                   Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that is included in the normal sudo log line, prefixed with “TSID=”.  The iolog_file option may be used to con‐
                   trol the format of the session ID.

                   Output logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.

Кроме того, вы хотите войти sudo использование также:

 sudoers can log both successful and unsuccessful attempts (as well as errors) to syslog(3), a log file, or both.  By default, sudoers will log via syslog(3) but this is changeable via the syslog and logfile Defaults settings.

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

Источник
Другие вопросы по тегам