Где найти лог-файлы SSH Login на centos – 3 ответа

Centos 6.5: нужно писать логи internal-sftp и sshd в разные файлы

Чистый и полностью обновленный Centos 6.5, OpenSSH версии 5.3p1-94.el6, настройки классические:

/etc/rsyslog.d/sftp.conf

$AddUnixListenSocket /var/www/vhosts/user1/dev/log
:programname, isequal, "internal-sftp" -/var/log/sftp.log
:programname, isequal, "internal-sftp" ~

/etc/ssh/sshd_config

Subsystem       sftp    internal-sftp -l VERBOSE
Match Group sftp
        ChrootDirectory %h
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp -l VERBOSE

Пользователь

user1

, home=

/var/www/vhosts/user1

, group=

sftp

Проблема в том, что всё работает как надо, только если убрать

ChrootDirectory

из настроек, даже

ChrootDirectory /

не помогает. Собственно вот что должно быть:

/var/log/secure

Jun  8 12:08:01 srv sshd[10371]: Accepted password for user1 from IP port 38817 ssh2
Jun  8 12:08:01 srv sshd[10371]: pam_unix(sshd:session): session opened for user user1 by (uid=0)
Jun  8 12:08:01 srv sshd[10373]: subsystem request for sftp
...

/var/log/sftp.log

Jun  8 12:08:01 srv internal-sftp[10374]: session opened for local user user1 from [IP]
Jun  8 12:08:01 srv internal-sftp[10374]: received client version 3
Jun  8 12:08:01 srv internal-sftp[10374]: opendir "/"
Jun  8 12:08:01 srv internal-sftp[10374]: closedir "/"
...

Если включить

ChrootDirectory

все логи идут в

/var/log/secure

от sshd с его Level и Facility, так что разделить их по разным файлам уже не реально, вот пример

Jun  8 12:11:01 srv sshd[10825]: Accepted password for user1 from IP port 38821 ssh2
Jun  8 12:11:01 srv sshd[10825]: pam_unix(sshd:session): session opened for user user1 by (uid=0)
Jun  8 12:11:01 srv sshd[10827]: subsystem request for sftp
Jun  8 12:11:01 srv sshd[10828]: session opened for local user user1 from [IP]
Jun  8 12:11:01 srv sshd[10828]: received client version 3
Jun  8 12:11:01 srv sshd[10828]: opendir "/"
Jun  8 12:11:01 srv sshd[10828]: closedir "/"
...

Варианты которые перебрал, но ничего хорошего не получилось:
1) Наличие доп.сокета rsyslog не на что не влияет, раскидывал его чуть ли не всей файловой системе, без видимого результата.
2) Домашняя директория пользователя по сути тоже не важна, понятно, если указывать абсолютный путь в jail или %u, поэтому оставил вариант выше, как наиболее удобный… корень тоже пробовал.
3) Продвинутая скриптовая схема правил rsyslog-а (версия 5.8.10) не работает. Как вариант, можно было-бы написать например:

if $programname == 'sshd' and ($msg startswith 'open' or $msg startswith 'close' ...) then /var/log/sftp.log

На этом мои светлые идеи закончились… подскажите, пожалуйста, что я мог упустить?

How to find all failed ssh login attempts in linux

Each attempt to login to SSH server is tracked and recorded into a log file by the rsyslog daemon in Linux. The most basic mechanism to list all failed SSH logins attempts in Linux is a combination of displaying and filtering the log files with the help of cat command or grep command.

In order to display a list of the failed SSH logins in Linux, issue some of the commands presented in this guide. Make sure that these commands are executed with root privileges.

The most simple command to list all failed SSH logins is the one shown below.

# grep "Failed password" /var/log/auth.log
List All Failed SSH Login Attempts
List All Failed SSH Login Attempts

The same result can also be achieved by issuing the cat command.

# cat /var/log/auth.log | grep "Failed password"

In order to display extra information about the failed SSH logins, issue the command as shown in the below example.

# egrep "Failed|Failure" /var/log/auth.log
Find Failed SSH Logins
Find Failed SSH Logins

In CentOS or RHEL, the failed SSH sessions are recorded in /var/log/secure file. Issue the above command against this log file to identify failed SSH logins.

# egrep "Failed|Failure" /var/log/secure
Find Failed SSH Logins in CentOS
Find Failed SSH Logins in CentOS

A slightly modified version of the above command to display failed SSH logins in CentOS or RHEL is as follows.

# grep "Failed" /var/log/secure
# grep "authentication failure" /var/log/secure
Find SSH Authentication Failure Logins
Find SSH Authentication Failure Logins

To display a list of all IP addresses that tried and failed to log in to the SSH server alongside the number of failed attempts of each IP address, issue the below command.

# grep "Failed password" /var/log/auth.log | awk ‘{print $11}’ | uniq -c | sort -nr
Find IP Addresses of SSH Failed Logins
Find IP Addresses of SSH Failed Logins

On newer Linux distributions you can query the runtime log file maintained by Systemd daemon via journalctl command. In order to display all failed SSH login attempts you should pipe the result via grep filter, as illustrated in the below command examples.

