Linux log ssh commands

How to Enable SSH Log and List Failed Login in Linux

As we know SSH protocol provide remote login facility and hence it is important to maintain the login logs. System admin can achieve this by configuring in syslogd services.

In Linux, syslogd is the unix logging service that maintains the logs that are sent by the programs to the syslog daemon, syslogd forwards them to another destination such as a console or a file. Destination is specified in the syslog configuration file /etc/syslog.conf.

In this tutorial we will learn how to enable ssh log and check Linux command to list failed ssh login attempts.

Enable syslog Logging

Lets first check config file whether ssh logging enabled or not, use the following command:

By default, ssh logging is enabled, if not enable then enable SSH logging we need to configure the syslog.conf by adding in /etc/syslog.conf file.

When SSH server runs, it will produce the log messages in sshd.log to describe what is going on. These log messages will help the system administrator to track the system details such as who logged in and logged out and to troubleshoot the problem.

The /etc/ssh/sshd_config file is a system-wide configuration file for open SSH service which allows you to set options that modify the operation of the daemon. This configuration file contains keyword-value pairs and one per line with keywords being case sensitive.

SyslogFacility AUTH and AUTHPRIV

Messages received by syslogd are processed according to their facility which indicates a the origin of the message. Standard SyslogFacility includes KERN (Messages from the OS Kernel), DAEMON (Messages from the Service or Daemon), USER (Messages from the user processes), MAIL (Messages from the email System) and others.

By default, the facility for SSH server messages is AUTHPRIV. This choice may be changed with the SSH keyword SyslogFacility which determines the syslog facility code for logging SSH Messages. Other possible values of SyslogFacility are DAEMON, USER, AUTH, AUTHPRIV, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6 and LOCAL7. The default is AUTHPRIV.

The option SyslogFacility specifies the facility code used when logging messages from sshd. The facility specifies the subsystem that produced the message—in our case, AUTH.

Normally, all authentication related messages are logged with the AUTHPRIV (or AUTH) facility [intended to be secure and never seen by unwanted eyes], while normal operational messages are logged with the DAEMON facility.

Enable Auth in sshd_config file

LogLevel

It gives the verbosity level that is used when logging messages from sshd. The possible other values are QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2 and DEBUG3. The default is INFO. DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of debugging the out-put.

If you want to record more information such as failed login attempts, then you should increase the logging level to VERBOSE.

Make sure to uncomment the below lines to enable loglevel.

Now you need to Restart ssh service

To enable the service of SSH, use the service sshd start command.

You can use watch command to see live ssh log file updates.

Check failed ssh login

You can use any of the below commands to check failed ssh login session on Centos and Ubuntu.

On Centos and Redhat

On Centos 7 and newer Linux distros using systemd

If you had auditd package installed, then you can use aureport tool to get authentication report. To get a report for all the failed attempts made:

Conclusion

There are mainly 3 different log managers available to Linux to collect and store logs. The default is syslog, other two are rsyslog and Syslog-ng.

Newer Linux distros use systemd’s logging service, which uses Journalctl for querying and displaying logs from journald.

I hope you enjoyed reading this tutorial on ssh logging and please leave your thoughts on this tutorial in the below comment section.

Источник

Использование screen для логирования действий (аудита) пользователей в Linux

Задача:

Собирать информацию о действиях пользователя (аудита) в консоли Linux, а именно вводимых им командах и выводимой на экран информации.

Предлагаемое решение:

screen по умолчанию для всех пользователей в Linux с логированием

Необходимые условия:

1. Полное логирование всех пользователей в консоли, включая вывод информации процессами, чтобы можно было оценить почему пользователь принял то или иное решение
2. Без возможности отключения логирования
3. Раз уж выбрали screen — максимально используем его возможности (открытие новых окон, отключение по ^a + d, оставляя рабочие процессы запущенными и другие удобства)
4. Максимальное удобство — не должно быть каких-либо несовместимостей с приложениями
5. В случае использования пользователями, не знакомыми с screen — сделать работу максимально знакомой и близкой к обычной командной оболочке (shell)

Возможные варианты:

1) Предложенный на Хабре вариант. Рабочий, но есть несколько моментов:

