Login incorrect ubuntu как исправить

Обновлено: 06.07.2024

После установления соединения и инициирования протокола система может проверить подключение пользователя к системе. SSH поддерживает множество механизмов аутентификации. В этом руководстве рассмотрены два наиболее распространенных механизма: парольная аутентификация и аутентификация на основе SSH-ключей.

Требования

Убедитесь, что можете подключиться к виртуальному серверу через консоль.
Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.

Основные ошибки

Отказ в доступе (парольная аутентификация)

Примечание: Если вы настроили на сервере SSH-ключи и отключили PasswordAuthentication, сервер не поддерживает паролей. Используйте SSH-ключ, чтобы подключиться к серверу.

root@111.111.111.111's password:
Permission denied (publickey,password).
PuTTY Error output
root@111.111.111.111's password:
Access denied
Server sent disconnect message
type 2 (protocol error):
"Too many authentication failures for root"

Это значит, что аутентификация прошла неудачно. Ошибка может быть вызвана рядом проблем. Вот несколько советов по устранению этой ошибки:

Убедитесь, что вы используете правильное имя пользователя. В CoreOS используйте пользователя core. В FreeBSD используйте аккаунт пользователя freebsd.
Парольная аутентификация пользователя может быть нарушена. Проверьте, поддерживает ли парольную аутентификацию веб-консоль сервера. Если она не поддерживает пароли, вам придется попытаться сбросить пароль или обратиться за помощью к службе поддержки, чтобы восстановить доступ.
Убедитесь, что сервер поддерживает парольную аутентификацию.

Отказ в доступе (аутентификация на основе SSH-ключей)

Этот метод использует криптографические ключи для аутентификации пользователя.

Вы можете получить такую ошибку:

Permission denied (publickey).
PuTTY Error output
Disconnected: No supported authentication methods available (server sent: publickey)

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

Убедитесь, что файл authorized_keys и сам закрытый ключ имеют правильные права доступа и собственности.
Убедитесь, что сервер поддерживает аутентификацию на основе ключей SSH.
Убедитесь, что клиент SSH может получить закрытый ключ. Если вы используете PuTTY, убедитесь, что ключи SSH правильно настроены в сессии. Если вы используете OpenSSH, убедитесь, что у закрытого ключа SSH есть соответствующие привилегии.
Убедитесь, что файл authorized_keys содержит правильный открытый ключ, и что открытый ключ добавлен на сервер.
Возможно, вы используете закрытый ключ, который больше не поддерживается сервисом OpenSSH. Эта ошибка обычно затрагивает серверы OpenSSH 7+ при использовании закрытого DSA-ключа SSH. Обновите конфигурацию сервера.

Консоль не поддерживает пароли

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

В консоли появляется форма аутентификации:

Ubuntu 14.04.4 LTS server tty1
server Login:
Password:

Но после ввода пароля появляется ошибка:

После сброса пароля вы получите:

You are required to change your password immediately (root enforced)
Changing password for root.
(Current) UNIX Password:

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

При успешном завершении вам будет предложено дважды ввести новый пароль:

Enter new UNIX password:
Retype new UNIX password:

Устранение неполадок

Проверка доступных методов аутентификации

debug1: Authentications that can continue: publickey,password

Если вы не нашли в списке метод аутентификации, который хотите использовать, откройте файл /etc/ssh/sshd_config. В нём часто допускается ошибка: PasswordAuthentication имеет значение yes, а PermitRootLogin – no или without-password для пользователя root.

Исправьте эту ошибку, перезапустите сервис.

Настройка прав доступа и собственности

Сервер и клиент OpenSSH имеют строгие требования к привилегиям и правам собственности на файлы ключей.

Сервер и клиент OpenSSH должны иметь следующие права:

Кроме того, клиент должен также иметь такие права:

Эти изменения можно внести с помощью консоли.

Проверка открытого и закрытого ключа

Если вы забыли, какой закрытый ключ соответствует тому или иному открытому ключу, инструменты OpenSSH и PuTTY помогут вам сгенерировать открытый ключ на основе зарытого ключа. Полученный результат вы можете сравнить с файлом

Чтобы восстановить открытый ключ на основе закрытого ключа в среде OpenSSH, используйте ssh-keygen и укажите путь к закрытому ключу.

/.ssh/id_rsa
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f

В среде PuTTY команда PuTTYgen.exe загружает интерфейс, в котором можно использовать опцию Load и импортировать закрытый ключ. PuTTY хранит такие файлы в формате .ppk (нужно знать место хранения файла).

Импортировав ключ, вы увидите окно с разделом Public key for pasting into OpenSSH authorized_keys file. В нём и будет искомый открытый ключ. Выделите текст и вставьте его в файл. Он сгенерирует открытый ключ.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f imported-openssh-key