# journalctl _SYSTEMD_UNIT=ssh.service | egrep "Failed|Failure"
# journalctl _SYSTEMD_UNIT=sshd.service | egrep "Failed|Failure"  #In RHEL, CentOS 
Find Real Time Failed SSH Logins
Find Real Time Failed SSH Logins

In CentOS or RHEL, replace the SSH daemon unit with sshd.service, as shown in the below command examples.

# journalctl _SYSTEMD_UNIT=sshd.service | grep "failure"
# journalctl _SYSTEMD_UNIT=sshd.service | grep "Failed"

After you’ve identified the IP addresses that frequently hit your SSH server in order to log in to the system with suspicious user accounts or invalid user accounts, you should update your system firewall rules to block the failed SSH attempts IP addresses or use a specialized software, such as fail2ban to manage these attacks.

Unix/centos how to parse access_log and log any matches to file

tail -f will have continuous output, so > test may never create a file.

The suggestion in Ahmed Masud’s answer is probably superior to this so try that first, but if that doesn’t work out for you, you can just run this once a minute or once an hour or whatever if you don’t need to worry about being super-efficient about it:

grep 'POST /index.php' access_log > test

That will totally re-create the file test every time you run it rather than build it incrementally. But if you just want a crude tool, that will get it done.

If you do it this way and your log file gets rotated, you’ll no longer have what was in the previous log file in test after this runs on the new file. So do be aware of that! On the other hand, using tail -f, if the file rotates, you will stop getting data until you restart the process (and it to will blow away your old data too unless you use >> rather than >).

Где найти лог-файлы ssh login на centos – 3 ответа

lastlog(8)сообщит самую последнюю информацию от /var/log/lastlogобъекта, если вы pam_lastlog(8)настроили.

aulastlog(8)сделает аналогичный отчет, но из журнала аудита войдет /var/log/audit/audit.log. (Рекомендуется, так как auditd(8)записи труднее подделать, чем syslog(3)записи.)

ausearch -c sshdбудет искать в ваших журналах аудита отчеты о sshdпроцессе.

last(8)проведет поиск /var/log/wtmpсамых последних входов в систему. lastb(8)покажет bad login attempts.

/root/.bash_history может содержать некоторые подробности, если допустить, что goober, который возился с вашей системой, был недостаточно компетентен, чтобы не удалить его перед выходом из системы.

Убедитесь, что вы проверили ~/.ssh/authorized_keysфайлы для всех пользователей системы, проверьте crontabs, чтобы убедиться, что новые порты не планируется открывать в будущем, и т. Д.

Обратите внимание, что все журналы, хранящиеся на локальном компьютере, являются подозрительными; единственные журналы, которым вы действительно можете доверять, пересылаются на другую машину, которая не была взломана. Возможно, это стоило бы расследовать централизованную обработку журнала с помощью rsyslog(8)или auditd(8)удаленной обработки машины.

Вы также можете попробовать:

grep sshd /var/log/audit/audit.log 

А также:

last | grep [username]

или же

last | head 

Демон rsyslog

Центром механизма журналирования является демон rsyslog. Данный сервис отвечает за прослушивание зарегистрированных сообщений различных частей системы Linux и маршрутизацию сообщения к соответствующему журналу в каталоге /var/log. Он также может передавать зарегистрированные сообщения другому серверу Linux.

Конфигурационный файл logrotate

Как и rsyslog, logrotate зависит от конфигурационного файла по имени logrotate.conf, который находится в /etc.

Вот что находится в данном файле на Debian:

debian@debian:~$ cat /etc/logrotate.conf# see “man logrotate” for details# rotate log files weeklyweekly# keep 4 weeks worth of backlogsrotate 4# create new (empty) log files after rotating old onescreate# uncomment this if you want your log files compressed#compress# packages drop log rotation information into this directoryinclude /etc/logrotate.d# no packages own wtmp, or btmp — we’ll rotate them here/var/log/wtmp {missingokmonthlycreate 0664 root utmprotate 1}/var/log/btmp {missingokmonthlycreate 0660 root utmprotate 1}# system-specific logs may be configured here

Похожее:  Вопросы по QUIK

По умолчанию журналы ротируются еженедельно, оставляя 4 backlog-а. При запуске программы создается новый пустой журнал, а старые при необходимости будут сжаты.

Файлы wtmp и btmp являются исключениями. wtmp отслеживает вход в систему, а btmp содержит информацию о неудавшихся попытках входа. Эти журнальные файлы ротируются каждый месяц, и ошибки не возвращаются, если можно найти один из предыдущих файлов wtmp или btmp.

Пользовательские конфигурации ротации журналов содержатся в каталоге «etc/logrotate.d». также они включены в logrotate.conf с помощью директивы include. К примеру, Debian показывает такое содержание данного каталога:

debian@debian:~$ ls -l /etc/logrotate.dtotal 44-rw-r–r– 1 root root 173 Apr 15  2022 apt-rw-r–r– 1 root root  79 Aug 12  2022 aptitude-rw-r–r– 1 root root 135 Feb 24  2022 consolekit-rw-r–r– 1 root root 248 Nov 28  2022 cups-rw-r–r– 1 root root 232 Sep 19  2022 dpkg-rw-r–r– 1 root root 146 May 12  2022 exim4-base-rw-r–r– 1 root root 126 May 12  2022 exim4-paniclog-rw-r–r– 1 root root 157 Nov 16  2022 pm-utils-rw-r–r– 1 root root  94 Aug  8  2022 ppp-rw-r–r– 1 root root 515 Nov 30  2022 rsyslog-rw-r–r– 1 root root 114 Nov 26  2008 unattended-upgrades

