Fatal error no supported authentication methods available server sent publickey filezilla

Устранение неполадок SSH: ошибки аутентификации

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

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

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

Требования

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

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

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

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

Клиенты PuTTY и OpenSSH выдают такое сообщение:

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:

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

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

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

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

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

debug1: Authentications that can continue: publickey,password

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

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

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

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

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

./ssh должен принадлежать текущему аккаунту.

/.ssh/authorized_keys должен принадлежать текущему аккаунту.

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

/ .ssh / config – 600.

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

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

Если вы забыли, какой закрытый ключ соответствует тому или иному открытому ключу, инструменты 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, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.

Источник

SSH Public Key — No supported authentication methods available (server sent public key)

I have a 12.10 server setup in a virtual machine with its network set to bridged (essentially will be seen as a computer connected to my switch).

I installed opensshd via apt-get and was able to connect to the server using putty with my username and password.

I then set about trying to get it to use public/private key authentication. I did the following:

1. Generated the keys using PuttyGen.
2. Moved the public key to /etc/ssh/myusername/authorized_keys (I am using encrypted home directories).

Set up sshd_config like so:

When I connect using putty or WinSCP, I get an error saying No supported authentication methods available (server sent public key).

If I run sshd in debug mode, I see:

Why is this happening and how can I fix this?

6 Answers 6

Looks like there was a problem with my public key file. PuttyGen will create a public key file that looks like:

However, this will not work, so what you need to do is to open the key in PuttyGen, and then copy it from there (this results in the key being in the right format and in 1 line):

Paste this into authorized_keys then it should work.

1. Edit the /etc/ssh/sshd_config file.
2. Change PasswordAuthentication and ChallengeResponseAuthentication to yes .

3a. Restart ssh /etc/init.d/ssh restart .
OR
3b. better you use service sshd restart

Just a tip I hope may help someone else with the headaches I had. F21 is right that you need to copy the key out of the PuTTYGen window instead of saving the file, but after copying, the way you paste may have significant impact on whether your key will work or not. Some editors will alter the text as you paste, or do something with newlines or something that makes the authorized_keys file invalid.

What I have found to be the least likely to break is to echo the full string and redirect the output to the file. Right-clicking in PuTTY to paste the key string to the commandline, it works out like this (with the example given above):

You’ll end up with this:

Another advantage of this method is that you can add multiple keys this way by using >> to append instead of > to overwrite, eg:

Источник

No supported authentication methods available in FileZilla

I’m using FileZilla to connect to my SFTP server. But when I’m trying to connect, it gives me this error

Error: Disconnected: No supported authentication methods available (server sent: publickey)

I have generated a private key with PuTTYgen and added it to FileZilla but this error still appears.

What does this error mean? And how can I solve it?

7 Answers 7

The error means that FileZilla tried all available authentication methods and have not succeeded. In your case, there was only public key authentication method available (a method that the client [FileZilla] and the server agreed on mutually).

As you claim that you have set up FileZilla correctly, chances are that you have not configured the public key on server-side.

For instructions see:

Though actually all the guides expect that you have a way to connect (e.g. password authentication). What does not seem to be the case. Possibly your server administrator/hosting provider has its own mechanism for setting up the public key authentication.

If you specify, what is your server like, you may get more specific answers.

I had similar issue error was Error: Disconnected: No supported authentication methods available (server sent: publickey)

Ans: Simply go to filezilla-Edit-settings-sftp-Add key file—add your ppk file-ok

connect again and issue resolved

Diff answer than 5 other answers here above (as of this moment)

I received this authentication error- No supported authentication methods available (server sent: publickey) repeatedly while connecting to my google cloud project and connecting thru FileZilla, even when I had spent hours checking my every step again and again by watching diff youtube videos and reading articles over Digital Ocean and similar.

But finally succeeded in a second, when I went into GCloud> Desired Project> Compute Engine> Metadata (in the left bar)> Metadata (in the main Pane)> and there I changed ‘ enable-oslogin’ from ‘True’ to ‘False’.

I had, sometime in my overzeal, had put in this key yesterday while doing something else.

I had the same problem and managed to solve the issue.

When using filezilla and sftp, it is important that you have full permissions for the folder where the ppk file is

Easiest way is to save the ppk file in the USERyour_user_nameDocuments folder. You may need to set permissions manually for other locations.

In my case I found that the FileZilla configuration I had was using an outdated user name for password authentication.

This just happened to me, if it was working fine before updating FileZilla then just fix it by deleting your site from your site manager (CTRL + S) and recreating it.

Apparently that update will not take your old configuration files properly.

Filezilla SSH — cPanel Instructions

Set Filzilla to SSH/SFTP using the site manager.

Set to use authorisation by Key File

For me I had to go into cPanel and then create a key. REMEMBER your password you need it in a minute.

Then «authorize» my key.

Convert your key to PPK in cPanel. You need your password.

Download it & save it somewhere you remember.

Use the Browse option in Filezilla SFTP settings and then upload it.

Then I also had to change my «username» in Filezilla from id_rsa to my cPanel account name. After that things worked well.

As an additional note, instead of using my remote directory as /public_html/ which I would for FTP I had to change it to the full directory /home/YourCpanelUserName/public_html

Hope that that helps someone.

In one case I had MOVED my PPK into a sub folder which was the issue.

Источник

I’m trying to allow another developer to connect to a our ubuntu server and they are getting the below error in FileZilla.

Disconnected: No supported authentication methods available (server sent: publickey)
Could not connect to server

I thought, maybe I added the public key to the ~/.ssh/authorised_keys on the server incorrectly.

She sent me a public key like this called mags_public_key

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "mags-key-20140819"
AAAAB3N????????????????????????????????????????????????????????
???????????????????????????????????????????????????????????????
???????????????????????????????????????????????????????????????
???????????????????????????????????????????????????????????????
???????????????????????????????????????????????????????????????
????x?????????????????????????????BKCx1M1S/Mhh3MHw==
---- END SSH2 PUBLIC KEY ----

Which is odd as I’m not used to comments in public keys or line breaks? We’ve tried using her public key with & witout the comment & line breaks. I’ve added it to ~/.ssh/authorised_keys like this:

ssh-rsa AAAAB/??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????3cXMJMA8zT
AAAAB3N??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????BKCx1M1S/Mhh3MHw==

It’s also strange as it does not begin with ssh-rsa, also her private key is called mags_private.ppk, I think this is because she is using windows & putty. I’m used to adding keys which are called id_rsa.pub

Is their a problem with her public key or do I need to add something to the authorised_keys file. Other devs have been able to ssh in before but they had a id_rsa.pub.