SSH не запрашивает пароль, сразу выдает “доступ запрещен”.

Пытаюсь подключиться по SSH с использованием учетной записи пользователя; учетная запись root работает, но я указываю закрытый ключ. Учетная запись пользователя просто выдает “Permission denied (publickey,gssapi-with-mic)” без запроса пароля вообще.

Как я могу это исправить, чтобы войти с паролем, а НЕ с ключом? Я не хочу использовать закрытый ключ для этого сейчас, только обычную учетную запись.

На сервере установлена настройка

 PasswordAuthentication no 

Измените ее на yes, и после перезапуска вы сможете использовать аутентификацию по паролю.

Вам также потребуется отредактировать /etc/ssh/sshd_config, чтобы установить настройку:

ChallengeResponseAuthentication yes

а также…

PasswordAuthentication yes

И не забудьте запустить /user/sbin/service ssh restart после этого, чтобы применить новые настройки.

Проверьте последовательность входа с помощью ssh -vv. Это покажет вам, какие методы аутентификации пробуются и какие терпят неудачу. Затем вы можете включить то, что хотите, и отключить то, что не хотите. Сначала, конечно, включите.

Это в вашем файле sshd (не ssh, который вы также, вероятно, найдете в /etc/ssh)

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

И на случай, если кто-то столкнется с этой проблемой, я получал эту проблему каждый раз, когда закрытый ключ пользователя имел слишком открытые разрешения. Чтобы это заработало, мне пришлось изменить разрешения на закрытом ключе на 400 (что, я полагаю, является уровнем разрешений по умолчанию при создании ключа. Не знаю, почему этот был другим).

Не знаю, является ли это всегда причиной, однако. Это произошло на Mac.

Существует три вещи, которые могут это вызвать, и две, обсуждаемые всеми остальными здесь, не охватывают распространенный сценарий, возникающий с AMI, развернутыми в AWS.

PasswordAuthentication no – не разрешать аутентификацию по паролю

или

ChallengeResponseAuthentication no – не вызывать проверку у пользователя для аутентификации (может быть, пароль или другой ввод с клавиатуры)

или

AuthenticationMethods publickey – разрешать вход только после аутентификации через publickey

Измените это на:

PasswordAuthentication yes – разрешить аутентификацию по паролю

и

ChallengeResponseAuthentication yes – разрешить проверку у пользователя

и

AuthenticationMethods any – разрешить любую действительную форму аутентификации для успешного прохода

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

Это также может быть вызвано работой ssh-agent. ps aux|grep ssh-agent

Его можно безопасно завершить.

Для меня выяснилось, что во время фриковского сеанса устранения неполадок файл LOCAL ssh_config был изменен. Ни один из этих методов не сработал для меня, но изменение PasswordAuthentication yes в /etc/ssh/ssh_config локальной машины сработало.

На случай, если это поможет кому-то.

У меня была такая же проблема в Ubuntu 22.04. Я не смог найти строку:

ChallengeResponseAuthentication no

в файле /etc/ssh/sshd_config. Я прочитал весь конфигурационный файл и нашел следующее:

# Измените на yes, чтобы включить пароли с вызовом (осторожно с проблемами с
# некоторыми модулями PAM и потоками)
KbdInteractiveAuthentication no

Я просто изменил это на yes:

KbdInteractiveAuthentication yes

Затем я перезапустил SSH-сервис:

service ssh restart

Вот и все!

Я установил как PasswordAuthentication yes, так и ChallengeResponseAuthentication yes, но все равно не смог использовать аутентификацию по паролю. Затем я проверил в папке /etc/ssh/sshd.config.d/ и нашел конфигурационный файл, который имел PasswordAuthentication no, поэтому я изменил его на yes и перезапустил сервис. Теперь все работает отлично.