Содержание rsyslog показывает, как вернуть логи в исходное состояние:

Конфигурационный файл rsyslog

Демон rsyslog получает конфигурации из файла «rsyslog.conf», который находится в каталоге /etc.

В основном, файл rsyslog.conf говорит демону, где хранить сообщения. Данная информация имеет вид серии строк, состоящих из двух частей.

Этот файл можно найти в rsyslog.d/50-default.conf в Ubuntu.

Под двумя частями строк подразумеваются селектор и действие (selector и action). Они разделяются пробельным символом.

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

Сам селектор также разделен на 2 части символом точки (.). Часть перед символом точки называется объектом (источник сообщения), а часть за символом называется приоритетом (степень важности сообщения).

Комбинация объекта-приоритета и действия говорит rsyslog, что делать, если сообщение соответствует указанным параметрам.

Вот отрывок из файла rsyslog.conf на CentOS:

# rsyslog v5 configuration file……# Include all config files in /etc/rsyslog.d/IncludeConfig /etc/rsyslog.d/*.conf#### RULES ##### Log all kernel messages to the console.# Logging much else clutters up the screen.#kern.*  /dev/console# Log anything (except mail) of level info or higher.

# Don’t log private authentication messages!*.info;mail.none;authpriv.none;cron.none                /var/log/messages# The authpriv file has restricted access.authpriv.*                                              /var/log/secure# Log all the mail messages in one place.mail.*                                                  -/var/log/maillog# Log cron stuffcron.*                                                  /var/log/cron# Everybody gets emergency messages*.emerg                                                 *# Save news errors of level crit and higher in a special file.uucp,news.crit                                          /var/log/spooler# Save boot messages also to boot.loglocal7.*                                                /var/log/boot.log……

Чтобы понять, что все это значит, нужно рассмотреть типы объектов, которые распознает Linux:

Ниже приведен список приоритетов по возрастанию:

  • Debug: Отладочная информация от программ;
  • info: простое информационное сообщение – никакого вмешательства не требуется;
  • notice: состояние, которое может потребовать внимания;
  • warn: Предупреждение;
  • err: ошибка;
  • crit: критическое состояние;
  • alert: состояние, требующее немедленного вмешательства;
  • emerg: аварийное состояние.

Изучите следующую строку из файла:

cron.*              /var/log/cron

Она говорит rsyslog сохранять все сообщения, приходящие от демона cron, в файле /var/log/cron. Звездочка (*) поле точки значит, что зарегистрированы будут сообщения всех приоритетов. Аналогичным образом, если объект был определен звездочкой, это объединяет все источники.

Объекты и приоритеты могут быть связаны в несколькими способами.

Вид по умолчанию, когда после точки указан только один приоритет, значит, что будут охвачены все сообщения с таким или высшим уровнем приоритета. Таким образом, данное указание регистрирует все сообщения, приходящие от почтовой подсистемы с приоритетом «warn» и выше в специальном файле в /var/log:

mail.warn           /var/log/mail.warn

Такие параметры будут регистрировать все сообщения с таким же или высшим, чем warn, приоритетом и пропускать все остальное. То есть, сообщения с приоритетом err, crit, alert и emerg также будут внесены в файл.

Знак равности (=) после точки указывает регистрировать только сообщения с указанным приоритетом. То есть, если нужно регистрировать только сообщения от почтовой подсистемы с приоритетом info, указание будет таким:

mail.=info          /var/log/mail.info

Опять же, если нужно регистрировать все сообщения почтовой подсистемы, кроме сообщений с приоритетом  info, строка будет выглядеть так:

mail.!info          /var/log/mail.info

или так:

mail.!=info         /var/log/mail.info

В первом случае файл mail.info содержал бы все сообщения с приоритетом ниже info. Во втором случае он содержал бы все сообщения с приоритетом выше info.

Несколько объектов в одной строке нужно разделить запятой.

Несколько селекторов в одной строке также разделяются запятой.

Отмеченное звездочкой действие объединяет всех пользователей.

К примеру, об этом говорит запись в файле rsyslog.conf на CentOS:

# Everybody gets emergency messages*.emerg                                                 *

По возможности проверьте, что говорит rsyslog.conf на других системах Linux. Вот отрывок из Debian:

Просмотр логов

В каталоге /var/log находится несколько общих журналов:

  • wtmp
  • utmp
  • dmesg
  • messages
  • maillog или mail.log
  • spooler
  • auth.log или secure

Файлы wtmp и utmp отслеживают пользователей, вошедших и покинувших систему. Содержимое данных журналов нельзя читать с помощью простой команды «cat», для этого есть специальные команды, с которыми теперь нужно ознакомиться.

Чтобы узнать, кто в текущий момент находится на сервере Linux, нужно использовать команду «who». Она извлекает информацию из /var/run/utmp (в CentOS и Debian) или из /run/utmp (в Ubuntu).