Можно проигнорировать комментарий после открытого ключа (imported-openssh-key).

В любом случае этот открытый ключ нужно добавить в файл

OpenSSH 7 и устаревшие ключевые алгоритмы

В системах с OpenSSH 7 (FreeBSD и CoreOS по умолчанию) старые ключи DSA не поддерживаются.

Ключи ssh-dss считаются слабыми, вместо них рекомендуют использовать более надёжные современные алгоритмы.

Следовательно, в данном случае лучшим решением будет создать новые ключи и добавить их на хосты.

Однако в качестве обходного пути вы можете установить в PubkeyAcceptedKeyTypes значение +ssh-dss в файле /etc/ssh/sshd_config.

Заключение

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

Загружаю /bin/bash, passwd, новый пароль.
Проверяю:

Решение: отключить SELinux

от рута уже давно входить нельзя. очнись.

По-умолчанию, пароль рута в федоре не установлен. Надо сделать sudo su , чтобы в него войти.

от рута уже давно входить нельзя

По-умолчанию, пароль рута в федоре не установлен

4.2 ставил спин с корицей, пароль рута задаётся при установке.

ну тогда думай че ты последнее менял/настраивал. ну и убедись, что все кнопки в tty нажимаются и работают.

ну тогда думай че ты последнее менял/настраивал.

Менял /etc/shadow, права доступа к нему(644). После сломался GDM(черт бы с ним).
Даже через tty войти не могу.

Позже покажу логи загрузки.

Была такая ерунда на свежей Федоре 32. Установил минималку через нетинстал, перезагрузка и не пускает. Не стал разбираться, снес этот самый лучший дистр.

utanho ★★ ( 04.10.20 18:13:38 )
Последнее исправление: utanho 04.10.20 18:14:52 (всего исправлений: 2)

Разобрался. SELinux мешал. Отключил его к черту.

Как именно это делается в федоре?

Это не называется «разобрался».

Скопипастил /etc/shadow откуда-то без учёта контекста selinux?

Мне тоже интересно, как?

SELinux мешал. Отключил его к черту.

Как именно это делается в федоре?

И ядру передай selinux=0

Скопипастил /etc/shadow откуда-то без учёта контекста selinux?

passwd user, vi /etc/shadow

мой vsftpd.conf файл выглядит следующим образом, и я пытаюсь связаться с локальным пользователем:

попробуйте перезапустить vsftpd. > sudo /etc/init.d/vsftpd restart У меня возникла та же проблема, но у меня это сработало. Еще одна вещь, чтобы проверить: что такое оболочка входа для пользователя. это оболочка в / etc / shells Для меня был просто неправильный формат для пользователя в / etc / passwd - мне нужно было установить правильный домашний каталог, оболочку и . часть.

Сделайте резервную копию файла конфигурации перед внесением изменений;

и затем отредактируйте vsftpd.conf (с помощью vi или nano)

Затем внесите следующие изменения

pam_service_name = ftp

Сохраните изменения и перезапустите ftp-сервер (если вы используете nano, нажмите CTRL + O и введите для сохранения, затем CTRL + X для выхода)

Эта проблема также может быть решена в debian7 с помощью этого ответа. Вы отключаете управление доступом по умолчанию через PAM, потому что по умолчанию "ftp" не имеет правил. По умолчанию pam_service_name=vsftp используется файл /etc/pam.d/vsftpd . Этот файл по умолчанию требует, чтобы у пользователей FTP была включена оболочка, /etc/shells а их не нужно указывать в /etc/ftpusers . @JeroenVermeulenBVBA +1 ты прав. Я боюсь, что некоторые люди просто не знают, что на самом деле происходит под ними и почему это «работает».

По умолчанию vsFTPd использует файл /etc/pam.d/vsftpd . Этот файл по умолчанию требует, чтобы у пользователей FTP была включена оболочка, /etc/shells а их не нужно указывать в /etc/ftpusers . Если вы проверите эти 2 вещи, вы, вероятно, найдете, в чем проблема.

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

Мне не нужно было менять vsftpd.conf. Нужно было только убедиться, что в моем файле / etc / passwd была установлена оболочка, которая также была указана в / etc / shells.

Таким образом, в основном после useradd без оболочки мне нужно было убедиться, что домашний каталог был создан и что пользователь имел / bin / bash в качестве оболочки.

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

Я столкнулся с этой проблемой, когда попытался войти в систему с правами root, и я просто решил ее.
мой vsftpd: версия 3.0.2

Решение:

проверьте следующий файл (он содержит список пользователей, которым запрещен доступ по FTP):

В моем случае я закомментировал root из файла, потом все заработало.

