Какой самый простой способ отследить точное время подключения пользователя по ssh к другой системе
Вы можете (в основном )сделать это со стандартными ACL:
mkdir dir
setfacl -d -m u::rwx,g::rwx,o::rwx dir
chmod 0777 dir
ACL по умолчанию переопределяет umaskпроцесса, создающего файл, и именно это обычно не позволяет процессам создавать всемирные -перезаписываемые файлы. ACL по умолчанию не останавливает процессы, которые явно создают файлы «частные» файлы, доступные только владельцу (, использующему open(filename, flags, 0600)или подобное ), или впоследствии изменяют разрешения.
tmpfs, по-видимому, поддерживает ACL по умолчанию, без каких-либо параметров монтирования, при условии, что CONFIG_TMPFS_POSIX_ACLустановлен в конфигурации ядра.
Если этого недостаточно, вам, возможно, придется настроить некоторый процесс для исправления прав доступа к файлам в каталоге, если они изменены нежелательным для вас образом. Используйте для этого cronили inotifyили подобное.
Очень простой способ — отключить вход в систему с помощью пароля и использовать только вход на основе ключа -.
Таким образом, у вас есть ключ, названный в auth.log, и вы можете просто сопоставить его с пользователем (, например, добавить имя пользователя в поле «комментарий» файла authorized_keys). При входе в систему вы получаете идентификатор процесса, который также отображается при выходе из системы.
$cat /var/log/auth.log
Jun 21 14:42:11 DEV sshd[26510]: Accepted publickey for apple from 1234:5678:90ab:cdef:1234:5678:90ab:cdef port 58888 ssh2: RSA SHA256:abcdefghIJKLMNOPQ/1234567890
Jun 21 14:47:57 DEV sshd[26510]: pam_unix(sshd:session): session closed for user apple
$cat /home/fruit/.ssh/authorized_keys
ssh-rsa abcdefghIJKLMNOPQ/1234567890 apple@bastion
Остальная часть мониторинга зависит от настройки audit.
Это своего рода ужасный ответ (, потому что identdненадежен и легко подделывается и может раскрывать информацию о ваших пользователях, когда они подключаются к другим системам ), но в старые времена люди использовали identdдля такие вещи.
Вы можете запуститьidentdна «бастионе»(с конфигурацией и правилами брандмауэра, чтобы запретить доступ к порту 113 откуда угодно, кроме «DEV» или вашей внутренней сети ).
sshdобычно компилируется с libwrap, а/etc/hosts.allowна DEV можно настроить для регистрации имени пользователя, сообщаемого identd бастиона, с таким правилом, как:
sshd : ALL : spawn = /usr/bin/logger -i --tag "sshd+identd" -p auth.notice "attempted login by %u@%h" &
Это приведет к появлению в журнале строк, подобных приведенным ниже:
Jun 21 14:13:33 DEV sshd+identd[2128678]: attempted login by apple@bastion
, за которым сразу же следуют обычные журналы sshd.
Обратите внимание, что это может привести к задержкам (во время выполнения запроса identdи тайм-ауту )для пользователей, которые входят непосредственно в DEV с других хостов, которые не работают identd(, например. клиентские машины в вашей локальной сети ).
Также обратите внимание, что во время регистрации удаленного имени пользователя это все еще попытка входа в систему , поскольку это происходит, как только соединение установлено, прежде чем sshd аутентифицирует вход с помощью пароля или открытого ключа.
Я не уверен, какие версии identdвсе еще поддерживаются в Centos, но, насколько мне известно, единственная доступная в Debian — это oidentd . Это почти -забытое,устаревшая технология, которую почти никто больше не использует (некоторые сети IRC все еще используют ее, и некоторые клиенты IRC могут дополнительно прослушивать порт 113 и отвечать на запросы identd).