Это пример ее работы в CentOS:

Ротация  лог-файлов

Со временем журналы становятся больше, поскольку в них появляется новая информация. Это создает потенциальную проблему производительности. Кроме того, управление файлами становится затруднительным.

Linux использует понятие «ротации» журналов вместо их очистки или удаления. При ротации создается новый каталог, а старый переименуется и при необходимости сжимается. Таким образом, журналы имеют несколько старых версий. Эти файлы будут возвращаться в течение определенного периода времени в виде так называемых backlog-ов. Как только будет получено определенное количество backlog-ов, новая ротация удалит самый старый журнал.

Ротация выполняется при помощи утилиты «logrotate».

Создание и тестирование сообщений

Теперь попробуйте сами создать сообщение.

Для этого нужно будет сделать следующее:

  • Задать спецификацию в файле /etc/rsyslog.conf;
  • Перезапустить демон rsyslog;
  • Проверить конфигурацию с помощью утилиты «logger».

В следующем примере внесены две строки в файл rsyslog.conf на CentOS. Как видите, обе они исходят от объекта local4 и имеют разные приоритеты.

[root@TestLinux ~]# vi /etc/rsyslog.conf……..# New lines added for testing log message generationlocal4.crit                                             /var/log/local4crit.loglocal4.=info                                            /var/log/local4info.log

Затем нужно перезапустить сервис, чтобы обновить данные файла:

[root@TestLinux ~]# /etc/init.d/rsyslog restartShutting down system logger:                               [  OK  ]
Starting system logger:                                    [  OK  ]
[root@TestLinux ~]#

Теперь нужно вызвать приложение logger, чтобы создать сообщение:

[root@TestLinux ~]# logger -p local4.info ” This is a info message from local 4″

Каталог /var/log показывает два новых сообщения:

……-rw——-  1 root root      0 Dec  9 11:21 local4crit.log-rw——-  1 root root     72 Dec  9 11:22 local4info.log

Размер local4info.log не равен нулю, а это значит, что сообщение было записано:

[root@TestLinux ~]# cat /var/log/local4info.logDec  9 11:22:32 TestLinux root:  This is a info message from local 4

Стандартные логи

По умолчанию журналы в Linux хранятся в  /var/log.

Для просмотра списка журналов, находящихся в данном каталоге, используйте команду ls -l /var/log.

В системе CentOS это выглядит так:

[root@TestLinux ~]# ls -l /var/logtotal 1472-rw——-. 1 root root   4524 Nov 15 16:04 anaconda.ifcfg.log-rw——-. 1 root root  59041 Nov 15 16:04 anaconda.log-rw——-. 1 root root  42763 Nov 15 16:04 anaconda.program.log-rw——-.

1 root root 299910 Nov 15 16:04 anaconda.storage.log-rw——-. 1 root root  40669 Nov 15 16:04 anaconda.syslog-rw——-. 1 root root  57061 Nov 15 16:04 anaconda.xlog-rw——-. 1 root root   1829 Nov 15 16:04 anaconda.yum.logdrwxr-x—.

2 root root   4096 Nov 15 16:11 audit-rw-r–r–  1 root root   2252 Dec  9 10:27 boot.log-rw——-  1 root utmp    384 Dec  9 10:31 btmp-rw——-. 1 root utmp   1920 Nov 28 09:28 btmp-20221202drwxr-xr-x  2 root root   4096 Nov 29 15:

47 ConsoleKit-rw——-  1 root root   2288 Dec  9 11:01 cron-rw——-. 1 root root   8809 Dec  2 17:09 cron-20221202-rw-r–r–  1 root root  21510 Dec  9 10:27 dmesg-rw-r–r–  1 root root  21351 Dec  6 16:37 dmesg.old-rw-r–r–.

Похожее:  Балашихинская Электросеть

1 root root 165665 Nov 15 16:04 dracut.log-rw-r–r–. 1 root root 146876 Dec  9 10:44 lastlog-rw——-  1 root root    950 Dec  9 10:27 maillog-rw——-. 1 root root   4609 Dec  2 17:00 maillog-20221202-rw——-  1 root root 123174 Dec  9 10:

27 messages-rw——-. 1 root root 458481 Dec  2 17:00 messages-20221202-rw——-  1 root root   2644 Dec  9 10:44 secure-rw——-. 1 root root  15984 Dec  2 17:00 secure-20221202-rw——-  1 root root      0 Dec  2 17:09 spooler-rw——-.

Тестирование ротации

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

Чтобы продемонстрировать, как это работает, ниже приведен неполный список журнальных файлов в каталоге /var/log на CentOS:

[root@TestLinux ~]# ls -l /var/logtotal 800…-rw——-  1 root root    359 Dec 17 18:25 maillog-rw——-. 1 root root   1830 Dec 16 16:35 maillog-20221216-rw——-  1 root root  30554 Dec 17 18:25 messages-rw——-.

Неполное содержимое файла logrotate.conf выглядит так:

[root@TestLinux ~]# cat /etc/logrotate.conf# see “man logrotate” for details# rotate log files weeklyweekly# keep 4 weeks worth of backlogsrotate 4# create new (empty) log files after rotating old onescreate……

