Если это на самом деле OpenSSH sshd, я думаю, что сценарий где-то запускает их в разорванном цикле, и один из их дочерних процессов загружает весь этот процессор.
Как предложил Marki555, strace поможет вам, но вы должны использовать strace -f чтобы strace следовал за дочерними процессами. От man strace:
-f Trace child processes as they are created by cur-
rently traced processes as a result of the fork(2)
system call.
Поскольку strace генерирует так много данных, было бы также неплохо использовать аргумент -e (например, чтобы показывать только вызовы open ()):
-e expr A qualifying expression which modifies which events
to trace or how to trace them. The format of the
expression is:
[qualifier=][!]value1[,value2]...
Другая команда, которую вы можете попробовать, - это ps xaf или pstree -a чтобы легко понять древовидное представление процессов и их дочерних процессов, чтобы вы могли определить, какой процесс запустил эти sshd. lsof также может помочь вам, он скажет вам, какие файлы открыты у процесса.
И, конечно же, убедитесь, что вы используете последнюю версию OpenSSH. Я думаю, что rsync + большие файлы + ssh на древнем OpenSSH 3.4p1 было бы проблематично.
Если это на самом деле не процессы sshd, то контрольная сумма MD5 двоичного файла может отображаться правильно, но это может быть не фактическая работающая программа sshd. Также сама команда md5sum может быть версией с резервным копированием, которая модифицирована для сообщения правильной контрольной суммы для определенных файлов (например, sshd).
Вы должны взглянуть на /proc /[sshd pid] /exe и убедиться, что это символическая ссылка на /usr /sbin /sshd (или где бы ни находился ваш sshd), а также /proc /[sshd pid] /environment, чтобы увидеть какие переменные окружения он использует, и /proc /[sshd pid] /cmdline, чтобы увидеть, какая команда на самом деле его запустила.
Хотя злоумышленник мог переименовать вредоносную программу в "sshd", затем выполнить ее, чтобы она выглядела как sshd. Можно было даже переместить /usr /sbin /sshd в /tmp /sshd, а затем переместить вредоносный sshd в /usr /sbin /sshd, чтобы попытаться скрыть его от этого типа анализа /proc, но когда /tmp /sshd вернется в /usr /sbin /sshd символьная ссылка /proc /[sshd pid] /exe будет отображаться в ls как:
lrwxrwxrwx 1 root root 0 May 19 06:47 /proc/[sshd pid]/exe -> (deleted)/usr/sbin/sshd
Кроме того, если эти sshd делают что-то для активного предотвращения нормального анализа процесса, вы можете попробовать kill -STOP вместо kill -9 чтобы "приостановить" процесс (используйте kill -CONT чтобы возобновить его. См. Http://en.wikipedia.org/wiki/Job_control_%28Unix%29#Implementation).
Однако, если у злоумышленника есть привилегии root, можно установить руткит, скрывающийся от /proc, netstat, ls и т.д. Если вы действительно взломаны, лучше всего перевести систему в автономный режим и смонтировать ее разделы на другом ( Чистая) система затем выполняет экспертизу (или использует один из этих живых компакт-дисков Linux, созданный для экспертизы).
