Во-первых, я не знаю, лучший ли подход - передача информации в среду, поэтому начну с подробного описания того, чего я действительно хочу достичь.
В корпоративном масштабе есть серверы, на которых у ряда сотрудников есть индивидуальные учетные записи оболочки, они используют эти учетные записи для подключения к другим серверам, используя аутентификацию с открытым ключом, входя в систему как root.
то, что я хочу сделать, это уметь определять на удаленных серверах, на которые они входят, какая учетная запись пользователя на сервере, с которого они приходят.
например, пользователь John Doe имеет учетную запись на центральный сервер, он входит в свою учетную запись jdoe, то jdoe пользователь теперь подключается к remote.server.1 и входит как корень с аутентификацией с открытым ключом.
Я хочу регистрировать команды, которые он выполняет remote.server.1, но я хочу сохранить информацию, что он на самом деле jdoe на центральный сервер
Итак, в основном я хочу иметь возможность извлекать журнал из remote.server.1 и посмотреть, какой сотрудник что делал, когда и где
Я понимаю, что могу просто добавить логин в профиль или bashrc на remote.server.1 и настроить sshd с помощью PermitUserEnvironment, используйте глобальный профиль на центральный сервер и используйте это, чтобы передать имя пользователя в переменной среды в remote.server.1
Интересно, есть ли лучший способ добиться этого?
Спасибо
Невозможно одновременно сохранить возможности аудита и позволить пользователям стать пользователем 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.
В заключение, вам необходимо убедиться, что доступ, предоставленный вашим пользователям, не дает слишком широких разрешений, чтобы позволить им переопределить систему аудита.
Первое и лучшее решение - просто запретить вход по SSH в учетную запись root. Как вы сами убедились, отследить, кто что сделал, очень сложно. Люди, которые должны иметь доступ к серверу, должны использовать свои собственные учетные записи, а затем использовать sudo для выполнения задач, требующих root-доступа. Это лучшая практика для доступа по SSH.
Вы также можете настроить ведение журнала аудита на центральном сервере, с которого пользователи выполняют свою работу по SSH. Вы можете использовать auditctl только для регистрации команд ssh. (Однако включение аудита в некоторой степени замедлит работу сервера; вам нужно будет провести некоторые оценки производительности, чтобы определить, работает ли он для вас.)
Вы также можете добавить информацию в публичную часть ключа SSH на целевых серверах - см. этот вопрос для некоторых советов по этому поводу. Однако, поскольку у пользователей есть root, им будет легко изменить эти данные, поэтому их нельзя использовать для серьезного аудита.
Кроме того, если вы установите LogLevel к VERBOSE, sshd зарегистрирует отпечаток ключа ssh, который использовался для входа в систему. Но если эти журналы не пересылаются на удаленный сервер, к которому у этих людей нет доступа, они могут быть изменены и, таким образом, не будут представлять собой надежный контрольный журнал.