Затем запустите команду logrotate:

[root@TestLinux ~]# logrotate -fv /etc/logrotate.conf

Сообщения прокручиваются при создании новых файлов, обнаружении ошибок и т.д. Затем  попробуйте проверить новые журнальные файлы почты, безопасности и сообщений:

[root@TestLinux ~]# ls -l /var/log/mail*-rw——-  1 root root    0 Dec 17 18:34 /var/log/maillog-rw——-. 1 root root 1830 Dec 16 16:35 /var/log/maillog-20221216-rw——-  1 root root  359 Dec 17 18:25 /var/log/maillog-20221217[root@TestLinux ~]# ls -l /var/log/messages*-rw——-  1 root root    148 Dec 17 18:

34 /var/log/messages-rw——-. 1 root root 180429 Dec 16 16:35 /var/log/messages-20221216-rw——-  1 root root  30554 Dec 17 18:25 /var/log/messages-20221217[root@TestLinux ~]# ls -l /var/log/secure*-rw——-  1 root root    0 Dec 17 18:

Как можно видеть, все три новых журнала были созданы. Почтовый журнал и журнал безопасности все еще пусты, но новый журнал сообщений уже содержит некоторые данные.

Централизованный сбор логов с консолей сетевого оборудования по ssh

Существуют рекомендованные, общепринятые средства сбора логов сетевого оборудования — SNMP, syslog и иже с ними. Обычно они прекрасно работают, но временами требуется нечто большее.

Представим себе следующий сценарий: некая сетевая железка на ровном месте исчезает из сети, и через несколько минут снова появляется. «Show version» указывает на перезагрузку, вызванную неким crash, который может быть следствием тысяч причин в сотнях компонентов ОС. Файл crashinfo отсутствует. Syslog сервер не получал никаких сообщений от устройства перед самым падением. Устройство покрыто сервисным контрактом – но TAC не может воспроизвести аварию у себя, а переданной клиентом информации слишком мало для точного установления причин аварии. Непонятно даже, было ли падение вызвано программным или аппаратным сбоем. Можно заменить устройство, но это не поможет, если причина программная. Переходить на другую версию ОС? А на какую? Ведь неизвестно, какой баг вызвал падение и закрыт ли он в новой версии – а там могут найтись и новые баги. В процессе общения сотрудник TAC упоминает, что перед самым падением, когда уже отказала сеть, устройство наверняка послало сообщение в консоль с информацией о том, какая подсистема упала и в связи с чем. У вас, конечно, уже есть терминальный сервер, но используется он только для аварийного доступа к устройству, а все прилетающие с консольного порта отслеживаемой железки сообщения он игнорирует. Надо как-то собирать эти сообщения. Этим мы и займемся.

Маленькое замечание. Все, что предлагается ниже, рассматривается лишь как дополнение к традиционным средствам мониторинга (в первую очередь штатный SNMP/syslog на устройствах) и предназначено для упрощения расследования причин аварий (ну а заодно для автоматического сбора лога перезагрузки). И хочется надеяться, что собранные таким образом данные не пригодятся никогда.

За основу берем статью “Терминальный сервер на базе маршрутизатора Cisco“. Там указаны правильные первые шаги. Однако, там не рассмотрен вопрос собственно логирования сообщений. Ну и для подключения используется телнет, что, конечно, недопустимо. Можно считать данную статью продолжением той.

SSH клиентом и по совместительству сборщиком логов будет отдельный сервер на *NIX. В моем случае – Centos 6-й линейки.
Для начала рассмотрим сам по себе доступ к терминальному серверу. Штатный линуксовый клиент ssh не умеет автоматически вводить пароль, будучи вызванным из скрипта (при желании это обходится весьма некрасивым способом), но нам это и не надо.

1) Обновляем роутер, работающий терминальным сервером, до 15-й версии IOS (с поддержкой фичи «SSHv2 Enhancements for RSA Keys» — для роутерных IOS платформ на первый взгляд весь софт с k9 15-х линеек поддерживает данную фичу)
2) Создаем пару ключей RSA для SSH сессий на сервере. Просьбу «Enter passphrase» игнорируем и жмем enter.

[root@centos ~]# ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
1d:60:fe:72:b5:8c:1e:b5:5e:d1:3c:9c:67:15:9c:59 root@centos
The key's randomart image is:
 --[ RSA 2048]---- 
|        o     ..E|
|       o .    .*o|
|        . . o . =|
|         o * o oo|
|        S *   .  |
|           o .   |
|          . .    |
|                 |
|                 |
 ----------------- 

3) Берем публичный ключ RSA.

[root@centos ~]# cat /root/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0w2L4YVD/V303ccFatgtJxcS JMYlPkmyufW36fUCogGjzWLbtMZGYoAW8vgy bVgN6r7lcbrbpF6oW9beGfHIWTBfUT898sUQL9jOOki0qvUWzkbej/po6agAK3KK/Z7QCtnAkbDQDb1SzHEmTx9rmboY EZosHOchQy dvHEoBKCOMBrGKpYgdHfImjctKS3Q02TrkTO0 BoIFc2V32R9AukWFp7 ppGy2ZdoxLv5eEjlhcHukbM yKg9Kjc72/dPNbNkvLXcWKVnkebTmTJIQQyGU2qsAy2asgPC6D02gy6tZAdqp 0umEF2gLXlq2G1p3kn AojH8bWvYBwyL2s6Q== root@centos