• По-хорошему надо было бы указать shell пользователя в /etc/shells
• screen как таковой не работает. Иначе говоря дополнительные окна не открываются
• Логирование отключается банальным ^a + H (заглавная)

2) Тут тоже предложены варианты, но это больше сырые заготовки

Итак, приступим:

Создаём скрипт для запуска screen, чтобы при запуске командной оболочки bash (ведь у вас bash, правда?) все пользователи использовали этот файл и загружались в screen по умолчанию с включённым логированием. При выходе из screen – сессия закрывается:
vi /usr/local/bin/get_in.sh

Что мы имеем:
-L — направить весь лог в файл (куда именно — см. директиву logfile в файле /etc/screenrc ниже)
-A — Адаптировать размеры окон к размеру текущего терминала. Взято отсюда.
-RR — Переподключить сессию и, если необходимо, отсоединить (detach) её или создать заново. Используется первая сессия, если больше чем одна доступна. В случае отключения по ^a + d, при повторном входе откроется эта же сессия этого же пользователя.
-c — мы чётко указываем, какой конфигурационный файл использовать, чтобы избежать возможности отключения логирования и переназначения опций пользователями, к примеру созданием файла в

/.screenrc.
-S — Назначаем сессии понятное имя. У каждого пользователя может быть одно и то же имя.

Делаем скрипт исполняемым:
chmod 0755 /usr/local/bin/get_in.sh

Делаем так, чтобы все использовали этот скрипт. Для этого в конец файла /etc/bash.bashrc добавляем строку:
/usr/local/bin/get_in.sh

Корректируем файл /etc/screenrc:

Не забываем создать директорию для логов:

Этим мы добиваемся, что все команды будут логироваться в лог-файлы вида:

В Debian, чтобы в screen работало автозавершение команд (bash_completion), необходимо раскомментировать в /etc/bash.bashrc:

Уважаемый 1ex подсказал решение, как с помощью wrapper-а для ssh логировать команды, выполняемые без входа в интерактивный режим bash вида: ssh user@host «ls -l». Для этого необходимо:
в /etc/ssh/sshd_config указать ссылку на обработку wrapper-ом:

Затем создать сам wrapper /etc/ssh/hook.sh:

Не забыть сделать его исполняемым:

Этим мы добиваемся, чтобы все такие команды (и только команды — без информации, что выводится на экране) логировались в ту же директорию и будут дополнены суффиксом «-command»:

Ну вот и всё. Теперь при подключении все пользователи (включая root — будьте осторожны, если потеряете возможность входа!) будут работать в screen, который запускается из bash. При выходе из screen, родительский bash закрывается и соединение прерывается. Если необходимо оставить работать процессы в фоне, то для выхода используем ^a+d. При следующем подключении эта сессия подключится автоматически.

Для дальнейшего изучения:

• Так как в логи пишется вывод команд — они могут занимать большое количество места. Необходимо предусмотреть методы сжатия для уменьшения объёма/трафика
• Лучшее место для логов — удалённая машина и далее обработку производить там, так как логи на локальной машине создаются с uid/guid пользователя и могут быть им удалены/изменены. Предполагается использование syslog.
• Возможно, есть методы обойти screen и, соответственно, логирования при этой конфигурации. Хотелось бы услышать их и внести изменения

Используемые источники:

Update:

1) По замечанию joneleth пути изменены на жёсткие:
Абзац:
Заменён на:

На данный момент существуют 2 метода обхода логирования команд:

1) Подсказана kiltum: команды типа ssh user@host «ls -l» не логируются. В этом случае команды выполняются как /bin/bash -c , при этом нужный /etc/bash.bashrc не читается.
Уважаемый 1ex подсказал решение с помощью wrapper-а для ssh. Теперь все команды такого типа логируются. Изменения в текст внесены.
2) Подсказана ForeverYoung: команда screen -X log отключает логирование.
Возможности отключить эту особенность пока что нету, поэтому необходимо применять административные меры к пользователям, кто запускает эту команду (сама эта команда всё равно будет записана в лог).
Лучшие решения приветствуются.

ИТОГИ:

Как выяснилось screen не совсем предназначен для решения такого рода задач, а именно принудительного логирования команд и их вывода без возможности отключения логирования. Это приводит к тому, что приходится дополнительно править другие файлы.
Как порекомендовал уважаемый amarao для решения такого рода задач лучше посмотреть на другие решения:
а) сниффинга всего трафика, проходящего через псевдотерминалы (более серьёзно). kiltumподсказал conspy. Slipeer предложил Snoopy Logger.
б) систем аудита (SELinux/Apparmor/etc), которые будут записывать реально всё выполняемое.
Но эти решения выходят за рамки данной статьи.

Считаю, что несмотря на недостатки, использование screen для логирования действий пользователей и выводимой на экран информации в Linux оправдано, ввиду несложности реализации, а главное — простоты чтения логов (в отличие от auditd, напимер).

Источник

6 commands to check and list active SSH connections in Linux

Table of Contents

How to check active SSH connections in Linux. Show SSH connection history. How to show active ssh sessions in Linux. List all the active SSH connections in Unix. Find out all the currently active ssh connections on any Linux node. Which all tools can be used to list all the active ssh connections in Linux. Show active SSH sessions. Check ssh connection history using log files in Linux.

Some more more articles you may be interested on similar topics:

Check active SSH connections

There are various commands and tools available in Linux which can be used to check active SSH connections or sessions on your Linux node. In this article I will share a list of tools which can be used to get the list of active SSH connections. If you are aware of any more commands to show active ssh sessions then please let me know via comment section.

1. Using ss command

ss is used to dump socket statistics. It allows showing information similar to netstat . It can display more TCP and state information than other tools. We will use grep function to only get the list of active SSH sessions on our local host

From the above example we know that there are three hosts which are currently connected to our node3. We have active SSH connections from 10.0.2.31, 10.0.2.30 and 10.0.2.2

2. Using last command

last searches back through the file /var/log/wtmp (or the file designated by the -f flag) and displays a list of all users logged in (and out) since that file was created. Names of users and tty’s can be given, in which case last will show only those entries matching the arguments.

Using this command you can also get the information about the user using which the SSH connection was created between server and client. So below we know the connection from 10.0.2.31 is done using ‘deepak‘ user, while for other two hosts, ‘root‘ user was used for connecting to node3.

Here I am grepping for a string «still» to get all the patterns with » still logged in «. So now we know we have three active SSH connections from 10.0.2.31, 10.0.2.30 and 10.0.2.2

3. Using who command

who is used to show who is logged on on your Linux host. This tool can also give this information

Using this command we also get similar information as from last command. Now you get the user details used for connecting to node3 from source host, also we have terminal information on which the session is still active.

4. Using w command

w displays information about the users currently on the machine, and their processes. This gives more information than who and last command and also serves our purpose to get the list of active SSH connections. Additionally it also gives us the information of the running process on those sessions.

Using w command you will also get the idle time details, i.e. for how long the session is idle. If the SSH session is idle for long period then it is a security breach and it is recommended that such idle SSH session must be killed, you can configure your Linux host to automatically kill such idle SSH session.

5. Using netstat command

Similar to ss we have netstat command to show active ssh sessions. Actually we can also say that ss is the new version of netstat. Here we can see all the ESTABLISHED SSH sessions from remote hosts to our localhost node3. it is also possible that one or some of these active ssh connections are in hung state so you can configure your host to automatically disconnect or kill these hung or unresponsive ssh sessions in Linux.

Источник

Локальное ведение журнала всех команд ssh с метками времени?

Как я могу сохранить локальную метку времени всех удаленных команд, которые я использую ssh (клиент openssh из командной строки запускается bash )?

Требования:

• 100% на стороне клиента, не полагаясь на ведение журнала на сервере
• Сконфигурированный или установленный для пользователя с журналами, сохраненными в домашнем каталоге пользователя.
• Поддержка различения нескольких одновременных сеансов с различными пользователями и хостами.
• Ненавязчивый (не нужно активировать его каждый раз и не сильно мешает использованию ssh)

