Я даже не уверен, правильно ли я спросил. Каждый раз, когда кто-то упоминает об изменении пароля root, он упоминает об изменении /etc/passwd, или просто используя passwd команда, но я никогда не слышал о необходимости изменять ее в файле authorized_keys. Где я могу это найти и как я могу безопасно удалить запись или изменить ее для root, не вызывая хаоса? Спасибо!
Да. Вам нужно будет удалить открытый SSH-ключ пользователя, чтобы полностью удалить доступ. Если вы просто пытаетесь лишить одного пользователя доступа к root, это немного сложно. Надеюсь, вы использовали отдельные закрытые ключи, потому что в противном случае вам придется воссоздавать файл и распространять открытые ключи авторизованным пользователям.
Чтобы удалить запись, вам необходимо отредактировать authorized_keys файл. Если это ваш пользователь root в системе Linux, скорее всего, файл можно найти по адресу /root/.ssh/authorized_keys. Вам нужно будет удалить строку, содержащую открытый ключ пользователя, которого вы удаляете. К сожалению, нет простого способа узнать, что это за строка, без копии открытого ключа этого пользователя.
Да; только по этой причине считается плохой практикой разрешать пользователям использовать ssh как "root". В ваших ящиках, вероятно, должен быть отключен root ssh, а также должно использоваться что-то вроде «sudo» для обеспечения контроля доступа над тем, кто что может делать как root, таким образом вам не нужно будет выдавать пароль root или что-то подобное.
Учетные записи выпускников можно просто отключить, и вы можете гарантировать, что они не смогут вернуться (если, конечно, они не оставили какие-то задние двери, с которыми вы в любом случае ничего не можете сделать).
Мы используем каталог ldap для хранения пользователей, групп и ключей ssh, а затем ограничиваем доступ «sudo» по группе.
Если у кого-то был root, очень сложно, возможно, невозможно быть уверенным, что он не сможет его вернуть, если вы не переустановите и не восстановите его из резервной копии, сделанной до того, как у них был доступ. На что следует обратить внимание: во-первых, старый трюк: любые лишние пользователи в /etc/passwd с UID 0. Например:
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
..etc...
something-innocuous:0:42:foo:/:/bin/sh
..etc..
У этого дополнительного пользователя будет отдельный пароль, и он будет фактически root, как только войдет в систему.
Бегать visudo если у вас есть sudo установлен и проверьте, нет ли там чего-нибудь необычного.
Вы должны проверить /etc/pam.conf и все /etc/pam.d (возможно, и в другом месте?), чтобы убедиться, что ничего не настраивает PAM для предоставления входа без пароля для root с определенного IP-адреса или аналогичного.
Вы должны проверить наличие каких-либо дополнительных процессов, запущенных как root, которые могут предлагать корневую оболочку конкретному удаленному или локальному пользователю; исполняемый файл этого процесса больше не должен существовать на диске или быть тем, чем он был при запуске процесса.
Наконец, если вы все еще не думаете, что это невозможно: найдите все точки монтирования, параметры монтирования которых не содержат nosuid для двоичных файлов setuid / setgid (используя что-то вроде find -perm /6000) или двоичные файлы, которые могут запускаться root, которые могли быть изменены. Какие из них могли быть изменены / добавлены недавно? Любой из них. Отметки времени изменить несложно.
Руткит мог выполнять любую комбинацию вышеперечисленного и исправлять ядро (возможно, тоже в памяти, без перезагрузки), чтобы помешать вам его обнаруживать (удаление чего-либо из ps / netstat и т. Д.)
Удачи. :-)
Если вы используете ключи SSH, возможно, вы захотите вообще отключить пароль.
SSH почти невозможно взломать без паролей, но эти два слова похожи на «или», поэтому, если вы можете взломать любой из них, вас взломали.
Вы можете отключить вход в систему root через ssh, установив PermitRootLogin no в вашем файле sshd_config. Если у вас есть серверы, обменивающиеся данными или удаленно выполняющие команды как root (например, резервное копирование некоторых систем), вы, вероятно, не захотите этого делать. Если это так, то ответ Кайла Кронина - лучший вариант.
Стоит очень и очень хорошо подумать об использовании авторизованных ключей ssh для root.
Допустим, я могу быть пользователем root в системе ZZ и добавляю свой открытый ключ к authorized_key root. Теперь мой закрытый ключ гораздо более ценен, потому что теперь он не только позволяет кому-то взломать, возможно, все мои учетные записи, но также позволяет получить root-доступ на ZZ. Плюс, конечно, любая система, которая позволяет root на ZZ, также быть root на себе.
Обратите внимание, что если я помещаю свой закрытый ключ в систему, в которой другие могут иметь root-права, эти пользователи также могут получить root-права на ZZ, поскольку они могут легко получить мой закрытый ключ.
и т.д
и т.д
и т.д
Это очень опасное ослабление безопасности. Люди, как правило, слишком свободны в выборе того, куда они кладут свой закрытый ключ, поскольку это значительно упрощает использование ssh.
Я согласен с отсутствием корневого ssh вместе с sudo, но, если вы это сделаете, вы можете добавить специальных пользователей, которые не имеют сетевой зависимости NIS / LDAP / NFS / etc, чтобы вы все еще могли войти в систему, когда есть сетевой fubar. Обычно root может войти в систему, когда другие не могут, поскольку у root, как правило, меньше этих внешних требований.