Скроллинг назад под screen у меня абсолютно нормальный (Shift+PgUp), не считая возврата к предыдущему состоянию, когда минуты в caption внизу страницы меняют своё значение. А вот обычный скроллинг страниц, к примеру man bash — притормаживает. Другие претензии к screen в плане удобства, которые у меня были вначале — отсутствие «пикания» и автозавершения команд — исправлены и рецепт приведёт в статье.
Я старался не проводить в статье обзор методов аудита в Linux. Это статья для тех, кто как я, решит остановиться на этом методе из обзорной статьи про script, screen, sudo, auditd.
Вариант с подключением на уровне системы к ttyX думаю лучше, но я с ним не знаком и их не было в статье, на основании которой был выбран метод (см.выше).
Спасибо за информацию.
Скрипт чуть модифицирован (не работали команды типа ssh user@server «ls -al /; sleep 5; echo Works», а также изменён метод записи в лог-файл — теперь это простое echo >>) и внесён в статью.
Думаю для таких вариантов нужно более серьёзные решения (auditd, к примеру), но там непросто читать лог-информацию.
К примеру на команду “hostname audit-test.home.private”
Спасибо за информацию. Считаю это не совсем нужным действием — отвечать нужно ли подключать, ведь для того, чтобы отключиться от screen и оставить работать процессы в фоне — надо проделать «телодвижения», соответственно зачем их проделывать, если потом отвечать «не подключать screen». А если просто выйти (^d или exit), то и screen убивается.
Я проверил и удалённо, и локально — логируется. С другой машины ввёл:
ssh root@server -t /bin/bash -l
root@server's password:
root@server:~# this is a test message
bash: this: command not found
Выхожу, смотрю логи:
root@server:~# cat /var/log/screen/root@server-20130716-\ 9\:32\:04.log
root@server:~#
root@server:~# this is a test message
bash: this: command not found
root@server:~# ogout
Как вариант есть возможность в ~/.ssh/authorized_keys сделать:
command="/bin/bash". Вижу сразу 2 нюанса:
1) Необходимо добавлять этот файл каждому пользователю
2) Авторизацию придётся запрещать по логину — только по ключу.
А где ещё быть утилитам screen и kill и, главное, зачем?
Для меня это имеет смысл, когда приходится одни и те же скрипты запускать на Linux и OpenWRT. У них пути разные и which очень помогает.
P.S. Кстати изменения в текст статьи внёс — путь указал точно.
Я старался не проводить в статье обзор методов аудита в Linux. Это статья для тех, кто как я, решит остановиться на этом методе из обзорной статьи про script, screen, sudo, auditd.
Вариант с подключением на уровне системы к ttyX думаю лучше, но я с ним не знаком и их не было в статье, на основании которой был выбран метод (см.выше).
Скрипт чуть модифицирован (не работали команды типа ssh user@server «ls -al /; sleep 5; echo Works», а также изменён метод записи в лог-файл — теперь это простое echo >>) и внесён в статью.
К примеру на команду
“hostname audit-test.home.private”В логе окажется:
type=SYSCALL msg=audit(1358306046.744:260): arch=c000003e syscall=170 success=yes exit=0 a0=2025010 a1=17 a2=7 a3=18 items=0 ppid=23922 pid=26742 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=16 comm="hostname" exe="/usr/bin/hostname" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="system-locale"Выхожу, смотрю логи:
command="/bin/bash". Вижу сразу 2 нюанса:
1) Необходимо добавлять этот файл каждому пользователю
2) Авторизацию придётся запрещать по логину — только по ключу.
Для меня это имеет смысл, когда приходится одни и те же скрипты запускать на Linux и OpenWRT. У них пути разные и which очень помогает.
P.S. Кстати изменения в текст статьи внёс — путь указал точно.
Есть идеи?