• Либо вывод не зарегистрирован или отфильтрованы в максимально возможной степени
• Либо записи пароля не зарегистрированы, либо файл зашифрован
• Указывает фактические используемые команды (после завершения табуляции / истории, возвраты, CTRL + C и т.д . )

Хорошо бы иметь:

• Также регистрирует команды в связанных сессиях (команды, введенные во время удаленных ssh или su сессий)
• Начало и конец сеанса должны быть зарегистрированы
• bash Лучше было бы использовать простое решение без полномочий root (возможно, сценарий alias или bash оболочка для ssh команды?)

Мой уровень мастерства:

• Я не новичок в программировании, но я все еще учусь bash и «способ Linux», поэтому примеры кода с краткими пояснениями будут наиболее цениться.

Возможные стратегии

• Кейлоггер — Проблема: регистрирует пароли, не регистрирует вкладку / историю завершения (см . ответ Гленна )
• screen с выгрузкой прокрутки один раз в секунду и diff между ними для поиска новых строк прокрутки — Проблема: как это можно реализовать полезным автоматическим способом?
• ssh «$@» | tee >(some_cleaner_function >> $logfile) — Проблема: не может обрабатывать многострочные команды или историю в связанных сессиях, необходима тщательная очистка (см. Мой ответ)
• Сочетание некоторых из вышеперечисленных

Пример

Следующая сессия SSH:

Может привести к записи в журнале,

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

Я был заинтригован вашим вопросом. Изначально я не собирался давать ответ, но меня зацепило.

Это использует, expect и это действительно ключ регистратор.

• он добавляется в файл с адресом ssh в имени
• это регистратор ключей: если вы не настроили ssh-ключи, вы получите пароль пользователя в файле журнала.
• это мешает завершению табуляции: если пользователь наберет u p t Tab (для uptime команды), вы получите «upt \ t» в файле журнала, а не «uptime»
• он захватывает символы в «сыром» режиме: если пользователь плохо печатает, вы получите много ^? (символов возврата) в файле журнала.

В настоящее время я использую скрипт bash ниже. У него много проблем, но это единственное найденное мной решение, которое учитывает все требования, приоритеты и «приятно иметь» (по крайней мере, большую часть времени).

В этом ответе обсуждается, почему локальная регистрация сессий ssh ​​так сложна.

Проблемы со сценарием, которые я обнаружил до сих пор:

Многострочные команды вызывают проблемы:

• Если вы пролистаете многострочный элемент в удаленной истории (с помощью клавиш вверх / вниз), он запишет элемент истории вместо последней команды. Вы можете избежать этого, удалив из истории bash любые многострочные команды сразу после их использования.
• Регистрируется только первая строка многострочных команд.

Связанные сеансы (использование ssh или su команды на удаленном конце) вызывают прокрутку истории для записи команд с прокруткой вместо фактических используемых команд

Регулярные выражения могут быть улучшены и могут нуждаться в изменении для определенных сред:

• Я обманываю, преобразовывая непечатаемые символы cat -v перед очисткой. В результате допустимый контент может быть удален, если вы когда-либо будете использовать строки, как ^[[ в ваших командах.
• Иногда вы получаете дополнительный зарегистрированный ввод перед командой, например, если вы просматриваете историю очень быстро. Это обычно сопровождается «^ M» перед фактической командой и, таким образом, может быть удалено при желании.
• Другие управляющие символы иногда встречаются. Я оставляю их всех пока, пока не узнаю, какие из них безопасно удалить. ^ M, как я только что упомянул, полезен для обнаружения неверного зарегистрированного ввода, и ^ C сообщит вам, была ли команда прервана.
• Может быть необходимо изменить регулярное выражение для конкретных приглашений, и я мог бы предположить, что разные удаленные среды могут иметь разные шаблоны управляющих символов.

Нет завершения команды ssh, например, для имени хоста. Вы можете получить завершение оргии , если псевдоним этого скрипта ssh с alias ssh=»sshlog»

Сценарий источника и установки:

Чтобы установить, вставьте следующее в

/ bin / sshlog и сделайте исполняемым. Позвони с sshlog . При желании псевдоним ‘ssh’ в файле .bashrc пользователя.

Пример содержимого журнала:

Источник