4) Если роутер не настроен SSHv2 сервером, то исправляем это досадное недоразумение стандартным способом.

5) Копируем публичный ключ сервера на роутер. Важно: строка длинная, поэтому потребуется копировать его частями, в 2-3 захода, нажимая enter между кусками и каждый раз убеждаться, что все символы влезли.

termserver(config)#ip ssh pubkey-chain
! указываем того пользователя, который сможет логиниться без пароля по сертификату
termserver(conf-ssh-pubkey)#username consoleuser
termserver(conf-ssh-pubkey-user)#key-string
termserver(conf-ssh-pubkey-data)# ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQE…
termserver(conf-ssh-pubkey-data)#...BwyL2s6Q== root@centos
! все содержание файла id_rsa.pub должно быть скопировано от первой до последней буквы
termserver(conf-ssh-pubkey-data)#exit
! если на этом этапе выскочила ошибка, то нужно копировать меньшими порциями
termserver(conf-ssh-pubkey-user)#exit
termserver(conf-ssh-pubkey)#

Проверяем, работает ли аутентификация по RSA:

[root@centos ~]# ssh consoleuser@10.10.0.10
termserver>

Теперь нужно проверить, удастся ли подключиться к консольному порту. Сначала разрешаем ssh на всех line’ах (попутно запрещая telnet, если он был открыт). На моем терминальном сервере нумерация идет от 1/0 до 1/15:

termserver(config)# line 1/0 1/15
termserver(config-line)# transport input ssh

Теперь само подключение. Из второго столбца «show line» узнаем номер линии (пусть будет 75) и делаем:

[root@centos ~]# ssh consoleuser:75@10.10.0.10

Жмем еще раз enter и видим:

Username:

А это уже послало то устройство, чья консоль подключена к 75-й линии терминального сервера. Аутентифицируемся для проверки:

Username: admin
Password: 
router1> exit
router1 con0 is now available
Press RETURN to get started.

Отлично, доступ по ssh к консоли есть. Осталось настроить отправку логов в консоль на отслеживаемом оборудовании. Тут есть нюанс. Многие делают «no logging console», и в общем случае это имеет смысл. Нельзя допустить, чтобы консоль была перегружена сообщениями, да и они могут мешаться. Однако для наших целей это не годится. Потому первым делом на обеих сторонах:

router1(config)# line console 0
router1(config-line)#speed 115200
termserver(config)# line 1/0 1/15
termserver(config-line)#speed 115200

В данном случае выставлено 115200. Это по опыту довольно надежное значение (и чертовски быстрое по сравнению с родным 9600), но все равно надо проверить, что при получении больших блоков текста не приходят кракозябры.

Далее, нужно определить, какого уровня записи слать в консоль командой logging console X, где X — число от 1 до 7. «6» и «7» включать категорически нельзя, там лишь информационные сообщения (чаще всего бесполезные), которых может быть много (особенно на «7» — это уровень дебагов, который должен писаться только в buffered).«5» и «4» — обычно годится, но надо проанализировать, сколько сообщений с таким уровнем попадает в буфер. Например, “%ASA-4-106023” — это сообщения о блокировании пакетов на файрволах ASA, которых может быть крайне много, и нам не нужно гнать их в консоль. Возможно, имеет смысл поменять facility отдельных сообщений syslog на самом устройстве. Нам безусловно интересно собирать любые сообщения с facility от 1 до 3, а также не помешают события поднятия/падения интерфейсов (хотя если речь идет про коммутатор с сотнями портов, то это под вопросом). В общем, есть поле для размышлений.

Похожее:  Быстрый, простой и рабочий способ обхода Captive Portal (hotspot с авторизацией на web-интерфейсе) -

Терминальных серверов может быть несколько, у каждого десятки линий. Да и любой роутер без HWIC-16A является терминальным сервером на один порт (AUX). Сейчас у нас уже настроен доступ к консолям по ssh и отправка логов в консоль, но нет записи событий. Начинаем писать скрипты, причем такие, чтобы добавление новой консоли было делом простым и приятным.

Для начала, напишем скрипт, который будет парсить список хостов и линий, запуская соединения. Пусть он зовется startcon.sh

#!/bin/bash
#куда сбрасывать логи сессий. В данном примере они сохраняются в файл, но ничто не мешает сразу отправлять их хоть в syslog, хоть в почту.
LOGFOLDER="/root/logs/"
#откуда брать список хостов и линий
LIST="/root/collectconsole/consolelist.txt"
#где искать скрипт на запуск ssh
LOCATION="/root/collectconsole"
#Парсим список на предмет записей вида «75,10.10.0.1,termserver», где первая запись – линия, вторая – адрес терминального сервера, а третья – имя подключенного сетевого железа – для проставления хостнеймов на файлах логов. Номер линии может содержать от одной до трех цифр, а хостнейм по нашей политике содержит только буквы, цифры и дефис
for i in $(cat $LIST | egrep -o "[0-9]{1,3},([0-9]{1,3}.){3}[0-9]{1,3},[a-zA-Z0-9-] ") ; do
#Вырезаем первую и вторую запись из строки для скармливания их connectcon.sh – скрипту, осуществляющему подключение к линиям терминального сервера.
ARGS="$(echo $i | cut -f 1 -d ",") $(echo $i | cut -f 2 -d ",")"
#Запускаем соединение только если его еще не было
if ! ps ax | grep -v grep | grep "connectcon.sh $ARGS" > /dev/null ;
then
$LOCATION/connectcon.sh $ARGS >> $LOGFOLDER$(echo $i | cut -f 3 -d ",").log &
fi
Done

