Основные механизмы аутентификации пользователей при подключении через SSH — проверка пароля и сверка ключей. Их можно применять вместе или по отдельности, это настраивается в файле конфигурации SSH. Оба способа надежные, но иногда при их использовании можно столкнуться с ошибкой authentication failed. В этой статье разберемся, какие у этого сбоя могут быть причины и как их устранить.
В чем суть ошибки
У сообщения «authentication failed» перевод на русский предельно простой. Этот вывод в терминале говорит о том, что аутентификация пользователя не удалась.
Аутентификация — это проверка подлинности. Например, у вас есть сервер на timeweb.cloud. Вы настроили SSH для удаленного подключения. Чтобы система защиты вас пропустила, нужно пройти процедуру аутентификации – подтвердить, что это действительно вы.
Метод проверки подлинности закреплен в конфигурационном файле SSH. По умолчанию это аутентификация по паролю.
Другой вариант — использование пары SSH-ключей для проверки подлинности. В таком случае у пользователя на компьютере хранится закрытая часть ключа. На сервере располагается открытая часть. При попытке установить соединение эти части сравниваются. При совпадении доступ открывается. Если совпадения нет, появляется сообщение об ошибке — например, следующая ошибка SSH:
Permission denied (publickey)
Но причины появления ошибки не ограничиваются только неправильным паролем или не теми ключами. Сбой может возникать также из-за повреждения системных файлов или неверно выставленных прав доступа.
Ниже разберемся с наиболее частыми ситуациями.
VDS и VPS
Гибкие виртуальные серверы с почасовым
биллингом по всему миру: Россия, Азия и Европа.
Ошибка при использовании пароля
Обычно проблемы возникают из-за неверного имени пользователя или пароля. Также стоит обратить внимание на конфигурацию сервера — может стоять запрет на аутентификацию через пароль. Как это проверить:
- Откройте файл конфигурации на сервере. Он находится по пути /etc/ssh/sshd_config.
- Найдите строку PasswordAuthentication. По умолчанию у неё значение `yes`. Это значит, что проверка по паролю разрешена.
- Если в вашем файле конфигурации параметр PasswordAuthentication имеет значение `no`, то подключиться по паролю не получится. Чтобы исправить ситуацию, измените значение на `yes`.
С паролем связано и появление ошибки su authentication failure. Вернее, с отсутствием парольной проверки у пользователя root. Если при такой конфигурации выполнить команду `su` без параметров, то вернется ошибка. Чтобы ее устранить, достаточно назначить пользователю root парольную защиту.
Ошибка при использовании ключей
Одна из самых распространенных проблем — использование не тех ключей при установке соединения. Часто это происходит, если с одного компьютера приходится подключаться к разным хостам. Самый простой способ не запутаться — давать понятные названия с указанием на то, для каких целей вы используете файлы аутентификации.
Использование большого количества ключей без явного указания нужного приводит еще к одной ошибке:
Too many authentication failures for user
Причина сбоя — превышение числа попыток. Это случается из-за того, что SSH-клиент пытается подключиться к хосту, используя все доступные ключи. Исправить ситуацию можно с помощью опций IdentitiesOnly и IdentityFile. Пример запроса на подключение:
ssh -o IdentitiesOnly=yes \
-o IdentityFile=id1.key \
user@example.com
Чтобы каждый раз не прописывать это в командной строке при подключении, можно указать необходимую настройку в конфигурационном файле SSH ~/.ssh/config. Пример такой настройки:
Host 192.168.3.44
IdentityFile ~/.ssh/id_rsa
Host *
IdentitiesOnly=yes
В этом случае SSH будет использовать только идентификаторы, указанные в файлах ssh_config, плюс идентификатор, указанный в командной строке. Идентификаторы, предоставленные агентом, будут игнорироваться.
При использовании ssh-ключей может возникнуть еще одна ошибка:
Permission denied (publickey, password)
Ее причиной может быть ввод неверной ключевой фразы.
Если вы потеряете ключевую фразу, восстановить ее будет невозможно. Вам нужно будет сгенерировать новую пару значений для Secure Shell.
Восстановление открытого ключа
Если у вас есть закрытый ключ, но вы потеряли открытую часть, то эту проблему можно решить стандартными средствами OpenSSH.
Самый просто способ — использовать утилиту ssh-keygen.
Запустите терминал и выполните команду:
ssh-keygen -y -f ~/.ssh/id_rsa
Здесь ~/.ssh/id_rsa — это путь к закрытому части, которая хранится на компьютере. В ответ вы получите последовательность символов. Это и есть открытая часть, которую необходимо добавить на сервер.
В среде Windows решить ту же задачу можно с помощью утилиты PuTTYgen, которая входит в набор PuTTY. В ней есть кнопка Load, через которую вы можете загрузить закрытый ключ. Для этого нужно лишь знать директорию, в которой он хранится на компьютере.
После импорта вы увидите окно с полем `Public key for…`. В нём отобразится открытая часть, которую можно скопировать и отправить на сервер.
Восстановить закрытую часть по открытой нельзя — это противоречит основам безопасности.
На что еще обратить внимание
У понятия «authentication failed» перевод дает весьма общее представление о причине сбоя. Проблема может крыться не только в пароле или ключах. Значение имеют также выставленные права доступа и алгоритмы шифрования.
Неправильная конфигурация клиента
Распространенная ошибка — использование клиента SSH/SFTP (SSH, PuTTY, Filezilla) без правильной настройки всех необходимых параметров, таких как хост, порт, имя пользователя или закрытый ключ.
Другая частая проблема возникает, когда вы используете неподдерживаемый сертификат. Например, пытаетесь добавить в PuTTY файл ключа *.pem вместо файла ключа *.ppk.
Противоречия в файле конфигурации
Убедитесь, что в файле /etc/ssh/sshd_config установлены параметры, которые не противоречат друг другу. Такое может быть, например, при отключении парольной проверки или запрете на подключение для пользователя root.
Распространенный пример конфликта: у параметра PasswordAuthentication установлено значение `yes`, а у параметра PermitRootLogin — значение `no` или `without-password`. Из-за этого сервер не понимает, как проверять пользователей, и не пускает никого.
Настройка прав доступа
У OpenSSH строгие правила к тому, кто должен быть владельцем файлов и какие на них должны быть выставлены права доступа.
Убедитесь, что на сервере выставлены следующие доступы:
- ~./ssh – 700.
- ~./ssh принадлежит текущему аккаунту.
- ~/.ssh/authorized_keys – 600.
- ~/.ssh/authorized_keys принадлежит текущему аккаунту.
На клиенте также проверьте разрешения следующих файлов:
- ~ / .ssh / config – 600.
- ~ / .ssh / id_ * – 600.
Почему важен владелец? Например, вы настраивали доступ через Secure Shell от имени одного пользователя, а затем пытаетесь подключиться под другим аккаунтом, у которого нет прав даже на чтение содержимого защищенных директорий с аутентификационными данными.
Использование устаревших алгоритмов
В OpenSSH начиная с седьмой версии не поддерживаются старые ключи, которые используют алгоритм цифровой подписи — DSA. Ключи ssh-dss считаются слишком слабыми для того, чтобы можно было доверять им защиту подключения к серверу.
Если у вас старые ключи, оптимальное решение — сгенерировать и добавить на хосты новые, которые основаны на более стойких алгоритмах.
Есть и альтернатива, но пользоваться ей придется на свой страх и риск. Речь идет об изменении файла конфигурации /etc/ssh/sshd_config. Если установить параметру PubkeyAcceptedKeyTypes значение `+ssh-dss`, то можно будет использовать ключи, сгенерированные с помощью устаревшего алгоритма цифровой подписи.
Дополнительные опции могут понадобиться и на SSH-клиенте. Например, при подключении к серверу с ПО, которое давно не обновлялось. В частности, такие проблемы возникают при подключении к хостам на CentOS 6, поддержка которой прекращена в конце 2020 года. Чтобы исправить эту ошибку, необходимо добавить опцию `-oHostKeyAlgorithms=+ssh-dss`:
ssh -oHostKeyAlgorithms=+ssh-dss user@legacyhost
Ошибки на сторонних сервисах
Проблемы аутентификации могут возникать и при использовании сторонних сервисов. Например, при подключении к VK API пользователи сталкиваются с сообщением user authorization failed invalid session. Устранить такой сбой самостоятельно не получится — нужно обращаться в поддержку.
Заключение
Причина ошибки аутентификации может быть как на стороне клиента, так и на стороне сервера. Начинайте диагностику с самого простого: проверьте правильность имени пользователя и пароля, если он используется, выбор SSH-ключа в агенте. Если это не помогает устранить сбой, проверьте конфигурацию подключения и права доступа к файлам, которые OpenSSH использует для проверки подлинности пользователей.
Windows Workspace Authentication Error «incorrect user name or password» via NetScaler Gateway
book
Article ID: CTX566171
calendar_today
Updated On:
Description
When using Windows workspace, after input username, password and passcode, error prompt «incorrect username or password»(two-factor basic authentication). And can’t access Storefront resource list. While access same Gateway with Web Browser is working fine.
Resolution
If two-factor basic authentication , the Session profile for Receiver Self-Service policy needs set to SECONDARY in Credential Index checkbox.
- Navigate to Citrix Gateway>>Policies>>Session>>Session Profiles
- Select Session profile for Receiver Self-Service, Click Edit button
- Navigate to Client Experience tab , search Credential Index under Single Sign-on to Web Applications checkbox.
- Check override and set SECONDARY in Credential Index checkbox.
- Click OK to save change.
NOTE: 2 factors classic authentication configuration guide in Gateway for Workspace(Receiver) , please click here .
Problem Cause
Incorrect configuration for Credential index under Single Sign-on to Web Applications checkbox
Was this article helpful?
thumb_up
Yes
thumb_down
No
Select Suggestions:
Send us feedback
Resolving «Password Authentication Failed for User ‘postgres’» in PostgreSQL
The error message «password authentication failed for user ‘postgres'» commonly occurs in PostgreSQL when there’s an issue with login credentials, user access configurations, or the PostgreSQL authentication settings. This error prevents users from accessing the PostgreSQL server using the specified username and password, and it’s essential to address it to establish a proper connection.
Causes of the Error
- Incorrect Password: The password provided may be incorrect for the postgres user.
- pg_hba.conf Misconfiguration: PostgreSQL’s pg_hba.conf file manages client authentication. If it’s incorrectly configured, it may block password authentication.
- Database Server Restart Needed: Configuration changes in PostgreSQL require a restart to apply, so changes may not have taken effect.
- Database Host Mismatch: Trying to connect to PostgreSQL on the wrong host can also trigger this error.
Step-by-Step Solution
Step 1: Verify Password
Double-check that the password you’re using is correct. If unsure, you can reset it in PostgreSQL with the following command:
Code:
-- Change password for the 'postgres' user
ALTER USER postgres WITH PASSWORD 'new_password';
Command Explanation:
- ALTER USER postgres: Targets the postgres user.
- WITH PASSWORD ‘new_password’: Sets a new password.
Step 2: Check pg_hba.conf File
PostgreSQL uses the pg_hba.conf file to configure client authentication. Verify that it allows password-based authentication for the postgres user.
1. Open pg_hba.conf, usually located in the PostgreSQL data directory.
2. Ensure the following line (or similar) exists for the required connection type (local or host):
Code:
# For local connections
local all postgres md5
# For host-based connections
host all postgres 127.0.0.1/32 md5
Command Explanation:
- local indicates a local connection using a socket.
- host indicates a network-based connection.
- md5 specifies password-based authentication.
Step 3: Reload PostgreSQL Server
For any changes in pg_hba.conf to take effect, reload or restart the PostgreSQL service:
Code:
# Reload PostgreSQL on Linux/Mac
sudo systemctl reload postgresql
Step 4: Check Database Host
Make sure the connection is being attempted on the correct host, especially if connecting remotely. For example, use localhost if the database is on the same machine:
Code:
# Connect to PostgreSQL with a specific host
psql -U postgres -h localhost -W
Examples and Explanation:
1. Reset Password for postgres
Code:
-- Change the password for the 'postgres' user
ALTER USER postgres WITH PASSWORD 'new_password';
2. Verify pg_hba.conf Entry
# Allow password-based local authentication for 'postgres'
local all postgres md5
# Allow host-based password authentication on localhost
host all postgres 127.0.0.1/32 md5
3. Reload PostgreSQL Configuration
# Reload PostgreSQL to apply authentication settings
sudo systemctl reload postgresql
4. Attempt Connection
# Attempt to connect as the 'postgres' user
psql -U postgres -h localhost -W
Important Notes:
- Password Encoding: Ensure the password is encoded in md5 format in pg_hba.conf.
- Privileges: Confirm that the postgres user has the necessary permissions for the intended actions.
- Service Management: Changes in PostgreSQL configurations require reloading or restarting for proper effect.
All PostgreSQL Questions, Answers, and Code Snippets Collection.
Ошибка «Неверный пароль»
Иногда при попытке войти в аккаунт Google из стороннего сервиса (например, через почтовое приложение Apple, Mozilla Thunderbird или Microsoft Outlook) возникает ошибка «Неверный пароль», даже если пароль был введен верно. Эту проблему можно решить, обновив приложение до последней версии или установив более надежный почтовый клиент.
Обновите приложение или ОС
Причиной трудностей с доступом к аккаунту может быть устаревшая версия приложения или операционной системы на вашем устройстве. Их необходимо обновить.
Смените почтовый клиент
Google может блокировать попытки доступа к вашему аккаунту, если приложение, через которое вы пытаетесь зайти, не отвечает нашим стандартам безопасности.
Войти в аккаунт Google можно через сторонние приложения, у которых есть опция «Войти через аккаунт Google», или через любые сервисы и приложения Google, например Gmail.
Подробнее о небезопасных приложениях и аккаунте Google…
Создайте пароль приложения
Пароль приложения – это 16-значный код, который дает стороннему приложению или устройству доступ к вашему аккаунту Google. Подробнее о том, как войти в аккаунт Google с помощью пароля приложения…