Моя компания требует, чтобы любое время, пользователь входит в рабочий сервер причина, что человек вошел в систему и изменения пользователь, намеревалось сделать, должен быть зарегистрирован. Моя команда хочет сделать это, но его легкое для упущения. Я хотел бы помочь им помнить. Я рассмотрел motd, но хотят что-то немного более сильное.
Моя первая мысль состояла в том, чтобы изменить оболочку пользователя на сценарий, который делает что-то как
vim /logs/logindate.txt
bash -l
Существует ли лучшая или более стандартная техника?
Примечание: Идея состоит в том, что эти пользователи являются системными администраторами и хотели бы сделать запись в журнале, не ниспровергая систему - они просто часто забывают делать так. Так, если они могут ctrl-c это, хорошо... мы предполагаем, что они не будут.
Посмотрите на pam_exec.so. Вы можете запустить скрипт при входе в систему в интерфейсе сеанса PAM-auth. Скрипт выполняется как root до того, как пользователь получит оболочку, так что он может не захватить вход с помощью read
? Однако, вы можете попробовать и использовать read
, чтобы получить от пользователя причину и записать его в syslog с оператором loger
. (Я опустил ниже, но вы можете поймать CTRL+C в ловушку, чтобы никто не выходил без причины). $PAM_USER будет установлен для человека, входящего в систему, так что вы можете включить это в утверждение логгера.
Пример:
В верхней части сессии в /etc/pam.d/system-auth:
session required pam_exec.so /usr/local/sbin/getreason
И /usr/local/sbin/getreason:
#!/bin/bash
read -p "Reason for logging into production: " reason
logger -t $(basename $0) "$PAM_USER logged in with reason: ${reason}"
Приносим извинения, если это не работает идеально. Я не тестировал, но недавно сделал нечто подобное. (Он не захватил вход.)
Edit: Чем больше я думаю об этом, тем больше я не думаю, что он будет работать из-за стадии, на которой он работает. Тот же самый скрипт getreason
должен работать после того, как вы замените $PAM_USER
на $(logname)
, но может потребоваться его выполнение в /etc/profile
. (Сначала проверьте интерактивную оболочку.)
Я оставлю обе опции включенными, так как это, по крайней мере, заставит вас думать в правильном направлении, если больше ничего не нужно.
.Альтернативой является решение по управлению привилегированными учетными записями, где вместо того, чтобы предоставлять администраторам доступ со своей учетной записи, учетные записи администраторов хранятся на условном депонировании третьей стороной, а обязательные процедуры должны быть выполнены до того, как администраторы получат доступ к производственным системам http://en.m.wikipedia.org/wiki/Privileged_Identity_Management
Другим способом достичь этого было бы использование вашей системы централизованного ведения журналов (я думаю, Logstash, но вы можете сделать это другими способами), взять ваш auth.log в производственных системах, скормить его в приложение, где люди могут заносить в журнал свои оправдания.
.Я видел, как это реализовано у клиентов, которые запускают HP Server Automation*, это то, что они полагаются на врожденный журнал инструмента с комбинацией шагов одобрения (я был у нескольких клиентов, где нет sudo или root privs, кроме как в Dev).
Утверждения могут быть сделаны через что-то вроде Remedy and Operations Orchestration, или административный логин внутри SA, и т.д.
Все это, вне средств автоматизации и управления предприятием, @Ответ Аарона Копли является отличным выбором.
* Я старший консультант HPSA, HPOO, и других аспектов пакета автоматизации HP
.В поисках решения я прочитал ответ и мысль Аарона Копли: "Что если я изменю оболочку моего пользователя?"
Я сделал это успешно на моей машине Ubuntu 14.04:
# usermod -s /usr/bin/loginScript username
На вашем скрипте вы можете просто перехватить причину входа в систему. Мой так:
#!/bin/bash
read -p "Tell me why you logged in:" reason
echo "You told me: $reason" >> /var/log/reasonLogin.log
/bin/bash
Одна вещь, которую вы должны отметить: скрипт не запускается как root, так что вы, возможно, придется дать пользователю некоторые разрешения, чтобы сделать это.
.