Создаем consolelist.txt с указанием номеров линий (вторая колонка из «show line» терминального сервера), адресов терминальных серверов и названий подключенных к этим линиям устройств:

nano consolelist.txt
66,10.10.0.10,router1
70,10.10.0.10,router2
71,10.10.0.10,router3
74,10.10.0.10,router4
67,10.10.0.10,router5
72,10.10.0.10,router6
75,10.10.0.10,router7
76,10.10.0.10,router8
79,10.10.0.10,router9

Создаем скрипт connectcon.sh. С ним не все просто. Изначально я пытался сделать его обычным bash скриптом, вызывающим ssh. Но как оказалось, ssh, будучи запущенным в фоне, отказывается редиректить все услышанное в файл. Решение было найдено. Сначала нужно установить интерпретатор expect – для centos это «yum install expect». Затем создать скрипт:

#!/usr/bin/expect –f
#мы ожидаем, что соединение будет висеть вечно – пока его не отобьет та сторона. Ну или пока сам процесс не будет убит.
set timeout -1
#Собираем аргументы, с которыми скрипт запускался.
set line [lrange $argv 0 0] 
set ipaddr [lrange $argv 1 1]   
#Теперь запуск ssh. Нам нужно, чтобы соединение держалось вечно. Как только его отобьют с той стороны – надо переподключиться. Т.е. бесконечный цикл. «expect timeout» останавливает выполнение цикла до тех пор, пока команда перед ним не отработает, что может быть вызвано разрывом ssh соединения с терминальным сервером – тогда надо переподключиться, подождав 2 минуты.
while { true } {
spawn ssh consoleuser:$line@$ipaddr
expect timeout
sleep 120
}

Как известно, несколько подключений не могут одновременно использовать одну консоль. А что делать, если нужно самому зайти на консольный порт и выполнить какие-либо действия? Решение простое: нужно зайти в обычную сессию терминального сервера и поклирить нужную линию.

termserver#clear line 75
[confirm]
 [OK]

Этим мы выбили сервер логирования с терминального сервера. Команда «sleep 120» в скрипте даст нам 2 минуты на то, чтобы самим залогиниться. А сборщик логов будет продолжать раз в 2 минуты стучаться в дверь, пока мы не выйдем.

Всё. Запускаем startcon.sh:

[root@centos collectconsole]# ./startcon.sh 
[root@centos collectconsole]#

Смотрим процессы:

[root@centos collectconsole]# ps -ef | grep -E "connectcon|ssh"
…
root     23151     1  0 14:54 pts/4    00:00:00 /usr/bin/expect -f /root/collectconsole/connectcon.sh 66 10.10.0.10
root     23152     1  0 14:54 pts/4    00:00:00 /usr/bin/expect -f /root/collectconsole/connectcon.sh 70 10.10.0.10
root     23153     1  0 14:54 pts/4    00:00:00 /usr/bin/expect -f /root/collectconsole/connectcon.sh 71 10.10.0.10
root     23154     1  0 14:54 pts/4    00:00:00 /usr/bin/expect -f /root/collectconsole/connectcon.sh 74 10.10.0.10
root     23155     1  0 14:54 pts/4    00:00:00 /usr/bin/expect -f /root/collectconsole/connectcon.sh 67 10.10.0.10
root     23156     1  0 14:54 pts/4    00:00:00 /usr/bin/expect -f /root/collectconsole/connectcon.sh 72 10.10.0.10
root     23157     1  0 14:54 pts/4    00:00:00 /usr/bin/expect -f /root/collectconsole/connectcon.sh 75 10.10.0.10
root     23158     1  0 14:54 pts/4    00:00:00 /usr/bin/expect -f /root/collectconsole/connectcon.sh 76 10.10.0.10
root     23159     1  0 14:54 pts/4    00:00:00 /usr/bin/expect -f /root/collectconsole/connectcon.sh 79 10.10.0.10
root     23239 23155  0 14:54 pts/2    00:00:00 ssh consoleuser:67@10.10.0.10
root     23240 23156  0 14:54 pts/3    00:00:00 ssh consoleuser:72@10.10.0.10
root     23242 23158  0 14:54 pts/6    00:00:00 ssh consoleuser:76@10.10.0.10
root     23243 23159  0 14:54 pts/7    00:00:00 ssh consoleuser:79@10.10.0.10
root     23244 23153  0 14:54 pts/8    00:00:00 ssh consoleuser:71@10.10.0.10
root     23247 23152  0 14:54 pts/9    00:00:00 ssh consoleuser:70@10.10.0.10
root     23248 23154  0 14:54 pts/1    00:00:00 ssh consoleuser:74@10.10.0.10
root     23255 23151  0 14:54 pts/10   00:00:00 ssh consoleuser:66@10.10.0.10
root     23341 23157  0 15:09 pts/5    00:00:00 ssh consoleuser:75@10.10.0.10
…

Смотрим хранилище логов (router4 что-то уже записал, остальные пока молчат):

[root@centos collectconsole]# ls -l /root/logs/
-rw-r--r-- 1 root root    58 Sep 22 14:54 router1.log
-rw-r--r-- 1 root root    58 Sep 22 14:54 router2.log
-rw-r--r-- 1 root root    58 Sep 22 14:54 router3.log
-rw-r--r-- 1 root root   115 Sep 22 14:57 router4.log
-rw-r--r-- 1 root root    58 Sep 22 14:54 router5.log
-rw-r--r-- 1 root root    58 Sep 22 14:54 router6.log
-rw-r--r-- 1 root root    58 Sep 22 14:54 router7.log
-rw-r--r-- 1 root root    58 Sep 22 14:54 router8.log
-rw-r--r-- 1 root root    58 Sep 22 14:54 router9.log

Смотрим на терминальном сервере:

termserver#sh line
   Tty Line Typ     Tx/Rx    A Modem  Roty AccO AccI  Uses  Noise Overruns  Int
      0    0 CTY              -    -      -    -    -     0      0    0/0      -
      1    1 AUX 115200/115200- inout     -    -    -     0      0    0/0      -
*   1/0   66 TTY 115200/115200-    -      -    -    -     0      0    0/0      -
*   1/1   67 TTY 115200/115200-    -      -    -    -     0      0    0/0      -
    1/2   68 TTY 115200/115200-    -      -    -    -     0      0    0/0      -
    1/3   69 TTY 115200/115200-    -      -    -    -     0      0    0/0      -
*   1/4   70 TTY 115200/115200-    -      -    -    -     0      0    0/0      -
*   1/5   71 TTY 115200/115200-    -      -    -    -     0      0    0/0      -
*   1/6   72 TTY 115200/115200-    -      -    -    -     0      1    0/0      -
    1/7   73 TTY 115200/115200-    -      -    -    -     0      0    0/0      -
*   1/8   74 TTY 115200/115200-    -      -    -    -     0      0    0/0      -
*   1/9   75 TTY 115200/115200-    -      1    -    -     2      0    2/4      -
*  1/10   76 TTY 115200/115200-    -      -    -    -     0      0    0/0      -
   1/11   77 TTY 115200/115200-    -      -    -    -     0      0    0/0      -
   1/12   78 TTY 115200/115200-    -      -    -    -     0      0    0/0      -
*  1/13   79 TTY 115200/115200-    -      -    -    -     0      0    0/0      -
   1/14   80 TTY 115200/115200-    -      -    -    -     0      0    0/0      -
   1/15   81 TTY 115200/115200-    -      -    -    -     0      0    0/0      -

Указанные в конфигурационном файле линии заняты (помечено звездочками). Отлично, скрипты работают.

Теперь к запуску скрипта startcon.sh. Можно поместить его в init.d и/или в cron.daily (тогда добавленные в список узлы начнут писаться на следующий день либо после рестарта системы). И — задача решена.

Осталось отметить несколько немаловажных моментов.
1) Имеет смысл средствами Secure ACS сервера ограничить права используемого для данных целей аккаунта. Он должен уметь логиниться, но ничего кроме этого. Причем логиниться он должен на ограниченный список устройств.
2) Для запуска скриптов лучше создать отдельный аккаунт на Linux-машине. Соответственно — под ним сгенерировать ключи RSA и именно их подсунуть на терминальный сервер. Да, в данной статье я всё время сидел под рутом, но все знают, что это нехорошо. Да и местоположение хранилища логов стоит изменить.
3) Logrotate на линуксе позволит файлам логов не достигать астрономических размеров. Лучше его включить для данных файлов. Алгоритм архивирования зависит от скорости наполнения файлов.
4) Надо жестко ограничить доступ к файлам логов.
5) Сервер сбора логов лучше разместить по отношению к терминальному серверу так, чтобы падение любой отслеживаемой железки не нарушало связь между сборщиком и терминальным сервером дольше чем на несколько секунд. Да и вообще, стройте сети так, чтобы отказ одного устройства вызывал сбой работы сети продолжительностью не более пары-тройки секунд.
6) Ничто не мешает использовать эти скрипты для записи событий любых устройств, подключенных к терминальному серверу — не только цискиных устройств.
7) Терминальным сервером может быть любой цискин роутер, имеющий AUX порт. К этому порту подключается с помощью rollover кабеля консольный порт целевой железки. И точно так же ставится на запись добавлением одной строки в конфиг. Это полезно для мелких офисов, где стоят по одному роутеру и свитчу — можно отслеживать свитч.
8) У меня мало опыта написания shell-скриптов, и в предложенной конфигурации наверняка можно много чего улучшить. Буду рад любым дополнениям.

Заключение

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

Tags:

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 4,00 из 5)
Загрузка...

Добавить комментарий

Ваш адрес email не будет опубликован.

Adblock
detector