Не может Войти в систему как корень

некоторые возможности, которые сразу происходят со мной:

• скорее всего, кто-то изменил пароль root. который мог означать, что поле было взломано.
• passwd или теневой файл были повреждены или удалили так или иначе.
• так же для/etc/nsswitch.conf или Вашей конфигурации PAM.

для фиксации (или, по крайней мере, получите корневой доступ снова):

перезагрузите систему. при подсказке личинки отредактируйте строку ядра и добавьте "init =/bin/bash". когда начальные загрузки системы, Вы получите подсказку удара, и корневая фс будет смонтирована только для чтения. необходимо будет повторно смонтировать его, RW. затем изменяют пароль root. затем выполненная синхронизация, повторно смонтируйтесь / как RO снова, и "перезагрузка-f теперь" (дополнительно делают еще некоторое расследование/фиксацию прежде, чем перезагрузить).

примечание: однако, то, что консоль tty будет в очень странном состоянии. Вы, например, не сможете уничтожить процессы путем нажатия ^C (потому что ^C еще не отображается на SIGINT). не делайте ошибку проверки с помощью ping-запросов нигде или выполнения ничего больше, что продолжает идти, пока это не получает INT. откройте еще много VTs с командой openvt прежде, чем сделать что-либо.

(BTW, для больше об этой теме, видят мое сообщение в блоге, ^C не уничтожает процессы, SIGINT делает),

Это по SSH? Большинство дистрибутивов (включенный SuSE) отключает корень от входа в систему по SSH по умолчанию. Соответствующая установка является "PermitRootLogin" в/etc/ssh/sshd_config; измените его на "Да" и перезапустите SSHD, посмотрите, работает ли это.

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

Некоторый глупый вопрос: Ваша клавиатура повреждается?

Можно ли загрузить сервер и начать ли в единственном режиме получать корневой доступ и затем восстанавливать пароль с командой "passwd".

Вот ссылка о том, как сделать это в установке Red Hat:

http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/s1-rescuemode-booting-single.html

Надежда это поможет Вам

Это может быть признаком большей проблемы. Даже если Вы устраняете проблему входа в систему могут быть другие неожиданности, ожидающие Вас или Вашего клиента. Возможно, это было бы лучше и более безопасным выполнить новую установку и быть сделанным с ним.

Некоторое недавнее OSs Linux не имеет корневой учетной записи, которая является log-in-able, вместо этого необходимо войти в систему как обычный пользователь и sudo базироваться. У Вас есть другой счет на ту машину?

Если это - продукт под ключ, к которому у Вашего клиента не было корневого доступа, и Вы уверены, что существует пользователь root и Ваш пароль, который только знала Ваша компания, не работает, то она кажется, что кто-то еще изменил ее. Ни с кем уведомляющим Вас относительно изменений затем я предположил бы, что это взламывается.

Разъедините его от своей сети IMMEDIATELY.

Используйте liveboot CD для доступа к файловой системе, если бы существует что-то, что необходимо выйти из поля, но я лично полагал бы, что это пошло на компромисс. Если бы машина регулярно не сохранялась затем, то наша политика состоит в том, чтобы предположить, что не имеет данных никакой важности на нем и просто вытирает и переустанавливает и реконфигурировала, поскольку Вы не можете действительно доверять никаким данным по ней в этой точке, чтобы не быть trojaned или измененный.

Я предположил бы, что никто не заботится в этой точке, но я просто поразил эту проблему.

Сценарий: Мы пытаемся загрузить SuSE Linux 11 с режимом Rescue и заменить/etc/shadow запись пустым указателем так, чтобы корень мог войти в систему без пароля. Результат что исходный сказанный плакат: "Войдите в систему неправильный", не будучи предложенным пароль. Не уверенный, что, но что-то еще изменяется passwd.

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

• (начальная загрузка в спасении)
• смонтируйте/dev/sda1/mnt
• смонтируйтесь - связывают/dev/mnt/dev
• chroot/mnt
• корень passwd

Затем обычный umount, umount, синхронизация, останов.

Надежда это помогает кому-то.

Проверьте свой /var/log/auth.log на предмет неудачного входа в систему root. Вы можете обнаружить нечто подобное:

30 декабря 07:31:51 vps login [18093]: (pam_securetty) доступ запрещен: tty 'hvc0' небезопасен ! 30 декабря 07:31:51 vps login [18093]: НЕУДАЧНЫЙ ВХОД (1) на 'hvc0' ДЛЯ `root ', Ошибка аутентификации

В современных системах используется множество новых технологий, и, например, виртуализированный экземпляр XenServer может иметь консоль как hvc0.

Это можно исправить, включив эту консоль в / etc / securetty. Просто введите: echo hvc0 >> / etc / securetty && kill -1 1 Затем попробуйте войти еще раз.

Сначала вам нужно войти в вашу систему. Это можно сделать с помощью

init=/bin/bash

в параметрах загрузки ядра. После загрузки вы получаете корневую оболочку без аутентификации, но ничего другого.

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

openvt -c 23 -f /bin/bash

. Она откроет вторую корневую оболочку на вашей 23-й виртуальной консоли, которую вы можете получить, нажав клавишу alt / стрелка влево на вашей первой виртуальной консоли (позже, из X, вы можно перейти к этой первой виртуальной консоли с помощью alt / ctrl / f1).

После этого вы можете запустить свою систему с помощью команды

exec /sbin/init

Если все прошло хорошо, ваша система теперь работает, вы не можете далее входить в систему , но скоро вы сможете хотя бы попробовать их, пока у вас есть корневая консоль на tty23.

Теперь попробуйте войти в систему и проверьте файлы журналов в / var / log, что там написано. Если этого недостаточно для поиска и устранения проблемы, этот сайт ждет вас с вашим следующим вопросом и интересными частями журнала ошибок.

У этого есть проблема с модулем аутентификации PAM:

cd /etc/pam.d

Мы также должны отредактировать « su » в / etc / pam. d каталог

sudo nano su

требуется авторизация pam_securetty.so - Эта строка должна быть прокомментирована знаком «#», только root может войти в систему как root, не может изменить, например, другого пользователя на root.

Решено:

В / etc / default / shellinabox я изменил:

SHELLINABOX_ARGS = - no-beep

на:

SHELLINABOX_ARGS = "- no- beep --service = /: SSH "

Это загружает оболочку как сеанс SSH. Затем он следует правилам, установленным в / etc / ssh / sshd_config:

PermitRootLogin yes

Это работа для меня.

sudo su 
sudo apt install xinit

Затем войдите в систему как root в режиме пользовательского интерфейса