Я сделал то же самое, чтобы иметь возможность войти в систему как root, но не сработало

Пожалуйста, внесите некоторые изменения в /etc/vsftpd.conf

pam_service_name = FTP

если вы хотите установить доступ по умолчанию к каталогу / var / www для локального пользователя, вы можете сделать это с помощью строки ниже .

local_root = / вар / WWW

теперь сохраните и выйдите .

перезапустите сервер vsftpd с помощью службы sudo vsftpd restart

Предлагаемое решение не работает для меня. Я разочаровался в ftp пользователе и переключил свое внимание на ubuntu пользователя. Я убедился, что есть пароль, связанный с ubuntu пользователем.

Я обязательно включил пассивный режим и установил local_enable=YES в vsftpd.conf файл.

Я был в состоянии подтвердить подлинность просто отлично, используя ubuntu учетную запись. И я успешно загрузил большой файл на мой FTP-сервер Amazon Ubuntu. Ясно, что с ftp пользователем что-то не так .

Я использовал Ubuntu 18.04 и LetsEncrypt сертификаты для шифрования TLS. То, что работало, меняло имя pam_service_name = ftp, ошибка, которую я получал в Filezilla, была

Я обнаружил, что моя проблема связана с грязным хранилищем пакетов. Я обновил свои репозитории и переустановил ubuntu-desktop:

Войдите в bash, (Ctrl + Alt + F1) sudo apt-get update sudo apt-get install --reinstall ubuntu-desktop

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

Переходите к tty1 с помощью Ctrl-Alt-F1.

sudo перезапуск службы lightdm

Моя проблема заключалась в том, что из-за манипуляций с SSD права доступа к / tmp были испорчены, и я нашел на форуме Ubuntu это решение, которое мне помогло:

Это может произойти, если в вашем файле .bashrc или .profile есть ошибка. На графическом экране входа нажмите Ctrl + Alt + F2 и войдите оттуда. Исправьте все ошибки, которые вы видите напечатаны на консоли. Тип: перезагрузка sudo

Войдите в bash, (Ctrl + Alt + F1)

Теперь вы готовы! вот что решило мою проблему.

Я столкнулся с той же проблемой после установки пакета vnc4server в Ubuntu 12.10. (Возможно, он настраивает пересылку X11, не уверен.) Я обнаружил, что в моем домашнем каталоге файлы .Xauthority , .bash_history и папка .vnc принадлежат пользователю root и группе root . Изменение их (и всех файлов под .vnc ) на принадлежащее моему собственному пользователю с помощью команды chown позволило мне войти в систему (я перезагрузился первым).

Чтобы внести эти исправления, либо введите ssh в другом месте или переключитесь в текстовую консоль с помощью Ctrl + Alt + F2.

Проверьте ваш файл .xsession-errors в домашнем каталоге на наличие ошибок после входа через CTRL + ALT + F1

. В моем случае .xsession-errors выдает ошибку, говорящую, что у меня плохие символы в мой файл .profile из моей установки git (человеческая ошибка .. моя ошибка)

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

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

я обнаружил, что по какой-то причине он удалил ubuntu-desktop. Вы можете попробовать Ctrl + Alt + F1 и использовать следующую команду:

После завершения нажмите Ctrl + Alt + F7 и войдите в систему как обычно. У меня все еще не было кнопок «Перезагрузить» и «Учетные записи пользователей» на панели; для этого перейдите в терминал и используйте:

Решил мою проблему.

Проверьте ваш файл .xsession-errors в домашнем каталоге на наличие ошибок после входа через CTRL + ALT + F1

. В моем случае .xsession-errors выдает ошибку, говорящую, что у меня плохие символы мой файл .profile из моей установки git (человеческая ошибка .. моя ошибка)

Войдите в bash, (Ctrl + Alt + F1)

Теперь вы готовы! вот что решило мою проблему.

Чтобы внести эти исправления, либо введите ssh в в другом месте или переключитесь в текстовую консоль с помощью Ctrl + Alt + F2.

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

Решил мою проблему.

Переходите к tty1 с помощью Ctrl-Alt-F1.

sudo перезапуск службы lightdm

Войдите в bash, (Ctrl + Alt + F1) sudo apt-get update sudo apt-get install --reinstall ubuntu-desktop

Проверьте ваш файл .xsession-errors в домашнем каталоге на наличие ошибок после входа через CTRL + ALT + F1

Войдите в bash, (Ctrl + Alt + F1)

Теперь вы готовы! вот что решило мою проблему.

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

я обнаружил, что по какой-то причине он удалил ubuntu-desktop Вы можете попробовать Ctrl + Alt + F1 и использовать следующую команду:

Решил мою проблему.

Читайте также: